Tableless » JQuery

Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas

Diego Eis — Wed, 09 May 2012 16:53:47 +0000

Existem três categorias de “ferramentas” que nos ajudam a desenvolver um projeto client-side: Préprocessadores, Frameworks e Bibliotecas.

Préprocessadores

Préprocessadores são ferramentas onde você escreve CSS de uma determinada forma, modificando sua sintaxe, fazendo com que na hora de sua utilização o código CSS precise ser préprocessado para que o código escrito seja transformado em código CSS puro e assim então os browsers consigam entender.

Existem muitos préprocessadores no mercado como Less, Sass, Turbine, Switch CSS e outros.

Particularmente eu não gosto de usar préprocessadores. Para começar é necessário que você aprenda a linguagem de cada um e a ideia de que seu CSS precisa ser compilado para poder funcionar não me agrada muito. O CSS é simples demais para complicarmos desse jeito. Entretanto, há uma série de coisas interessantes que podemos fazer com os préprocessadores como variáveis, funções, operações e etc que demorarão um pouco (ou não) para fazerem parte do core definitivo da linguagem. Mesmo assim, pessoalmente, para a maioria dos projetos, não vale a pena.

Frameworks

Frameworks são diferentes de préprocessadores mas são muito parecidos com Bibliotecas. Um Framework disponibiliza para o dev um conjunto de estilos e estruturas prontas para a utilização em projetos de forma escalável e uniforme. Normalmente os frameworks te dão uma coleção de componentes para que sejam usadas por todo o projeto. Esses componentes na maioria das vezes já vem com estilos visuais aplicados, bem como a estrutura. Veja por exemplo o Bootstrap ou o Blueprint.

Com o Bootstrap você consegue, rapidamente, fazer um protótipo simples ou uma estrutura básica de sistema. É o preferido dos programadores. Os elementos visuais já foram criados e desenhados. Talvez não seja uma boa ideia você utilizar um framework em um projeto cujo design já esteja aprovado. Você teria muito retrabalho para “zerar” o estilo visual de cada elemento para depois reconstruí-lo utilizando o seu design.

É muito importante que o uso de um framework CSS/Javascript seja aprovado no início de um grande projeto. Mesmo que você planeje criar um framework do zero, específico para seu projeto. O que na maioria das vezes não vale a pena.

Bibliotecas

Bibliotecas CSS geralmente não modificam o visual como os Frameworks fazem, mas eles disponibilizam uma coleção de classes, reutilizáveis e o melhor, combinatórias, para que se adeque a diversos cenários do seu projeto. Como essas classes não estão ligadas a nenhuma formatação visual, você consegue combinar sem grandes problemas com suas classes e IDs, modificando a hora que quiser a formatação visual dos elementos.

As bibliotecas são indicadas para projetos mais simples, sem grandes apetrechos técnicos, como um site ou algo parecido. Para fazer um sistema, as bibliotecas irão reforçar os Frameworks, facilitando a organização e formatação da estrutura do site. A biblioteca também ajuda na manipulação dos elementos via Javascript se baseando por estas classes prontas.

A verdade é que hoje é muito difícil diferenciar uma biblioteca de um framework.

Como todos eles trabalham juntos?

Você pode usar todos os três ao mesmo tempo em um projeto. Mas não é muito inteligente, já que se você estiver utilizando um framework, muito provavelmente ele terá uma “biblioteca” em sua base. Imagine que a biblioteca pode ser específica de estrutura ou formatação visual. O Framework, basicamente, junta os dois. Obviamente há mais coisas envolvidas. Mas para simplificarmos a explicação, imagine que um Framework é a mistura dessas duas bibliotecas.

O Preprocessador é independente do Framework e da Biblioteca. O seu ganho está ao escrever um código mais escalável, muitas vezes melhorando ou piorando a sintaxe do código. É pura sintaxe, não são classes prédefinidas. Mesmo assim você pode basear seu Framework/Biblioteca em um Préprocessador. O Bootstrap faz isso para facilitar features dinâmicas como grids, cores e etc.

Como eu disse, eu não gosto de misturar as coisas. Prefiro utilizar o Bootstrap puro, sem a interferência de nenhum préprocessador. Mas, há gosto para tudo.

Qual deles é melhor para o meu projeto

Eu não sugiro que você utilize um framework para criar websites institucionais. Websites geralmente não usam os mesmos elementos, nem as mesmas estruturas, nem o mesmo design. Logo, se você utilizasse um framework como o Bootstrap, ou o JQuery UI, você acabaria gastando mais tempo reestilizando e brigando com o CSS já criado dos frameworks do que fazendo o que realmente importa: o seu trabalho.
Logo, para projetos de pequeno porte eu sugiro que você utilize uma biblioteca simples. Sugiro ainda que essa biblioteca seja criada por você.

Não precisa de muito. Em uma biblioteca você só precisa ter algumas propriedades que fazem tarefas básicas, como fazer o elemento flutuar para a esquerda, para direita, clear, retirar margens e etc. Normalmente eu utilizo um reset chamado Normalize. Ele já reseta meu CSS inteiro e então eu me foco apenas nas propriedades que eu reutilizarei no resto do projeto.

Se seu projeto for médio ou grande, você já pode pensar em utilizar um Framework. Principalmente se seu projeto for um sistema. Você já vai ter à disposição estilos para formulários (que são um saco pra fazer), botões, grids, reset CSS e outras coisas. O trabalho fica mais fácil por que você tem menos arestas para acertar. Ainda mais se o designer aceitar utilizar alguns dos estilos já prontos do Framework, assim você não precisa reconfigurar formatações visuais e etc.

A utilização do Préprocessadores é totalmente opcional. Mas se você decidir utilizá-lo juntamente com algum Framework, procure saber se o Framework escolhido suporta algum tipo de préprocessador. O Bootstrap, por exemplo, tem uma versão para LESS.

No próximo artigo vou contar como estamos fazendo aqui na Locaweb. Estamos criando uma grande biblioteca visual e de front-end que será utilizado por todos os serviços. Os programadores conseguem subir um sistema sem precisar esperar um código HTML definitivo, utilizando os módulos dessa biblioteca. A galera de design faz todos os layouts padronizados visualmente, garantindo a uniformidade de todos os sistemas. E o pessoal de front? Bom o pessoal de front cuida para que tudo isso funcione.

Posts Relacionados

Tudo que você gostaria de saber sobre plugins jQuery e ninguém teve paciência de explicar

Zeno Rocha — Wed, 02 May 2012 12:10:14 +0000

Então quer dizer que você anda brincando com jQuery. Volta e meia utiliza uns plugins que mais parecem mágica e se duvidar até se aventurou em criar o seu próprio, acertei?

Acontece que, caso você já saiba desenvolver os seus, talvez possam existir melhores formas de escrevê-lo. Será que você está seguindo as melhores práticas? Será que realmente entende o que está acontecendo por trás de cada linha?

Hoje vou tentar responder as dúvidas mais frequentes, explorando as melhores práticas para se construir um plugin. E no fim lhe mostrar um padrão interessante que você pode seguir agora que já entendeu os conceitos.

A ideia aqui não é simplesmente mostrar como criar um plugin, mas sim como criar direito, explorando tudo o que o jQuery tem de melhor para nos oferecer.

Por que eu deveria construir um plugin?

Encapsulamento e reaproveitamento de código, essas são as palavras-chave. Se você está codificando algo que talvez sirva para futuros projetos, pode ser uma boa encapsular tudo isso em um plugin.

Entendi, quero criar um! Como faz?

Existem diversas formas, mas vamos começar com essa:

1
2
3

$.fn.meuPlugin = function() {
// aqui vem a lógica
};

Esse é o mínimo que você precisa para iniciar o desenvolvimento de um plugin, basta adicionar uma propriedade ao $.fn.

Por mais trivial que isso possa parecer, muita gente não entende o que está acontecendo por trás disso exatamente. Portanto, antes de evoluirmos esse padrão, vamos recorrer ao código fonte da biblioteca, na sua versão mais recente, para entender de verdade esse pequeno trecho de código.

O que significa o cifrão ($) ?

O famoso $ nada mais é do que um “apelido” para o objeto jQuery. Próximo ao fim do código fonte da biblioteca encontramos a seguinte definição:

1	window.jQuery = window.$ = jQuery;

Isso significa que o mesmo objeto em memória pode ser referenciado de diversas formas: window.jQuery, window.$, jQuery ou simplesmente $.

Qual a diferença entre $.meuPlugin e $.fn.meuPlugin?

Possivelmente você já se deparou com plugins que não utilizavam a propriedade .fn. Mas afinal, por que eu deveria utilizar o .fn? Por que não apenas $.meuPlugin ao invés de $.fn.meuPlugin?

Novamente, ao nos aventurarmos no código fonte percebemos, logo nas primeiras linhas, como o objeto jQuery é definido.

1
2
3

var jQuery = function( selector, context ) {
return new jQuery.fn.init( selector, context, rootjQuery );
}

Note que jQuery é uma função e no Javascript uma função é também um objeto do tipo Function. Por isso jQuery.meuPlugin (ou $.meuPlugin) irá atribuir meuPlugin para o objeto jQuery do tipo Function.

Dito isso, voltamos ao código fonte e veremos que jQuery.fn é a mesma coisa que dizer jQuery.prototype.

1	jQuery.fn = jQuery.prototype;

Portanto, a cada vez que você atribuir uma função (ou propriedade) para jQuery.fn, como em $.fn.meuPlugin, a função estará disponível para todas as instâncias desse objeto.

Isso é importante, pois quando você invoca a função $(), como em $(“#algumID”), uma nova instância é criada nessa linha:

1	return new jQuery.fn.init( selector, context );

E essa instância terá todos os métodos que atribuirmos ao prototype, mas não todos os métodos que foram atribuídos direto ao objeto Function.

Logo, vá de .fn.

Evite conflitos

Sabia que existem outras bibliotecas Javascript que também utilizam o símbolo cifrão para referenciar seus objetos? Pois é, isso pode lhe causar uma baita dor de cabeça se utilizar apenas aquele primeiro padrão proposto.

Logo, uma boa prática seria encapsular a lógica do plugin em uma função anônima. Assim, garantimos que não irá haver conflito entre o $ do jQuery com o $ de outras bibliotecas.

1
2
3
4
5

(function( $ ){
$.fn.meuPlugin = function() {
// aqui vem a lógica
};
})( jQuery );

Dessa forma mapeamos o $ para que não seja afetado por nada fora desse escopo.

Não quebre a corrente

Então, você já entendeu como funcionam algumas coisas, vamos criar nosso primeiro plugin! Começaremos com o clássico exemplo de um Tooltip (aquelas caixinhas que aparecem no mouseover).

Criamos então a chamada para o plugin a partir de determinado seletor:

1
2
3

$(function() {
$(".BlaBlaBla").tooltip();
});

E código do nosso plugin ficará definido assim:

1
2
3
4
5

(function( $ ){
$.fn.tooltip = function() {
this.css({ background: 'yellow' });
};
})( jQuery );

Aparentemente tudo certo, já que o plugin funciona direitinho, certo?

Na verdade não, pois dessa forma estamos ferindo um dos princípios importantes que diferem os plugins bons dos ruins, e esse princípio se chama encadeamento.

No jQuery é muito comum vermos declarações do tipo:

1	$('div').show().addClass('BlaBlaBla').fadeIn();

Isso, porque é possível encadear diversas chamadas, a um mesmo seletor. E uma excelente prática por sinal, já que não criamos diversas instâncias como em:

1
2
3

$('div').show();
$('div').addClass('BlaBlaBla');
$('div').fadeIn();

Para permitirmos comportamento similar com nosso plugin basta retornar o this.

1
2
3
4
5
6
7

(function( $ ){
$.fn.tooltip = function() {
return this.each (function() {
$(this).css({ background: 'yellow' });
});
};
})( jQuery );

Assim, além de garantirmos o encadeamento, também manipulamos a coleção passada para o plugin através do método each, muito similar a um loop com for por exemplo.

Como passar parâmetros e lidar com eles depois?

E que tal se evoluíssemos nosso plugin e resolvessemos passar como parâmetro a cor de fundo do nosso elemento.

1
2
3
4
5

$(function() {
$(".BlaBlaBla").tooltip({
'corDeFundo' : 'blue'
});
});

Agora preparamos nosso plugin para receber os parâmetros através da variável options e aplicamos a propriedade corDeFundo no background.

1
2
3
4
5
6
7

(function( $ ){
$.fn.tooltip = function(options) {
return this.each (function() {
$(this).css({ background: options.corDeFundo });
});
};
})( jQuery );

Maravilha, funcionou! Mas o que acontece se você resolve mais tarde não passar como parâmetro a cor de fundo? Nosso plugin quebra.

Portanto, não podemos nos esquecer de que precisamos nos preparar para receber esse conjunto de opções e assegurar que, caso não seja passado nenhum valor como parâmetro, nós possamos lidar com valores padrão.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Para isso recorremos a função $.extend que irá buscar os valores passados pela variável options e mesclar com os valores definidos na variável defaults, armazenando em outra variável chamada settings.

A procura da batida perfeita

Esse é só o começo para você que deseja se aprofundar um pouquinho mais nessa arte de criar plugins, para entender mais visite o guia oficial.

Mesmo que a ideia de se formar um padrão único para criar plugins seja utópico, sugiro fortemente que dê uma olhadinha no jQuery Boilerplate, lá você vai encontrar um padrão bem sólido para iniciar seus projetos, sem contar que a versão traduzida para português foi lançada hoje!

Mas se o buraco for mais em baixo e você for lidar com plugins stateful que controlam o estado dos objetos, confira o jQuery UI Widget Factory.

Lembre-se que o jQuery não é apenas uma caixa preta que faz mágicas pra você. Aventure-se no código fonte e verá que não é nada muito diferente do que você já faz com JavaScript puro.

E é isso, espero que depois desse artigo, você tenha evoluido de um simples “manipulador de plugins” para um criador de fato. Até a próxima!

Mais comentados

jQuery: conheça os métodos on() e off()

Davi Ferreira — Tue, 13 Mar 2012 12:35:42 +0000

Em outubro de 2010 escrevi um artigo aqui mesmo no Tableless sobre a associação dinâmica de eventos. Na época, reinava uma confusão sobre quais métodos utilizar e quando utilizá-los. Eram três as opções: bind(), live() e delegate().

Com o lançamento da versão 1.7 do jQuery, dois métodos definitivos (assim espero) devem acabar com a confusão em torno da associação de eventos: os métodos on() e off().

Eventos diretos

A associação direta de eventos ocorre quando o seletor (ou escopo) é omitido nos parâmetros do on(). Por exemplo:

1
2
3
4
5

function exibeMenu(e) {
e.preventDefault();
$('#menu').show();
}
$('#lnk-menu').on('click', exibeMenu);

No código acima, o elemento com id #lnk-menu recebe uma associação no evento click para executar a função exibeMenu(). A associação ocorre de forma direta, ou seja, quando o on() é executado o evento passa a estar associado ao elemento, antes mesmo do clique ocorrer.

Essa opção equivale ao bind() e deve ser utilizada em casos de elementos únicos, ou com poucos elementos, para evitar problemas de performance.

Múltiplos eventos

Também é possível associar múltiplos eventos a um ou mais elementos. Para isso, basta passar um mapa onde cada chave representa um evento ao invés de um evento como string:

1
2
3
4
5
6
7
8
9
10
11

$('#lnk-menu').on({
click: function(){
$('#menu').show();
},
dblclick: function(){
$('#submenu').show();
},
mouseenter: function(){
$(this).addClass('ativo');
}
});

Removendo associações de eventos diretos

Remover associações de eventos diretos é simples:

1	$('#lnk-menu').off();

Para remover eventos específicos, mantendo qualquer outra associação, basta informar o nome do evento:

1	$('#lnk-menu').off('click');

Eventos delegados

A delegação de eventos (antigos live() e delegate()) ocorre quando passamos um ou mais seletores nos parâmetros do on. O evento não será
associado diretamente quando o código for executado, tampouco será executado para o seletor que chama o on() e sim para os elementos descendentes que se encaixem no parâmetro passado.

A associação ocorre quando o evento é acionado. Esse tipo de associação funciona tanto para elementos já presentes no DOM como para elementos criados posteriormente.

1
2
3
4
5

function exibeConteudo(e){
$(this).find('conteudo').fadeIn();
}

$('table').on('click', 'a', exibeConteudo);

Removendo a associação de eventos específicos

Em alguns momentos será preciso associar eventos diretos e, ao mesmo tempo, delegar eventos. Nesses casos, é possível remover apenas os eventos delegados utilizando o parâmetro especial “**”.

1	$('a').off('click', '**');

Outra opção é remover a associação com base na função utilizada:

1	$('#lnk-menu').off('click', 'a', exibeConteudo);

Namespaces

Uma importante implementação do on() é a possibilidade de utilizar namespaces nos eventos – uma grande novidade para desenvolvedores de plugins. Um evento pode, agora, ser associado a um namespace específico, facilitando o controle sobre associações específicas de um plugin ou uma funcionalidade.

1
2
3
4

$('#lnk-menu').on('click.menu', exibeMenu);
$('.menu-item').on('mouseleave.menu', escondeMenu);

$('#lnk-menu, .menu-item').off('.menu');

Enviando dados para o evento

O método on() também permite enviar dados específicos para um evento. O objeto de dados fica associado ao objeto do evento.

1
2
3
4
5
6

function exibeMenu(e) {
$('.ativo').text(e.data.descricao);
}

$('#lnk-home').on('click', { descricao: 'Página inicial' }, exibeMenu);
$('#lnk-sobre').on('click', { descricao: 'Sobre a empresa' }, exibeMenu);

No exemplo acima, cada link passa uma descrição diferente durante o evento. Essa descrição passa a ser o conteúdo dos elementos com a classe “.ativo”.

Este evento se autodestruirá…

O método .one() poderia ter entrado na lista dos métodos desconhecidos do meu último artigo, já que existe desde a versão 1.1 do jQuery. No entanto, junto com a implementação do .on() ele ganhou uma nova cara.

Sua implementação segue as mesmas regras do .on() com uma importante diferença: o evento associado é executado apenas uma vez. Após a execução a associação é automaticamente removida, seja ela uma associação direta ou delegada.

1
2
3

$('#lnk-menu').one('click', function() {
alert('Este evento não será mais executado.');
});

Caso o seletor possua mais de um elemento, o evento será associado uma vez a cada um deles, ou seja, cada elemento possuirá uma execução do evento.

Essas são as novidades com relação a eventos utilizando jQuery. Os métodos .on() e .off() devem “matar” seus antecessores (.live() e .delegate()) e padronizar de uma vez por todas a associação de eventos em aplicações.

Posts Relacionados

Manipulação de classes com JQuery

Diego Eis — Thu, 01 Mar 2012 13:27:13 +0000

Você já deve saber que o JQuery é coisa linda de Deus. Existe uma linha muito tênue entre as features que o CSS pode fazer e o que o JQuery pode nos ajudar. A manipulação de classes é uma das facilidades que o JQuery proporciona e facilita infinitamente nossa vida. Essas funções nos ajudam muito quando iremos definir um comportamento dinâmico para os elementos.

Formas de manipulação de classes

Você pode manipular as classes de elementos do HTML de quatro formas:

.addClass()
Existem diversas situações onde precisamos adicionar uma ou mais classes em um elemento para executarmos uma ação ou formatarmos o elemento com estilos determinados.

.removeClass()
Remove uma, várias ou todas as classes dos elementos escolhidos.

.toggleClass()
Insere ou remove uma ou mais classes dos elementos determinados, alternando entre classes escolhidas.

.hasClass()
Verifica se qualquer um dos elementos selecionados tem a classe determinada.

.addClass()

Imagine que você queira adicionar uma classe extra o último elemento LI da lista:

1
2
3
4
5

<ul>
<li>Primeiro</li>
<li>Segundo</li>
<li>Terceiro</li>
</ul>

1	$('li:last').addClass('selecionado');

Link do exemplo de ADDCLASS do JQuery

Para adicionar mais de uma classe, basta fazer como fazemos no CSS: separe com espaços o nome das classes. E se você na sabia, sim, da para colocar mais de uma classe em um mesmo elemento HTML.

1	$('li:last').addClass('selecionado ultimo');

Você pode adicionar uma classe no elemento ao clicar nele:

1
2
3

$('li:last').click(function(){
$(this).addClass('selecionado ultimo');
});

Link do exemplo de AddClass com click do JQuery

Você pode ver a documentação completa dessa feature aqui.

.removeClass()

O .removeClass() function da mesma maneira que o .addClass(), só que em vez de colocar uma classe, você a remove. Simples assim.

Ainda usando o exemplo acima, vamos retirar a classe selecionado dos elementos e adicionar apenas no elemento clicado. O JS fica assim:

1
2
3
4

$('li').click(function(){
$('li').removeClass('selecionado');
$(this).addClass('selecionado');
});

Muito simples. Você define qual a classe que vai ser removida e pronto, o JQuery faz isso para você.

.toggleClass()

O toggleClass nos ajudaria muito mais no exemplo aplicado acima. Ele alterna uma determinada classe, adicionando e removendo-a sem a necessidade de IFs ou coisas assim.
Eles detectam se o elemento tem ou não a classe. Se houver a classe, ele a retira, se não, ele adiciona. A sintaxe é a que segue abaixo:

1
2
3

$('li').click(function(){
$(this).toggleClass('selecionado');
});

Link do exemplo

.hasClass()

E por último, o .hasClass. Essa função detecta se o elemento tem ou não a classe, e então, sabendo disso, você pode manipulá-lo da maneira que bem entender. No nosso exemplo abaixo iremos apenas detectar qual dos elementos tem a nossa classe. HTML:

1 2	<p>Este é o primeiro parágrafo.</p> <p class="selected">Este é o segundo parágrafo e tem a classe SELECTED</p>

E o JQuery:

1 2	$("div#result1").append($("p:first").hasClass("selected").toString()); $("div#result2").append($("p:last").hasClass("selected").toString());

Link do exemplo

Para ler a documentação dessas funções, clique aqui.

Posts Relacionados

jQuery: métodos desconhecidos

Davi Ferreira — Tue, 31 Jan 2012 15:30:24 +0000

No meu último artigo falei sobre dicas de otimização e performance de códigos jQuery. Na versão inicial do texto eu havia planejado um tópico sobre os métodos não muito conhecidos, já que alguns, como o ajaxSetup, podem também atuar na performance da sua aplicação.

Acabei descobrindo que este tópico ficaria enorme e, por isso, preferi escrever sobre o assunto em um artigo próprio.

Com vocês, alguns dos métodos menos populares do jQuery!

proxy()

O método proxy() permite executar um outros método forçando um determinado contexto. Seu objetivo principal é evitar a confusão do ‘this’ causada quando um objeto é utilizado dentro de um método de outro objeto.

Por exemplo:

1
2
3
4
5
6
7
8
9
10
11

$(".botao").click(function() {
setTimeout(function() {
console.log(this); //window
}, 400);
});

$(".botao").click(function() {
setTimeout($.proxy(function() {
console.log(this); //.botao
}, this), 400);
});

É possível utilizar o proxy() através de duas assinaturas. A primeira recebe como parâmetros uma função e o escopo. A segunda funciona passando o escopo e o nome do método como uma string.

1 2	$.proxy( funcao(){}, 'objeto' ); $.proxy( 'objeto', 'metodo' );

Quem sabe agora você para de usar o truque do ‘var that = this’, hein?

isArray() e isFunction()

Esses dois métodos fazem parte da família de utilitários do jQuery. Como seus nomes sugerem, o primeiro verifica se o objeto é um array JavaScript e o segundo se o objeto é uma função.

1
2
3
4
5
6

var jogadores = ['Obina', 'Vagner Love', 'Zico'];
var chutar = function(jogador){
console.log("Gol de " + jogadores[jogador]);
};
console.log($.isArray(jogadores)); // true
console.log($.isFunction(chutar)); // true

Uma observação: a função isArray retorna true apenas para verdadeiros Arrays (e não objetos “tipo array”, como um objeto jQuery, por exemplo).

1 2	var jogadores = $('.jogadores'); console.log($.isArray(jogadores)); // false

A lista de utilitários possui outros métodos interessantes, tais como grep(), map(), merge() etc.

queue() e dequeue()

Apesar de terem sido desenvolvidos originalmente para o uso de animações, os métodos queue() e dequeue() podem ser utilizados para qualquer tipo de fila.

A fila padrão é chamada de ‘fx’: essa é a fila das animações. Ela será utilziada caso não seja passado nos parâmetros o nome de uma fila. No exemplo abaixo, estamos criando a fila ‘ajaxRequests’.

1
2
3
4
5
6
7
8
9
10
11
12
13

$(document).queue('ajaxRequests', function(){
$.ajax({
type: 'GET',
url: '/tableless',
complete: function(jqXHR, textStatus){
$(document).dequeue("ajaxRequests");
}
});
});

$(document).queue('ajaxRequests', function(){
$.post('/tableless', {categoria: 'jquery'});
});

Para dar sequência no andamento da fila, você precisa utilizar o método dequeue(). Ele deve ser chamado no final da execução de um processo da fila (e como essa é uma fila de processos AJAX, utilizamos o dequeue no evento complete).

Outro recurso interessante é a possibilidade de saber o tamanho da fila, ou seja, quantos eventos ainda serão executados. Para isso, basta utilizar a propriedade length após o método queue().

1
2
3

$(document).queue('ajaxRequests').length; // 2
$(document).dequeue("ajaxRequests"); // executa fila
$(document).queue('ajaxRequests').length; // 0

detach()

Assim como o remove(), o detach() retira um elemento do DOM. No entanto, esse método guarda as referências, eventos e dados associados ao elemento retornando um objeto jQuery que pode ser re-inserido no DOM.

1
2
3
4
5
6
7
8
9
10
11

$('.link').click(function(e){
e.preventDefault();
console.log('clique');
});
$('.link').click(); // 'clique'
var link = $('.link').detach();
$('body').append(link);
$('.link').click(); // 'clique'
$('.link').remove();
$('body').append('link');
$('.link').click(); // []

ajaxSetup() e afins

Talvez esses sejam os métodos mais injustiçados do jQuery. É muito comum a repetição de chamadas AJAX, incluindo seus parâmetros. Esses métodos de configuração permitem definir valores padrão para qualquer evento AJAX em sua aplicação.

Com o ajaxSetup() é possível, por exemplo, habilitar ou desabilitar o cache e definir o tipo de requisição: POST ou GET.

1
2
3
4
5

$.ajaxSetup({
type: 'POST',
dataType: 'json',
cache: true
});

Você ainda pode configurar uma URL padrão e também parâmetros passados durante a chamada:

1
2
3
4
5
6

$.ajaxSetup({
data: {
origem: 'tableless'
},
url: '/tableless'
});

Para conferir uma lista completa das propriedades configuráveis, visite a página do método AJAX na API do jQuery.

Os callbacks e eventos relacionados à execução de métodos AJAX também podem ser configurados. No entanto, essa configuração deve ser feita através dos seguintes métodos específicos: ajaxStart(), ajaxStop(), ajaxComplete(), ajaxError(), ajaxSuccess() e ajaxSend().

Por exemplo, você poderia utilizar a configuração abaixo para exibir um indicador de carregamento no início da execução de um método AJAX.

1
2
3
4
5
6
7

$('.carregando')
.ajaxStart(function(){
$(this).show();
})
.ajaxStop(function(){
$(this).hide();
});

Você pode associar os eventos a qualquer elemento e o jQuery se encarregará de encontrar e executar todos os métodos associados.

delay()

O método delay() serve para adiar a execução de uma função, método ou animação. Ele é especialmente útil para controlar o tempo de animações.

1	$('.alerta').fadeIn().delay(1000).slideUp();

No exemplo acima, o elemento com a classe “alerta” é exibido através de uma transição fade e, um segundo depois, ocultado através do método slideUp().

replaceWith() e replaceAll()

Imagine que você queira substituir todos os elementos que tenham a classe “pontos”. Com o método replaceWith() fica fácil. O que ele faz é buscar todos os objetos que se encaixem no seletor indicado e substituir seu conteúdo.

1	$('.pontos').replaceWith(' 1 milhão de pontos! ');

O replaceWith() também funciona com elementos que não estejam presentes no DOM, ou seja, você pode criar um objeto jQuery e substituir/manipular seu conteúdo antes de inserí-lo no DOM.

1	$(' ').replaceWith(' Carregando... ');

Da mesma forma, o método replaceAll() também substiui o conteúdo de elementos, mas a origem e o destino são invertidos. Você também pode passar seletores como conteúdo. Nesse caso o funcionamento é um pouco diferente já que o elemento não é clonado e sim movido no DOM.

1 2	$(' Carregamento completo! ').replaceAll('.carregando'); $('.titulo').replaceAll('.carregando');

Note que a diferença dos métodos acima para os métodos tradiconais html() e text() é que o próprio elemento também é substituído e não só o seu conteúdo.

Estes foram alguns métodos que pouca gente conhece ou utiliza. Pode até ser que você nunca tenha sentido falta deles, mas é sempre bom ter umas cartas extras na manga.

E se você gostou, garanto que ao consultar a API do jQuery você descobrirá vários outros métodos desconhecidos, mas que podem ser úteis em algum momento do desenvolvimento dos seus projetos.

Posts Relacionados

jQuery: dicas de otimização e performance

Davi Ferreira — Tue, 10 Jan 2012 10:26:21 +0000

A grande maioria dos desenvolvedores jQuery não se preocupa muito com performance e otimização. Afinal, o mantra do framework, “write less, do more”, envolve esconder a parte feia do Javascript e, muitas vezes, acrescentar camadas desnecessárias.

Neste artigo apresento algumas dicas de como melhorar a performance de sua aplicação jQuery. No entanto, vale lembrar que não é necessário otimizar nenhum código escrito previamente, já que a otimização dificilmente compensará o trabalho.

#1: Mantenha-se atualizado

Procure utilizar sempre a última versão estável do jQuery. A cada nova versão lançada são introduzidas inúmeras melhorias de performance nos métodos do framework.

Da versão 1.3 para a 1.4, por exemplo, houve um ganho de 50% na performance da execução dos testes padrão do jQuery.

Fique ligado nas mudanças. O lançamento de uma nova versão vem sempre acompanhando de notas sobre as novas funcionalidades, um changelog, como este aqui.

#2: Não utilize jQuery!

Em alguns momentos não é necessário utilizar jQuery. Apesar de ser fácil de utilizar e muito mais bonito de ler, o framework é apenas mais uma camada no desenvolvimento, uma “maquiagem” para o Javascript.

Em projetos pequenos você pode, se quiser, abolir totalmente o jQuery: é realmente necessário incluir os ~30kb do framework? Não dá pra resolver com Javascript puro?

Já em projetos maiores, mesmo incluindo o jQuery, em alguns casos é melhor não utilizá-lo. Por exemplo:

1
2
3

size: function() {
return this.length;
},

Acima está o código-fonte do método size, do jQuery. O que ele faz? Nada além de retornar o tamanho do objeto utilizando o método nativo length. Logo, é mais rápido utilizar diretamente o length!

1 2	$('.menu').size() $('.menu').length

O mesmo vale para retornar o ID de um elemento:

1 2	$(this).attr('id') this.id

O seletor $(this), aliás, somente deve ser utilizado quando for necessário um método que só existe no jQuery. Nos outros casos, sempre dê preferência ao this nativo do Javascript.

Também é comum utilizar jQuery para alterar o CSS de um elemento, por exemplo:

1	$('#menu').css('display', 'block');

Olhando o código-fonte do jQuery, o método .css() possui aproximadamente 20 linhas (sem contar outros métodos chamados). A atribuição acima poderia ser executada da seguinte forma, com uma única linha:

1	document.getElementById('menu').style.display = 'block';

Os próprios métodos jQuery possuem camadas dentro do framework. Ao invés de utilizar o método $.getJSON, por exemplo, você pode chamar diretamente o método $.ajax com os parâmetros type: ‘GET’ e dataType: ‘json’.

Vale a pena dar uma olhada no código-fonte do jQuery para entender o que o framework faz por baixo dos panos e até que ponto é válido utilizá-lo.

#3: Seletores

Procure sempre ser o mais específico possível em um seletor. Quanto mais específico, mais rápido. Opte sempre por utilizar o ID do elemento. Mesmo quando for preciso utilizar uma classe no seletor, utilize o ID do elemento pai.

Os seletores que utilizam o ID ou a tag de um elemento são mais rápidos por um simples motivo: ambos utilizam métodos nativos do Javascript document.getElementbyId() e document.getElementsByTagname().

Evite utilizar seletores com atributos e/ou pseudo-seletores, a menos que seja extremamente necessário.

Outra dica importante: dê preferência ao método .find() quando precisar achar elementos filhos de um elemento com ID. Por exemplo, ao invés de $(‘#container p’) utilize $(‘#container’).find(‘p’), dessa forma o escopo da busca fica limitado ao primeiro objeto. O mesmo vale para seletores de classes e pseudo-seletores.

#4: Cache de elementos

Esta é uma dica simples, mas que pode adicionar ganhos de performance consideráveis. Procure sempre armazenar em uma variável o objeto jQuery retornado por um seletor, principalmente quando o seletor está dentro de um loop.

Por exemplo:

1
2
3
4

var menu = $('#menu');
var itens = ['Home', 'Contato', 'Sobre'];
for(x in itens)
menu.append('

'+itens[x]+'

');

Ao invés de:

1
2
3

var itens = ['Home', 'Contato', 'Sobre'];
for(x in itens)
$('#menu').append('

'+itens[x]+'

');

No exemplo acima, o seletor $(‘#menu’) seria executado 3 vezes, ou seja, o elemento seria buscado no DOM três vezes seguidas, sem nenhuma alteração.

Conforme citei na abertura do artigo, cachear seletores é uma prática que vai contra o “write less, do more” do jQuery. Seu código pode ficar um pouco mais “sujo”, mas, em contrapartida, fica também mais rápido.

#5: Encadeamento de métodos

Encadear métodos sempre foi uma das funcionalidades mais legais do jQuery e, se você ainda não faz uso dessa técnica, é por aqui que você deve começar.

1
2
3

$('#container').addClass('corpo');
$('#container').width(940);
$('#container').height(300);

Vira:

1
2
3

$('#container').addClass('corpo')
.width(940)
.height(300);

Quase todos os métodos e plugins retornam (ou deveriam retornar) um objeto jQuery. Além de melhorar a leitura, essa prática também afeta diretamente a performance do seu código já que o seletor só é executado uma única vez.

#6: DOM

Qualquer tipo de manipulação no DOM envolve um processo bem lento. No geral, você deve fugir desse tipo de implementação, principalmente se ela não possuir nenhum tipo de cache.

O ideal é manipular já com os dados finais e completos. Não manipule o DOM em um loop, por exemplo.

Utilizando o exemplo da dica de caching, poderíamos alterar para ficar ainda mais otimizado:

1
2
3
4
5
6
7
8

var menu = $('#menu');
var itens = ['Home', 'Contato', 'Sobre'];
var html = '';
for(x in itens){
html += '

'+itens[x]+'

';
}
menu.append(html);
menu.show();

Repare que o método .append() foi chamado apenas uma vez, já recebendo o HTML completo concatenado.

#7: DRY (Don’t Repeat Yourself)

O jQuery disponibiliza um alto nível de personalização, permitindo que você escreva seus seletores e seus plugins.

Evite repetir blocos de código. Evite repetir seletores. Evite repetir manipulações no DOM (faça tudo o que precisa fazer uma única vez!). Esta é uma dica muito importante para performance, já que qualquer código repetido significa alguns bytes ou kbytes a mais na sua aplicação.

Mathias Bynens disponibilizou um uma apresentação genial sobre DRY e Javascript, vale a pena conferir.

Como medir a performance da sua aplicação?

O site jsPerf permite a criação de testes de performance para códigos javascript, utilizando jQuery ou não. É um bom lugar para você começar a comparar diferentes tipos de implementação. Esta apresentação dá dicas e ensina a utilizar a ferramenta.

Você também pode (e deve) utilizar a aba profile do Firebug e/ou do Chrome Developer Tools. Aqui tem um tutorial antigo, mas bacana, sobre o Firebug e aqui você encontra um tutorial sobre o Chrome Developer Tools.

Posts Relacionados

20 plugins jQuery que marcaram 2011

Davi Ferreira — Thu, 15 Dec 2011 06:29:07 +0000

jQuery Mobile

http://jquerymobile.com

Apesar de não ser um plugin, o jQuery Mobile encabeça nossa lista por ter sido uma das ferramentas mais importantes do ano. O objetivo do framework é disponibilizar uma API simples e compatível com todos os dispositivos móveis. Seu código é quase todo baseado em HTML e sua interface oferece suporte total a operações com toque.

Quicksand

http://razorjack.net/quicksand/

Quem utiliza sistemas e dispositivos da Apple conhece bem a interface simulada pelo plugin Quick Sand, que permite ordenar e filtrar ítens de uma lista, sejam eles ícones, texto ou imagens, utilizando animações e transições.

Reveal

http://www.zurb.com/playground/reveal-modal-plugin

Reveal é mais um plugin para janelas de alerta/informação. Sua instalação é bem fácil, permitindo executar o plugin diretamente via jQuery ou simplesmente utilizando o atributo ‘data-reveal-id’ em um elemento.

jQuery File Upload

https://github.com/blueimp/jQuery-File-Upload

Plugin para upload de arquivos com suporte a múltiplos envios e drag and drop. O plugin oferece ainda uma barra de progressão, cancelamento e resumo de envios, restrições por tipo de arquivo e preview de imagens. Bem completo.

QapTcha

http://www.myjqueryplugins.com/QapTcha/

Quem aí nunca teve dificuldade em reconhecer um captcha? O QapTcha chega para acabar com essa confusão de letras e números, trocando o captcha tradicional por um slider de liberação.

DropKick

http://jamielottering.github.com/DropKick/

O DropKick bombou bastante no Twitter. É um plugin para a criação de menus dropdowns. Assim como plugins de modal, existem milhares de outros plugins para este tipo de menu. O diferencial do DropKick é a facilidade de criação e o ótimo resultado final em todos os navegadores do mercado.

ParallaxSlider

http://tympanus.net/codrops/2011/01/03/parallax-slider/

O ParallaxSlider, na verdade, é um tutorial que acabou resultando em um plugin. No link acima você confere uma explicação completa de todo o desenvolvimento do plugin. Seu objetivo é oferecer uma galeria de fotos que adota o princípio de animação que se popularizou esse ano onde o background acompanha a navegação.

Toast Message

http://akquinet.github.com/jquery-toastmessage-plugin/

Mais um plugin para os fãs de Mac. O Toast Message oferece mensagens informativas no formato que ficou popular com o utilitário Growl. Fácil de implementar e personalizar.

FitText

http://fittextjs.com

Responsive Design está na moda. FitText é um plugin que adapta o tamanho de títulos e textos no geral de acordo com o elemento pai, tornando flexíveis as dimensões da fonte.

jRumble

http://jackrugile.com/jrumble/

jRumble é um plugin para adicionar animações — tremer, vibrar, balançar ou girar qualquer elemento. Ideal para menus e efeitos hover em links. Possui, além das animações, configurações para opacidade e velocidade.

Mosaic

http://buildinternet.com/project/mosaic/

Plugin que permite implementar “boxes deslizantes” de fotos e/ou conteúdo, com animações e tooltips. O plugin teve origem a partir de um tutorial bastante popular.

Isotope

http://isotope.metafizzy.co

Mais um plugin que bombou no Twitter! O Isotope permite a criação de layouts fluidos automagicamente com animações e transições personalizadas.

Zoomooz

http://janne.aukia.com/zoomooz/

Semelhante ao Isotope, o Zoomooz (ê, nome!) permite a criação de boxes e layout fluido com a diferença de também habilitar um zoom fantástico.

jQuery uCompare

http://www.userdot.net/files/jquery/jquery.ucompare/demo/

Já viram aquelas fotos com antes e depois? Este plugin habilita este recurso de forma dinâmica: o usuário pode visualizar a parte que desejar utilizando o mouse.

ArborJS

http://arborjs.org

Arbor é um plugin bacana para a visualização de grafos. Sua API é bem rica com diversos métodos para manipular ítens e o grafo como um todo.

Slides

http://slidesjs.com

“Slides é um plugin de slideshow para jQuery desenvolvido com simplicidade em mente.” E, de fato, o grande diferencial do Slides para outros plugins de slideshow é a simplicidade e facilidade de implementação — isso sem limitar em nada a personalização.

Zoomy

http://redeyeoperations.com/plugins/zoomy/

Plugin que habilita uma ferramenta de zoom em imagens, simulando aquela lente famosa da Apple. Possui callbacks permitindo um alto nível de personalização nos eventos de zoom.

jFormer

http://www.jformer.com

Forms geralmente são os elementos mais mal-tratados em um aplicativo web. O plugin jFormer visa facilitar o desenvolvimento de forms bonitos, paginados e com validações integradas.

DynamicNews

http://www.egrappler.com/rss-driven-dynamic-jquery-news-slider-plugin-dynamic-news/

O plugin DynamicNews permite a integração de um ticker de notícias com funções para anterior e próxima e tooltips.

jRating

http://www.myjqueryplugins.com/jRating

jRating é um plugin altamente personalizável para a implementação de um sistema de votação com jQuery e AJAX. Permite configurar desde o número de estrelas até callbacks onSuccess e onError.

Bônus: jQuery Boilerplate

http://jqueryboilerplate.com

Desenvolvido pelo brazuca Zeno Rocha em parceria com Addy Osmani e Adam J. Sontag, o jQuery Boilerplate é um template inicial para a criação de plugins jQuery e deve estar presente nos bookmarks de qualquer desenvolvedor jQuery.

Para 2012…

Create

http://createjs.org

O plugin Create ainda vai dar muito o que falar. Seu objetivo é oferecer uma interface de edição de conteúdo inline, recurso ainda pouco explorado por desenvolvedores.

nanoScroller

http://jamesflorentino.com/jquery.nanoscroller/

A personalização da barra de scroll foi moda durante um tempo e (ainda bem?) ficou no passado. O plugin nanoScroller oferece um scroll simples, simulando o visual do Mac OS.

Esqueci algum? Deixei de fora aquele plugin que você curtiu muito? Compartilhe com a gente nos comentários!

Posts Relacionados

Formulários e o Metawebdesign – Parte 1

Alysson Franklin — Mon, 24 Oct 2011 11:06:00 +0000

O front-end é uma profissão de uma amplitude imensa. Temos profissionais montando mockups/PSDs, especialistas em acessibilidade, usabilidade, arquitetura da informação, integração com aplicações, designers de interface, application developers. Tem até SEO.

O background do profissional neste momento não importa muito, apenas a afirmação que ele está trabalhando na camada de front-end. Só isso basta para confirmar os papéis acima.

Em muitas empresas o front-end é trabalhado de maneira criteriosa, com separação de tarefas em maior ou menor intensidade, de modo que o processo esteja sempre azeitado e atento aos prazos dos outros times que dependem da interface. Em algumas outras, o responsável pelo código é o unico responsável por fazer tudo isso acima. E isso acontece com frequência.

É o famigerado exército-de-um-homem-só, que em um projeto normalmente é responsável por:

Pesquisa: Fornece dados e insights para o desenvolvimento de todo o projeto – sobre o usuário, suas características, hábitos e necessidades. Apesar de orientada a um projeto específico, essa pesquisa também deve ser constante, oferecendo atualização e embasamento para a criação de novas experiências.
Arquitetura da informação: Organização de informação, entendendo o modelo mental do usuário, para que ele se reflita também no produto final.
Design da interação: Desenhar a interação de forma que ela seja consistente, fácil e auto-explicativa. Entende ros requisitos de usabilidade criados na fase de pesquisa e dominar os padrões de interação que a aplicação deve ter, além de saber lidar com a multiplicidade de devices e plataformas onde a interação ocorre.
Design Visual: Balanceando beleza e comunicação, domina tanto a direção de arte do produto que está sendo desenvolvido quanto o acabamento final dos pequenos detalhes da interface.
Redação: Expressar as ideias, simples ou complexas que o cliente passou para o desenvolvedor em palavras simples e que sejam facilmente entendidas pelos usuários do produto. Este conteúdo vem do cliente, mas não é difícil acontecer do desenvolvedor ser responsável por criar algum conteúdo, seja transformando a linguagem do cliente dentro de um contexto web, deixando-a mais dinâmica e convidativa a leitura, seja pequenos conteúdos que devem ditar padrões visuais para interações do usuário.
Prototipagem: Criação da UI. Isso serve tanto para o estágio inicial do projeto (com protótipos de papel, de baixa fidelidade) quanto para o estágio que precede o desenvolvimento, onde o produto já está mais amadurecido e mais próximo do final. Esta etapa pode ser a da criação das páginas em si, uma vez que os modelos de conceito e interação estão prontos e o design está criado ( sites tipicamente estáticos ou de menor porte ) ou pode ser a fase da criação dos protótipos que devem ir para a integração depois (back-end).
Gerenciamento: Garantir o funcionamento de todas as áreas de entrega da melhor e mais produtiva maneira possivel. E ainda ser o ponto focal com cliente e usuário, quando necessário.

Em um departamento multidisciplinar de UX, no melhor dos mundos, temos atribuições diferentes para diferentes profissionais. Muitas vezes, isso não acontece. Outros casos, não raros, a empresa não está interessada na matéria, ou apenas não tem profissionais que atuam nesta área que se preocupam com o código (e design) que entregam. Vai saber. Em empresas com atribuções de projeto mais estruturadas um departamento de UX conversa claramente com outros áreas, como Arquitetura, DBA, Requisitos, Integração, Testes e Gerência.

No FrontInBH, conversando com os desenvolvedores no final do evento, e também em conversas com devs de todos os cantos, é fácil perceber que empresas com equipes de desenvolvimento reduzidas (SMB, agências, pequenos portais) mantém um ou dois especialistas que acabam fazendo todo o serviço. E estes profissionais acabam por andar entre duas profissões distintas: Designer de Interação e Interfaces ou o Desenvolvedor web.

Vale lembrar que estas duas profissões tem backgrounds muito diferentes. Enquanto os designers lidam com abstração, devs costumam lidar com aobjetividade do código. Disciplinas que vão de Teoria de Cores à Orientação a objetos fazem parte do background destes profissionais, porém é com muito trabalho que são desenvolvidos as especialidades, devido a matérias tão antagônicas.

Algumas das disciplinas que um profissional de web hoje deve saber para atender demandas de projeto

Essa diferença de backgrounds acaba por oferecer barreiras que fazem com que o desenvolvimento e a integração das disciplinas seja muito difícil. E com isso temos profissionais que desenham interfaces e interações lindas, mas que não podem funcionar sob conceitos de acessibilidade, ou ainda websites perfeitamente acessíves e fluídos, mas que não tem um design tão impactante.

Diante deste cenário tenho trabalhado para desenvolver um conceito que chamo de Metawebdesign. A proposta é justamente encurtar estes espaços, sem incomodar profissões importantíssimas e já consolidadas, mas que por razões diversas em algumas vezes acabam por ser a mesma coisa no organograma de uma empresa.

Meu primeiro e segundo artigos sobre o assunto vão falar sobre formulários. Muito já foi falado, e não quero repetir o que já sabemos. Porém é importante mostrar como conceitos de design da interação, arquitetura da informação e código são usados para criar aplicações que oferecem uma experiência inesquecível para o usuário. Estes dois posts iniciais sobre o assunto se transformam em um toolkit muito útil aonde você poderá com a parte 1 e 2 escolher usando conceitos de design os melhores elementos de controle e depois entender como codificá-los de acordo com os padrões do W3C, mantendo usabilidade e acessibilidade.

Aplicando o Metawebdesign a formulários: o design da interface

Cedo ou tarde, a aplicação que você esta criando vai precisar perguntar (ou pedir) ao usuário algum tipo de informação. E sob o ponto de vista do usuário, nesse momento a credibilidade de seu design de interação e código estarão em jogo, pois complexidade e simplicidade aqui separam o céu e o inferno.

Todos sabem como usar alguns elementos de controle como input texts, checkboxes, radio e dropdowns – e isso não somos nós desenvolvedores de aplicações web. Isso é consenso, domínio público: um status quo que todo usuário de computador aprendeu a identificar e saber operar. Mesmo novos usuários entendem estes elementos com uma rapidez impressionante. O problema é como agrupar todos eles em torno de um bem comum – o bem sucedido submit. Afinal de contas, fazer um formulário é simples, basta colocar um bando de informações ordenadas de maneira racional, colocá-las na página com alguma ordenação top-bottom e é isso, correto?

Para começarmos a conversa, isso é o que os usuários esperam.

De acordo com o w3c, um formulário HTML (form) é uma seção do documento HTML que pode conter informação estática, elementos de controle (os mesmos mecionados acima e alguns outros que vamos falar aqui) e labels que referenciam estes controles semanticamente. Tudo isso para permitir que o usuário possa responder (ou preencher) uma série de perguntas que a sua aplicação precisa para prosseguir com o fluxo. E o usuário interage com tudo isso alterando elementos de controle.

Bons e maus exemplos:

Bons exemplos de formulário são fáceis: você mesmo deve conhecer vários; são aqueles que você usa diariamente sem gastar muito tempo ou que não entediam durante seu preenchimento. Maus exemplos são fáceis e estão por todos os cantos da internet, não é difícil encontrar um (na verdade não precisamos nem procurar). Só que não é ético questionar o trabalho de ninguém sem saber as variáveis que levaram aquela implementação. Sendo assim, olha que “bonito” esse formulário que está no site da Apple como exemplo de um mau form.

Acredite: foi difícil até colocar tudo isso em um espaço visível. E ainda nao ficou bom.

Antes de entrarmos de cabeça nos elementos e como formulários devem ser criados, precisamos entender alguns principios básicos de um design de form:

Form Design – O básico:

Tenha certeza que o usuário entende o que e o porque você está pedindo ou perguntando algo;
Escreva labels com palavras que seus usuários possam entender facilmente independente de serem usuários frequentes ou novos usuários, tenha cuidado com os jargões ou acrônimos utilizados. Se necessário, desenhe para o usuário.

exemplo 1 : antes de um grande formulário, tome algum espaço da tela para explicar como ele funciona e o porque você precisa de todas aquelas informações.
exemplo 2: Se você precisa colocar um controle na tela que não é imediatamente óbvio dentro de um fluxo da tela, use uma tooltip ou outro tipo de ajuda que mostre ao usuário o que ele deve fazer em seguida.

Se puder, evite a redundância;
Antes de colocar os campos em uma tela, analise a informação e o contexto de cada um deles e se possível, agrupe informações para minimizar o numero de campos a serem preenchidos. Mesmo no melhor dos cenários, gastar tempo preenchendo caixas de texto não é algo divertido.

exemplo 1: se o usuário já preencheu o endereço de entrega no formulário de checkout, você pode reutilizar esta informação para o endereço de cobrança. Basta adicionar um checkbox perguntando se o endereço de entrega e cobrança são os mesmos que em caso de positivo, você já atendeu aos requisitos.
exemplo 2: Se 80% dos seus usuários estão no Brasil, 15% estão na Argentina e 3% nos Estados Unidos, você pode usar um para atender os requisitos de país. As opções seriam Brasil, Argentina, USA e logo após teríamos lista com a ordenação alfabética.
exemplo 3: Para endereços no Brasil, no
de localização, perguntando apenas o CEP podemos recuperar endereço, bairro, cidade e estado. Com isso faz sentido perguntar primeiramente o CEP, recuperar o valor via webservice e após o sucesso automaticamente preencher estes campos para o usuário.
Existem também exceções: A segurança deve ser levada em conta ao ponderar sobre recursos de auto-completion. Não seria ético tampouco legal recuperar os dados do cartão de crédito do usuário para onerá-lo da tarefa de inputar seus dados bancários, uma das partes mais tediosas e passíveis de erro durante a transação de um checkout.

Informações de conhecimento público normalmente são mais acuradas que informações de conhecimento pessoal; Quando perguntamos algo ao usuário, temos que ter em mente que eles podem mentir (everybody lies) ou mesmo errar. Podemos minimizar isso reduzindo problemas. O sistema de auto-completion com o CEP mencionado acima é um exemplo claro. Um erro simples de digitação pode causar um problemão na hora da entrega: a rua Roda dos Ventos pode virar rua Rosa dos Ventos em um clique. Probabilidade altíssima de problemas futuros que você pode evitar usando este tipo de abordagem.
Tenha cuidado ao transformar os requisitos de design em forms;
A maioria dos forms é criada para manipular transações feitas com o banco de dados ou alterar objetos de uma tela. Explore as dependências entre os elementos, procure por similaridades que possam ser agrupadas graficamente, como campos de endereço ou informações pessoais. O exemplo do endereço de entrega versus o endereço de cobrança mencionado na regra #2 pode ser repetido aqui. Porque não habilitar em um form de inserir produto um drag-n-drop para definir a ordenação das imagens de descrição deste produto ao invés de subir as imagens em uma ordem pré definida ou ainda primeiro subir as imagens para só depois ordenar?
Teste, teste novamente e quando achar que está tudo ok, teste de novo; Por alguma razão que nunca vamos descobrir, é incrivelmente fácil desenvolvedores e usuários terem idéias completamente diferentes quando o assunto é preencher um formulário. O mesmo form! Isso pode acontecer pelos mais variados modos:

conhecimento prévio com interações passadas,
respostas possíveis,
fluxo de página que depende de um contexto que o usuário pode entender de maneira diferente dependo de variáveis externas.

Por isso é importante montar o formulário e se certificar que todas as possibilidades de interação do usuário com os elementos da tela estão garantidas:

preenchimento de campos;
clique/toque em botões e objetos de tela;
entrada de dados validados para atender requisitos de design da aplicação;
condições especiais de uso e interação do form.

Isso nos dá evidência empírica do que funciona e o que nao funciona em sua aplicação, além de claramente indicar o caminho a seguir no caso de identificar um problema.

Escolha sabiamente os elementos de controle: eles impactam a expectativa do usuário sobre o que ele está sendo perguntado e como deve responder a isso:

Os usuários tendem a associar o tamanho e forma física dos campos a o que eles imaginam que seja o que estamos perguntando. Só depois desta associação é que os usuários lêem o que o label de um campo está pedindo.
Uma única radio button vai ser algo ditatorial pois sugere a existência de pelo menos duas opções na tela.
Após você estar acostumado com o processo de compra de sua loja online e seu formulário, automaticamente você irá suavizar sua atenção por não ser uma tarefa nova e sim uma repetição (e daí entendemos o porque a estrada para para erramos um formulário que preenchemos “todo dia” é tão curta)

Escolhendo elementos de controle

Quando estamos montando o design do nosso form temos que nos ater a algumas situações que impactam diretamente todo o formulário:

Espaço disponível na tela: não precisamos falar nada sobre isso. Cada pixel conta e sabemos disso muito bem, então escolha sabiamente como usar os elementos para tirar total proveito da sua área de exibição.
Sofisticação no formulário deve respeitar uso geral dos forms: é algo que todos os usuários estão familiarizados a usar e vão fazê-lo bem, mas nem todo mundo estará confortável em usar um slider de range, com acionamento duplo.
O form deve respeitar o conhecimento público nos domínios da sua app: É aceitável você usar um para um campo que aceita valores entre 0 e 1000. Mas isso iria requerer uma validação para certificar que numeros maiores ou negativos fossem inputados. Se a maior base dos seus usuários está confortável com esta regra, não existe o motivo de usarmos o mesmo slider de range mencionado acima, por todos os problemas de implementação, tempo, acessibilidade e principalmente, dificuldade de uso.
Elementos externos criam expectativas que podem ser erradas: Temos o conhecimento que negrito, itálico e sublinhado são iconografias que foram criadas para dar um destaque a alguma palavra. Fica fora de contexto utilizarmos estas formas para exibir labels por exemplo.

Olha o fast-food “encostando uma arma na sua cabeça” ao perguntar o que é mais saudável.
Tecnologia disponível: o HTML e suas APIs oferecem suporte a muitos elementos de controle, e para os que não são suportados nativamente, existe uma grande gama de toolkits e frameworks que vai te ajudar a implementar aparência e controle em situações específicas.

Elementos de controle de Formulários

Para fazer o design de uma tela de formulário, precisamos de elementos de controle. No jargão do HTML, seriam elementos HTML, que nada mais é que o conteúdo que está dentro de uma tag, podendo inclusive ter outros elementos filho caso seja do interesse. Dito isso, fica muito mais fácil entender como o design trabalha com elementos de controle. Após escolher seus elementos na tabela abaixo, tudo que você precisa é codificá-los seguindo os padrões que já conhecemos.

Montar uma tela de formulário não é complicado. Estamos acostumados a fazer isso todos os dias. Porém existem mais coisas entre o céu e a terra do que pode imaginar a nossa vã filosofia. O tópico acima mostra algumas variáveis que as vezes podem passar desapercebido e podem ajudar – e muito na hora de montar o design da sua tela. Você consegue se imaginar trabalhando orientado ao Responsive Webdesign sem utilizar os conceitos básicos mostrados acima? Pode parecer óbvio, mas é importante manter isso em mente ao utilizar a tabela abaixo:

Elementos de controle em um formulário são divididos em:

Causa	Tipo de interação	Elementos aceitáveis	Prós	Contras
Seleções e listas	Escolhas binárias	Checkbox	Simples e pouco espaço utilizado na tela	Checkbox podem ser usadas para múltiplas escolhas, coisa que usuários já estão acostumados ao visualizá-las. Isso pode levar ao erro, uma vez que é necessário entender que este checkbox único compreende uma escolha sim/não
Seleções e listas	Escolhas binárias	Radio button	Duas opções visíveis. Fácil entendimento do usuário	Espaço de tela usado maior que checkboxes únicas
Seleções e listas	Escolhas binárias	Dropdown	Duas opções visíveis. Pouco espaço utilizado na tela. Permite expansão para múltiplas opções facilmente utilizando pouco espaço da tela	Apenas uma opção é visualizada por vez. Requer alguma destreza no uso de formulários. Pode oferecer desafios de acessibilidade a pessoas com deficiência ou que preferem navegação pelo teclado.
Seleções e listas	Escolhas binárias	Toggle Buttons Iconográficos	Mesmos prós do checkbox, desde que a opção seja mostrada como ícone visual	Mesmos contras o checkbox, além do fato que não é uma opção padrão para seleção de texto como checkboxes.
Seleções e listas	Escolhas binárias	Menu com Radio button	Espaço mínimo utilizado na tela uma vez que o menu é encontrado em barras ocultas de menu ou lightboxes.	Requer muita destreza para encontrá-los e utilizá-los. Necessitam de indicações para que sejam fáceis de ser encontrados em uma tela.
Seleções e listas	Escolha 1 de N para poucas opções	Radio button	Todas as opções estão sempre disponíveis na tela.	Utiliza um espaço considerável na tela.
Seleções e listas	Escolha 1 de N para poucas opções	Dropdown	Pouco espaço utilizado na tela.	Enquanto o menu nao está expandido, mostra apenas uma das opções. Novamente requer alguma destreza para operá-lo e pode tambem oferecer desafios de acessibilidade.
Seleções e listas	Escolha 1 de N para poucas opções	Toggle Buttons Iconográficos	Pouco espaço utilizado na tela. Todas as opções estão visíveis na tela.	Os ícones podem precisar de tooltips para descrição, uma vez que a imagem pode não ser de fácil entendimento para todos os usuários.
Seleções e listas	Escolha 1 de N para poucas opções	Menu com Radio button	Espaço mínimo utilizado na tela uma vez que o menu é encontrado em barras ocultas de menu ou lightboxes.	Requer muita destreza para encontrá-los e utilizá-los. Necessitam de indicações para que sejam fáceis de ser encontrados em uma tela.
Seleções e listas	Escolha 1 de N para poucas opções	Listbox	Muitas opções podem ser visíveis. O frame de seleção pode ser reduzido para até 3 items, permitindo scroll	Espaço de tela usado maior que dropdowns ou spinners. Necessita aplicação de padrões de seleção, permitindo seleção única apenas.
Seleções e listas	Escolha 1 de N para poucas opções	Spinner	Pouco espaço utilizado na tela.	Apenas uma opção é visualizada por vez. Requer muita destreza no uso de formulários e conhecimento deste elemento, pouco utilizado até o lançamento dos novos input types no HTML5. Pode oferecer desafios de acessibilidade a pessoas com deficiência, que preferem navegação pelo teclado ou ainda usuários com ponteiros (mouse) já que a área de clique é mínima.
Seleções e listas	Escolha 1 de N para muitas opções	Dropdown	Pouco espaço utilizado na tela.	Apenas uma opção é visualizada por vez. Requer muita destreza no uso de formulários. Pode oferecer desafios de acessibilidade a pessoas com deficiência, que preferem navegação pelo teclado ou ainda usuários com ponteiros (mouse) já que a área de scroll é mínima.
Seleções e listas	Escolha 1 de N para muitas opções	Listbox	Muitas opções podem ser visíveis. O frame de seleção pode ser reduzido para alguns items de modo a ganhar espaço (permitindo scroll)	Espaço de tela usado maior que dropdowns. Necessita aplicação de padrões de seleção, permitindo seleção única apenas.
Seleções e listas	Escolha 1 de N para muitas opções	Treeview	Muitas opções visíveis inicialmente, pode oferecer facilidades na cognição já que seus items estarão categorizados por níveis ou tipos (pastas)	Grande espaço utilizado na tela. Requer muita destreza no uso de formulários.
Seleções e listas	Escolha N de N para muitas opções	Array de checkboxes	Todas as opções estão sempre disponíveis na tela.	Grande espaço utilizado na tela.
Seleções e listas	Escolha N de N para muitas opções	Array de Toggle Buttons Iconográficos	Pouco espaço utilizado na tela. Todas as opções estão visíveis na tela.	Os ícones podem precisar de tooltips para descrição, uma vez que a imagem pode não ser de fácil entendimento para todos os usuários.
Seleções e listas	Escolha N de N para muitas opções	Menus com Checkboxes	Espaço mínimo utilizado na tela uma vez que o menu é encontrado em barras ocultas de menu ou lightboxes.	Requer muita destreza para encontrá-los e utilizá-los. Necessitam de indicações para que sejam fáceis de ser encontrados em uma tela.
Seleções e listas	Escolha N de N para muitas opções	Listbox	Muitas opções podem ser visíveis. O frame de seleção pode ser reduzido para alguns items de modo a ganhar espaço (permitindo scroll)	Todas as opções não estão disponíveis na tela, requerendo scroll. Usuário precisa de indicações de que a caixa permite múltiplas seleções. Requer muita destreza no uso de formulários. Pode oferecer desafios de acessibilidade.
Seleções e listas	Escolha N de N para muitas opções	Treeview	Muitas opções visíveis inicialmente, pode oferecer facilidades na cognição já que seus items estarão categorizados por níveis ou tipos (pastas)	Grande espaço utilizado na tela. Requer muita destreza no uso de formulários.
Seleções e listas	Escolha N de N para muitas opções	Listbuilder	Items selecionados são de fácil visualização. Pode permitir fácil expansão para escolha e ordenação de items. Lida facilmente com grandes listas.	Grande espaço utilizado na tela. Funciona bem para grandes listas com poucas seleções. Muitas seleções oferecem dificuldades na visualização.
Seleções e listas	Criando listas não ordenadas	Caixa com botão de adição/novo	Ação de adicionar registro é visível e óbvia para o usuário	Grande espaço utilizado na tela. Visualmente bagunçado quando usuário insere muitos items.
Seleções e listas	Criando listas não ordenadas	Caixa com edição in-place	Menor uso de tela. A adição é feita in-place, dentro da caixa	Ação de adição não é tão óbvia quanto a caixa com botão de adição
Seleções e listas	Criando listas não ordenadas	Caixa com edição drag-n-drop	Visualmente elegante e de fácil entendimento, uma vez que arrastar é uma ação intuitiva	Necessita de indicações que mostram que na caixa existe uma área de arrastar.
Seleções e listas	Criando listas ordenadas	Caixa com botões acima/abaixo para ordenação	Ações de rearranjo sempre visíveis na página.	Grande espaço utilizado na tela.
Seleções e listas	Criando listas ordenadas	Caixa com drag-n-drop de items	Visualmente elegante e de fácil entendimento, uma vez que arrastar é uma ação intuitiva	Necessita de indicações que mostram que na caixa existe uma área de arrastar.
Texto	Inputs para uma linha de texto	Textbox	–	–
Texto	Múltiplas linhas de texto não formatado	Textarea	–	–
Texto	Múltiplas linhas de texto formatado	Textarea que permite tags inline	Usuários avançados podem evitar o uso da toolbar inputando as tags diretamente	Não é realmente um editor WYSIWYG
Texto	Múltiplas linhas de texto formatado	Editor Rich text	Texto inputado já serve de preview.	Nao permite edição apenas pelo teclado. É necessário o uso da toolbar para adicionar as tags necessárias.
Números	Números com qualquer tipo de formato	Textbox com máscaras	Visualmente elegante e permite qualquer tipo/formato de tipos de dado	Requer validação no back-end.
Números	Números com qualquer tipo de formato	Textbox estruturado e com máscaras	Formato dos dados é explícito, facilitando preenchimento e entendimento do usuário	Pode requerer grande espaço na tela. Também não permite inputs diferentes dos previstos, mesmo que o usuário deseje isso.
Números	Números com qualquer tipo de formato	Spinner	Permite input sem o uso de teclado caso deseje o usuário	Apenas uma opção é visualizada por vez. Requer muita destreza no uso de formulários e conhecimento deste elemento, pouco utilizado até o lançamento dos novos input types no HTML5. Pode oferecer desafios de acessibilidade a pessoas com deficiência, que preferem navegação pelo teclado ou ainda usuários com ponteiros (mouse) já que a área de clique é mínima.
Números	Números dentro de um limite pre-definido	Slider	Metáfora óbvia, valor é mostrado de acordo com a posição do marcador. Usuário não pode inputar números fora deste range	Pode requerer grande espaço na tela. Labels muito grandes podem se transformar em um problema também
Números	Números dentro de um limite pre-definido	Spinner	Pouco espaço utilizado na tela, permite inputs direto pelo teclado e tambem via clique	Não é familiar para todos os usuários. Pode oferecer desafios de acessibilidade a pessoas com deficiência, que preferem navegação pelo teclado ou ainda usuários com ponteiros (mouse) já que a área de clique é mínima. Requer validação no back-end.
Números	Números dentro de um limite pre-definido	Textbox com validação pós-input	Familiar ao usuário, pouco espaço utilizado na tela, acesso via teclado.	Requer validação no back-end. Range não é visível para o usuário, requer indicações dos limites para input.
Números	Números dentro de um limite pre-definido	Slider com textbox	Permite inputs visuais(slide) e numéricos(input manual)	Complexo, requer validação dos inputs no textbox.
Números	Criando um subrange dentro de um range maior	Slider duplo	Menor uso de tela quando comparado com 2 sliders.	Não é familiar para a maioria dos usuários. Problemas graves de acessibilidade porque não permite inputs via teclado.
Números	Criando um subrange dentro de um range maior	2 Sliders	Utilização mais fácil que um slider duplo.	Grande espaço utilizado na tela. Problemas graves de acessibilidade porque não permite acesso via teclado.
Números	Criando um subrange dentro de um range maior	2 Spinners	Pouco espaço utilizado na tela, permite inputs direto pelo teclado e tambem via clique	Não é familiar para todos os usuários. Requer validação no back-end. Não permite visualização do range maior.
Números	Criando um subrange dentro de um range maior	Textbox com validação pós-input	Familiar para o usuário, ocupa menos espaço que sliders	Requer validação e é necessário informar o range de alguma maneira para o usuário.
Data / Horário	–	Textbox com máscaras	Visualmente simples, permite amplo range de formatos. Permite acesso via teclado	Requer validação back-end. Pode causar confusão no formato data/hora por não haver indicações explicitas.
Data / Horário	–	Textbox estruturado e com máscaras	Formato dos dados é explícito, facilitando preenchimento e entendimento do usuário	Pode requerer grande espaço na tela. Também não permite inputs diferentes dos previstos, mesmo que o usuário deseje isso.
Data / Horário	–	Datepicker	Metáfora óbvia, calendário é exibido e a seleção do valor faz o input	Grande espaço utilizado na tela. Pode oferecer problemas de acessibilidade caso não se permita acesso via teclado.

Seleções e listas:

Seleções binárias: sim/não, ativo/inativo, etc;
Escolha de UM item para N com poucas e muitas opções;
Escolha de N items para N com poucas e muitas opções;
Listas não-ordenadas;
Listas ordenadas.

Texto:

uma linha de texto;
múltiplas linhas de texto não formatados e formatados

Números:

com qualquer formato;
dentro de um range (limite);
subrange (sublimite);

Data e hora.

Use a tabela acima para escolher os melhores elementos de tela de acordo com sua necessidade. Você perceberá que as opções cobrem todas as necessidades atuais, alinhadas ao HTML5.

Padrões para Elementos de Controle

Os elementos de controle acima necessitam de padrões de funcionamento. Estes padrões mostram:

Como combinar elementos;
definir relações estruturais entre elementos;
controlar mudanças de valores e como estes valores são alterados

Alguns elementos de controle possuem requisitos de funcionamento que já estão aplicados ao elemento em si (spinners ou datepickers já possuem seu comportamento nativo no elemento graças ao HTML5). Outros necessitam de programação no back-end, seja para validação, seja para a criação de ranges, seja para outras necessidades específicas. Quanto mais versátil o elemento, maior a possibilidade de usá-los. Um bom exemplo seriam input type=”text” que com frequência possuem funcionalidades específicas, alem de aceitar qualquer coisa textual.

Máscaras:

Máscaras permitem texto em qualquer formato ou sintaxe, fazendo com que o input do usuário seja interpretado de maneira inteligente, a medida que é digitado no campo.

Máscaras são usadas quando sua interface necessita de dados que usuários podem inputar usando qualquer tipo específico de conteúdo, porém não possuem a obrigação de conhecer estes formatos automaticamente:

remover espaços,
inserir apenas números (ou texto),
texto sempre em caixa alta (ou caixa baixa),
abreviações, etc.

Usuários querem que a ação (submeter o formulário) aconteça, não querem (nem devem) se preocupar com formatos corretos e interfaces complexas. Jacob Nielsen já dizia que “Usabilidade na web passa pelo fato de que como desenvolvedores de interface, não podemos deixar o usuário pensar demais para fazer uma ação. Ele simplesmente tem que fazê-la de maneira cognitiva”. Máscaras podem inclusive remover a necessidade de dicas no input ou dicas no prompt.

Formato estruturado:

Estruturar um campo de input significa quebrar um campo em vários outros, de modo a facilitar o entendimento do que é esperado que o usuário faça. Um bom exemplo seria quebrar um campo único de CEP por exemplo em dois campos, um para os primeiros 5 números, e outro campo para os 3 restantes. Outros exemplos podem ser mencionados: números de telefone, numeros de cartão de crédito (cartões AMEX tem um numero de caracteres diferente de cartões VISA por exemplo).

Fill-in-the-blanks: Combine um ou mais campos de modo a permitir que o usuário possa categorizar o que está inputando, facilitando a ação do usuário. Um bom exemplo seria um formulário de pesquisa em uma loja virtual:

Usar esta abordagem faz com que a interface seja auto-explicável. Ajuda ao usuário entender o que está acontecendo e o que foi pedido para ele.

Dicas no input: As dicas no input são importantes para fornecer um guideline ao usuário de como ele deve inputar valores dentro de um campo. O exemplo abaixo, retirado de um form do site dos correios para rastreamento de objetos ilustra bem isso.
Placeholder no input: O placeholder é um texto adicionado dentro do input e que automaticamente desaparece quando o usuário posiciona o cursor da tela dentro do campo. Um bom exemplo pode ser visto no form de busca das páginas do portal globo.com.
Auto complete: O nome é auto-explicativo. A medida que o usuário vai digitando caracteres, os termos são auto-completados, fazendo com que o input seja mais rápido caso o resultado esteja disponível no índice usado. Veja o form de search no site do google.com.br
Dropdown chooser: Dropdowns podem ser usadas para acomodar seleções que podem utilizar um grande espaço na tela quando expandidas, porém não tem a necessidade direta de deixar todas as opções disponíveis (que usualmente são muitas). Um bom exemplo é a dropdown de seleção de cores no Google Docs.
Seleção ilustrada: Em alguns casos descrever a opção não é suficiente. É necessário ilustrá-la com uma imagem para facilitar a seleção do usuário. Um bom exemplo é esta dropdown de seleção de papel de parede disponível no site do livro Designing with Progressive Enhancement.
List Builder: Quando você precisa criar uma lista de items oriundos de uma outra lista, o listbuilder é o padrão ideal a ser usado. Duas textareas e programação fazem com que valores possam ser adicionados ou removidos, além de também poderem ser ordenados facilmente. Veja este exemplo de listbuilder para a configuração de uma toolbar:

Mensagens de erro:
Quando o usuário faz algo correto ele recebe um feedback de sucesso, informando que o formulario foi submetido sem problemas. Mas também é necessário informar de maneira clara quando algo dá errado. Mensagens de erro podem ser customizadas de modo a evitar deixar o usuário “no escuro” quando algum erro acontece. Campos obrigatórios precisam de validação (agora mais simples com o atributo required presente no HTML5), mas podem acontecer outros erros que necessitam de feedback claro para indicar quais os próximos passos a seguir.

Você pode usar o poster abaixo como referência para criar suas interfaces. Clique na imagem para vê-la em uma maior resolução.

Na próxima semana, com a Parte 2, a abstração dá o lugar ao código para saber como montar os items que você selecionou para montar seus formulários, transformando os dois posts em um toolkit para o dia-a-dia. Namastê!

Referências

Metawebdesign – Quando o Front-end se encontra com a experiência do usuário: http://www.slideshare.net/AlyssonFranklin/metawebdesign-frontend
O Metawebdesign – http://metawebdesign.org
Designing Interfaces – Second Edition (Jenifer Tidwell- O’Reilly books) http://designinginterfaces.com/
Top-down e bottom-up design: http://en.wikipedia.org/wiki/Top%E2%80%93down_and_bottom%E2%80%93up_design
Everybody lies, uma frase do House: http://www.youtube.com/watch?v=nNOExDrsdbg
W3C sobre formulários: http://www.w3.org/TR/html4/interact/forms.html#h-17.1
http://www.mhavila.com.br/topicos/web/controles.html
Spinner: http://www.jgeppert.com/jquery-spinner/
A Form of madness: http://diveintohtml5.org/forms.html
Responsive webdesign: http://www.alistapart.com/articles/responsive-web-design/
Composição de um time multidisciplinar de UX - http://itweb.com.br/blogs/a-composicao-de-um-time-multidisciplinar-de-ux/
UX Team of One - http://www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one

Posts Relacionados

Testando seu código jQuery com Jasmine – Parte 2

Davi Ferreira — Tue, 04 Oct 2011 14:12:30 +0000

Jasmine é um framework para testes focado em BDD (Behavior Driven Development). Na primeira parte deste artigo aprendemos seus métodos básicos e realizamos alguns testes simples. Agora chegou a hora de ir um pouco além e conhecer técnicas mais avançadas.

Vale lembrar que, em nossos exemplos, utilizamos uma versão modificada da biblioteca, adaptada para jQuery: jasmine-jquery.

Utilizaremos os dados de um outro artigo, Conteúdo sob demanda com jQuery. O objetivo é testar as solicitações AJAX do carregamento da lista de tweets do Tableless.

Fixtures

Antes dos testes propriamente ditos vamos conhecer uma forma prática de carregar nosso conteúdo HTM. Fixtures são arquivos carregados através do método loadFixtures. Esta funcionalidade, aliás, está disponível apenas no jasmine-jquery.

Vamos salvar o código HTML abaixo no arquivo tweets.html, dentro do diretório de fixtures.

1
2
3
4
5

id="container">
>Tweets do Tableless>
id="lista-tweets">>
> href="#" id="carrega-tweets" data-pagina="1">Mais!>>
>

Por padrão, o jasmine-jquery procura as fixtures no diretório spec/javascripts/fixtures. Como na primeira parte do artigo indicamos uma estrutura diferente, utilizando o diretório spec/fixtures, precisamos atualizar a propriedade fixturesPath nas configurações do Jasmine.

1
2
3
4
5
6
7
8
9
10
11

jasmine.getFixtures().fixturesPath = 'spec/fixtures/';

describe('Exibição dos últimos tweets do Tableless', function(){
beforeEach(function(){
loadFixtures('tweets.html');
});

it('Deve carregar na primeira página', function(){
expect($('#carrega-tweets').data('pagina')).toEqual(1);
});
});

Outra forma de utilizarmos fixtures é carregando diretamente no código, sem a necessidade de um arquivo HTML. Esse caso é mais indicado para templates mais simples, com poucos elementos.

1	setFixtures(' ');

Testando código assíncrono

Testar código AJAX pode ser um pouco mais complicado. No nosso exemplo, como acessamos uma URL externa à nossa aplicação, o tempo de resposta vai depender de vários fatores, como velocidade da conexão, estabilidade do Twitter etc.

Os métodos runs e waits são úteis para tentar simular esse tempo de carregamento. O runs executa os testes e funções um escopo próprio e, além disso, são executados em sequência (quando um termina, o outro começa). Já o método waits funciona como uma espécie de pausa/sleep e recebe como parâmetro o tempo em milissegundos.

1
2
3
4
5
6
7
8
9

it('Deve carregar os últimos 20 tweets', function(){
runs(function(){
Tableless.retorna_tweets(1);
});
waits(1500);
runs(function(){
expect($('#lista-tweets li').length).toEqual(20);
});
});

Espionando métodos

Às vezes precisamos testar se um método de um objeto é chamado (e com que parâmetros) — e não testar apenas seu resultado. O Jasmine oferece a função spyOn para capturar e validar essas chamadas. O spyOn recebe dois parâmetros: o objeto e o nome do método.

1
2
3
4
5

it('Deve executar função para retornar tweets', function(){
spyOn(Tableless, 'retorna_tweets');
Tableless.retorna_tweets(1);
expect(Tableless.retorna_tweets).toHaveBeenCalledWith(1);
});

Acima testamos se o método foi chamado com o parâmetro 1 (página). Poderíamos ter utilizado também toHaveBeenCalled, testando apenas a chamada. As funções de spy podem ainda ser combinadas com o not, por exemplo:

1	expect(Tableless.retorna_tweets).not.toHaveBeenCalled();

Matchers personalizados

Outra funcionalidade poderosa do Jasmine é a possibilidade de criação de matchers personalizados. Os matchers são asserts para seus tests. No exemplo abaixo, criamos o matcher toBeATweet para validar se um elemento possui a classe “tweet”.

1
2
3
4
5
6
7

beforeEach(function(){
this.addMatchers({
toBeATweet: function(){
return this.actual.hasClass('tweet');
}
});
});

1	expect($('#lista-tweets li:first')).toBeATweet();

O método addMatchers deve ser executado dentro do beforeEach, utilizando o Jasmine como contexto. Notem que ele recebe um objeto que pode conter um ou mais matchers personalizados. No código, this.actual representa a variável, elemento, ou objeto que estará sendo passado ao expect.

Outros projetos utilizando Jasmine

Nesses dois artigos vocês conheceram o jasmine-jquery, mas existem diversos outros projetos baseados no framework Jasmine, incluindo adaptações para NodeJS, Rails e iPhone e snippets para Vim e TextMate. A lista completa você confere no wiki do projeto no Github.

Referências

Posts Relacionados

Testando seu código jQuery com Jasmine – Parte 1

Testando seu código jQuery com Jasmine – Parte 1

Davi Ferreira — Mon, 12 Sep 2011 14:08:39 +0000

Durante muito tempo testar/debugar JavaScript era uma tarefa árdua (infelizmente, em alguns navegadores, ainda é). Quem aí se lembra do tempo em que não existia Firebug, por exemplo? E o tamanho dos scripts? Um simples menu drop-drown possuía umas 1.500 linhas de código. Não existia jQuery ou qualquer outro tipo de framework. Tempos difíceis.

Hoje a tarefa do desenvolvedor é muito mais fácil. Para debug temos o já citado Firebug e o Developer Tools do Chrome, entre outros. Nos testes, além do Jasmine, outro framework bem legal é o QUnit. O Jasmine, por focar em BDD, possui uma sintaxe mais fluida. Quem programa em Ruby/Rails vai notar a enorme semelhança com a ferramenta RSpec.

Nos exemplos vou utilizar uma versão modificada do Jasmine, jasmine-jquery. Ela possui alguns métodos próprios para o framework além de funções para carregar fixtures (templates).

Baby steps

Começar a trabalhar com uma cultura de testar sempre antes de desenvolver é bem difícil, principalmente para quem já está acostumado a programar antes e testar depois (manualmente). Comece devagar, sem medo. No início as coisas serão um pouco confusas, mas depois de adotar essa prática, você vai se perguntar como era possível programar sem testes.

O que testar e que testes escrever? Isso também vem com o tempo. Comece testando uma ou outra funcionalidade principal de um aplicativo já existente. Entenda como funciona a sua ferramenta de testes. Depois de um tempo comece a acreditar e confiar na sua intuição.

Procure sempre utilizar um conjunto variado de possibilidades, desde as mais óbvias até as mais inusitadas. Pense nos diferentes contextos, em tudo que interage com seu aplicativo: navegadores, sistemas operacionais, usuários, dados de entrada, scripts de terceiros etc.

Testes não evitam que seu software, uma vez finalizado, tenha bugs; não são a solução para todos os seus problemas de deploy, mas facilitam bastante essas etapas.

Red → Green → Refactor

O padrão básico a ser seguido é o seguinte:

Escreva o teste — naturalmente, ele vai falhar;
Escreva, sem se preocupar muito com qualidade, o código mais simples, que faça o teste passar;
Reescreva seu código, implementando melhorias de performance, escalabilidade e removendo duplicidades.

Configurando o jasmine-jquery

Baixe a última versão do jasmine-jquery e vamos começar com nossos primeiros testes. A estrutura de pastas do nosso aplicativo deve ficar da seguinte maneira:

1
2
3
4
5
6
7
8
9
10

- /
- /tests
- /lib
- /spec
- /fixtures
- /suites
- saudacao-spec.js
- /vendor
- SpecRunner.html
- tableless.js

Note que criamos um diretório “tests” onde ficarão todos os arquivos dos nossos testes, incluindo a biblioteca Jasmine. O arquivo SpecRunner.html é o responsável por executar e exibir os resultados dos testes, basta abri-lo no navegador. Dentro do diretório “tests/spec” ficarão nossos conjuntos de testes (suites) e nossos templates HTML (fixtures).

No início do SpecRunner ficam as chamadas para os testes:

1	<script type="text/javascript" src="spec/suites/saudacao-spec.js">script>

Você também pode incluir aqui qualquer javascript personalizado necessário para os testes. No nosso caso vamos incluir o arquivo tableless.js, que fica na raiz do nosso aplicativo.

1	<script type="text/javascript" src="../tableless.js">script>

Nosso primeiro teste

Vamos supor o seguinte: uma página deve exibir uma mensagem de boas-vindas para o usuário que varia de acordo com o horário. De 5 da manhã ao meio-dia, exibe “Bom dia!”; de meio-dia até 6 da tarde, exibe “Boa tarde!”; de 6 à meia-noite, exibe “Boa noite!”; e, por fim, de meia-noite até 6 da manhã exibe “Dormir é para os fracos!”. A mensagem fica sempre dentro de um elemento div com id “mensagem”. Os horários vão desde a hora inicial (incluída) até a hora final. A função pode receber como parâmetro uma hora no formato hh:mm ou, caso não receba nada, exibe a mensagem de acordo com a hora do usuário.

Esse é um bom começo para seus testes, tente escrever, em um parágrafo, o que deve ser executado e o que é esperado. Trabalhe sempre com um pedaço de papel por perto, para rascunhos.

Vejamos como ficaria o desenho inicial dos nossos testes. Crie o arquivo /tests/spec/suites/saudacao-spec.js e digite o seguinte código:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

describe('Exibição da mensagem de boas-vindas', function(){
beforeEach(function(){
setFixtures('

');
this.mensagem = $('#mensagem');
});

afterEach(function(){
this.horas = [];
});

it("Deve exibir 'Bom-dia!' entre 5:00 e 11:59", function(){
});

it("Deve exibir 'Boa-tarde!' entre 12:00 e 17:59", function(){
});

it("Deve exibir 'Boa-noite!' entre 18:00 e 23:59", function(){
});

it("Deve exibir 'Dormir é para os fracos!' de 00:00 a 04:59", function(){
});

it("Deve exibir, por padrão, a mensagem de acordo com a hora do cliente", function(){
});
});

Na raiz do aplicativo, crie um arquivo chamado “tableless.js”. Nele nós escreveremos nossa função para exibir a mensagem de acordo com a hora. Sua estrutura inicial é a seguinte:

1
2
3

function saudacao(hora_atual){
var hora;
}

Os conceitos básicos dos nossos testes giram em torno de três funções: describe, it e expect. Outras funções úteis, mas que nem sempre estarão presentes, são as funções beforeEach e afterEach. Também trabalhamos com uma função do jasmine-jquery, a setFixtures — falarei mais sobre ela na parte 2, por enquanto você só precisa saber que ela define templates/elementos no DOM.

describe — representa um conjunto de testes/comportamentos. Podem existir situações dentro de situações, por exemplo:
1
2
3
4
5
6
7
describe('Login', function(){
describe('Sucesso', function(){
});

describe('Falha', function(){
});
});
it — define um teste, uma ação. Por exemplo, “It should validate the username”, ou, “Deve validar o nome do usuário”, seria uma boa situação para nosso teste de login.
expect — espera que alguma variável ou retorno de função seja igual a alguma coisa, ou verdadeiro, ou falso etc. Nos testes acima utilizamos apenas um tipo de validação, o matcher “toEqual”. Todo o teste deve ser chamado com a função expect, utilizando um dos matchers disponíveis (mais sobre eles na parte 2). Os principais são: toEqual, toContains, toBeTruthy e toBeFalsy.
beforeEach — executada antes de cada teste dentro de um conjunto, muito útil para configurar elementos.
afterEach — executada depois de cada teste dentro de um conjunto, ideal para reiniciar variáveis.

Escrevendo os testes

Agora chegou a hora de preencher os nossos testes. Os testes que verificam a mensagem entre uma hora e outra seguirão um mesmo padrão. Dado um conjunto de horas válidas, a função saudacao deve retornar a mensagem correta.

1
2
3
4
5
6
7

it("Deve exibir 'Bom-dia!' entre 5:00 e 11:59", function(){
this.horas = ['05:00', '09:33', '10:22', '11:59'];
for(i in this.horas){
saudacao(this.horas[i]);
expect(this.mensagem.text()).toEqual('Bom-dia!');
}
});

O teste que valida o retorno da função saudacao sem passagem de parâmetro busca a hora do cliente e exibe a mensagem de acordo com ela.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

it("Deve exibir, por padrão, a mensagem de acordo com a hora do cliente", function(){
var data = new Date;
data.setTime(data.getTime());
var hora = data.getHours();

saudacao();

var texto = this.mensagem.text();
if(hora < 5)
expect(texto).toEqual('Dormir é para os fracos!');
if(hora < 12)
expect(texto).toEqual('Bom-dia!');
else if(hora < 18)
expect(texto).toEqual('Boa-tarde!');
else
expect(texto).toEqual('Boa-noite!');
});

Nesse momento, abrindo o SpecRunner no navegador, todos os nossos testes estarão falhando. Lembra da nossa regra? Red (falhou), Green (passou) e Refactor.

A função saudacao()

Abaixo segue a minha implementação da função saudacao(). Não me preocupei muito com repetições e performance. Meu objetivo principal era fazer o teste passar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Atualizando nossa SpecRunner veremos agora que todos os testes estão passando. Você pode (e deve) desenvolver aos poucos. Valide um teste de cada vez. Desenvolva com calma.

Melhorando nosso código

Como de praxe, vou deixar um dever de casa para vocês: a etapa de refactoring. O que podemos melhorar na nossa função saudacao()? E se o usuário passar uma hora atualmente inválida para nossa função, como “meio-dia”, “nove horas” etc. E se quisermos mudar o id do elemento #mensagem? E se quisermos exibir a saudação em mais de um elemento? Podemos melhorar algum nome de variável? Podemos reduzir o tamanho da nossa função? Nossa função está cumprindo seu objetivo? Tem algum código/texto repetido? E nossos testes? Estão cobrindo tudo? Prevendo todos os cenários?

O que não falta é opção para um bom refactoring.

Na segunda parte veremos a função spy, além de mais sobre fixtures, matchers personalizados e outros recursos avançados.

Tableless » JQuery

Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas

Préprocessadores

Frameworks

Bibliotecas

Como todos eles trabalham juntos?

Qual deles é melhor para o meu projeto

Posts Relacionados

Tudo que você gostaria de saber sobre plugins jQuery e ninguém teve paciência de explicar

Por que eu deveria construir um plugin?

Entendi, quero criar um! Como faz?

O que significa o cifrão ($) ?

Qual a diferença entre $.meuPlugin e $.fn.meuPlugin?

Evite conflitos

Não quebre a corrente

Como passar parâmetros e lidar com eles depois?

A procura da batida perfeita

Mais comentados

jQuery: conheça os métodos on() e off()

Eventos diretos

Múltiplos eventos

Removendo associações de eventos diretos

Eventos delegados

Removendo a associação de eventos específicos

Namespaces

Enviando dados para o evento

Este evento se autodestruirá…

Posts Relacionados

Manipulação de classes com JQuery

Formas de manipulação de classes

.addClass()

.removeClass()

.toggleClass()

.hasClass()

Posts Relacionados

jQuery: métodos desconhecidos

proxy()

isArray() e isFunction()

queue() e dequeue()

detach()

ajaxSetup() e afins

delay()

replaceWith() e replaceAll()

1 milhão de pontos!

Carregamento completo!

Posts Relacionados

jQuery: dicas de otimização e performance

#1: Mantenha-se atualizado

#2: Não utilize jQuery!

#3: Seletores

#4: Cache de elementos

#5: Encadeamento de métodos

#6: DOM

#7: DRY (Don’t Repeat Yourself)

Como medir a performance da sua aplicação?

Posts Relacionados

20 plugins jQuery que marcaram 2011

jQuery Mobile

Quicksand

Reveal

jQuery File Upload

QapTcha

DropKick

ParallaxSlider

Toast Message

FitText

jRumble

Mosaic

Isotope

Zoomooz

jQuery uCompare

ArborJS

Slides

Zoomy

jFormer

DynamicNews

jRating

Bônus: jQuery Boilerplate

Para 2012…

Create