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

• Qualidade de Imagens e densidade de pixels
• GoMo – Teste seu site mobile
• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução aos padrões de codificação

Sabemos que o HTML5 não se trata apenas de marcação, mas também de um conjunto de novas funcionalidades encapsuladas em APIs que podem ser acessadas via JavaScript.

Porém, há APIs em processo de padronização pelo W3C que não fazem parte da especificação do HTML5. Elas são especificações relacionadas não intrínsecas ao HTML5, ou seja, a utilização delas não está estritamente atrelada ao uso da linguagem. Algumas, inclusive, faziam parte do core do HTML5, mas hoje estão dissociadas e contam com uma especificação separada, como é o caso do Web Storage.

As APIs próprias do HTML5 são mais específicas às funcionalidades que atuam no escopo da página e da manipulação de elementos. Elas se relacionam em grande parte com o DOM. Já as outras APIs geralmente trabalham com funcionalidades um pouco mais complexas, como armazenamento de dados e manipulação de arquivos, por exemplo.

Algumas das novas APIs que estão contidas na especificação do HTML5 são:

• Canvas
• Validação de formulários
• Controles de áudio e vídeo
• Application cache / offline applications
• Funcionalidade de markup editável (contenteditable)
• Drag and drop
• Novas funcionalidades para manipulação do histórico do navegador

Algumas das novas APIs que são desenvolvidas em conjunto pelo WHATWG e W3C e trabalham muito bem com HTML5 mas que não são (mais) exclusivas dele:

• Web Storage (localStorage e sessionStorage)
• Web messaging
• Microdata
• Web Workers
• Web Sockets

E algumas especificações relacionadas, que não são desenvolvidas pelo WHATWG e possuem especificações publicadas separamente pelo W3C:

• Geolocation
• File API
• Indexed DB
• File Writer
• Notifications

O gráfico abaixo, desenvolvido por Sergey Mavrody fornece uma boa visão deste contexto e do relacionamento entre as novas APIs e o HTML, além de mostrar o status de desenvolvimento de cada uma destas especificações. Note que o Web Storage ainda está incluído junto à especificação do HTML5, mas isto já mudou.

HTML5 e as APIs relacionadas por Sergey Mavrody

Portanto, muitas vezes quando falamos das novas possibilidades do HTML5, na verdade estamos nos referindo à toda uma nova geração de tecnologias para a web.

O que podemos concluir disso tudo é que o HTML5, sozinho, não faz uma web melhor. Porém, ele ajudou a movimentar o mercado rumo ao desenvolvimento de novas tecnologias. Saímos da zona de conforto que já estávamos há alguns anos. O cenário que temos agora é de uma série de tecnologias web que, trabalhando em conjunto, fazem uma web melhor, para as pessoas e para os desenvolvedores

Referências:

Especificação do HTML pelo WHATWG
W3C – HTML5 differences from HTML4
HTML5 – Wikipedia

Posts Relacionados

• Porque é a web que comanda
• Sections: elemento article – Parte 4
• Sections: elemento aside – Parte 3
• Apostila sobre HTML5
• Google Apps não suportará mais IE6

Diferente dos frameworks e bibliotecas, que foram desenvolvidos como uma camada extra, o código escrito em CoffeeScript é compilado e resulta em JavaScript puro.

A sintaxe é inspirada em linguagens como Ruby e Python (principalmente Ruby), portanto você pode esperar códigos intuitivos e limpos, sem pontos-e-vírgulas, chaves e parênteses (quase).

Instalação & Comandos

Não vou entrar muito em detalhes sobre a instalação da linguagem. A maneira mais fácil de instalar as ferramentas para desenvolvimento em CoffeeScript é através do sistema de pacotes do NodeJS, o npm.

O criador do npm disponibilizou um gist com instruções variadas para a instalação do NodeJS e seu gerenciador de pacotes.

Depois de seguir todos os passos necessários, para conferir se a instalação foi concluída com sucesso, digite o seguinte comando em um terminal:

O comando coffee, executado via terminal, pode ser utilizado como um console interativo, como um compilador ou como um watcher. Como um watcher, o comando vigia qualquer alteração em códigos-fonte CoffeeScript e, automaticamente, gera os arquivos JavaScript.

Além disso, ele pode também executar diretamente um script:

Uma maneira mais fácil de testar e experimentar CoffeeScript é visitando o link “Try CoffeeScript” no site oficial da linguagem. Lá você pode observar, em tempo real, o resultado da transformação de CoffeeScript em JavaScript.

Variáveis & Funções

A simplificação começa com a declaração de variáveis, eliminando a necessidade de instanciá-las:

O código acima resulta no seguinte JavaScript:

Já uma função em CoffeeScript é representada pela junção dos caracteres “-” e “>”:

JavaScript:

O compilador CoffeeScript vai sempre transformar suas funções em expressões, ou seja, funções armazenadas em variáveis.

Vale lembrar que assim como em Python, a indentação em CoffeeScript precisa ser seguida à risca. Seu código deve respeitar um padrão de indentação — tab ou espaços, nunca os dois ao mesmo tempo.

O valor retornado por uma função é sempre a última linha de sua implementação. Não é necessário utilizar return.

Os argumentos devem ser declarados antes do símbolo da função. A concatenação segue o estilo Ruby de ser:

JavaScript:

Eles podem ainda possuir valores padrões, caso não seja passado nenhum parâmetro:

E, como já deu pra perceber, quando uma função é chamada, os parênteses são opcionais:

Objetos

Existem duas maneiras de representar objetos em JavaScript. A primeira é utilizando new:

A maneira mais comum, no entanto, é utilizando a notação JSON:

Este tipo de criação é simplificado no CoffeeScript, com a remoção das chaves e vírgulas, utilizando apenas indentação para formatar o objeto:

Agora o mesmo objeto, em JavaScript:

Operações condicionais e comparativas

As operações condicionais em CoffeeScript são bastante flexíveis e mais poderosas do que as operações nativas em JavaScript. O CoffeeScript introduz novos tipos de implementações de operações condicionais:

O segundo exemplo, compilado, fica assim:

Os operadores também receberam uma repaginada, ganhando versões “escritas”:

Javascript:

Outra implementação legal é a comparação em cadeia:

Javascript:

Loops

Antes de falar sobre operações de loop, vamos conhecer ranges ou intervalos. Em CoffeeScript é possível declarar ranges dinâmicos:

O código acima gera a lista completa, de 0 a 24. O resultado ainda pode ser trabalhado retornando apenas os quatro primeiros valores (0, 1, 2, 3):

A manipulação de dados via loops é bem completa, com diferentes possibilidades:

O código acima resulta no seguinte JavaScript (!):

Outra maneira de executar um loop é declarando tudo em uma única linha:

Podemos ainda manipular os dados diretamente no loop:

E para finalizar essa parte sobre loops, uma ferramenta muito útil é a keyword when, utilizada para filtrar os dados do loop:

Integração com jQuery

Escrever código em CoffeeScript não significa abandonar bibliotecas e frameworks JavaScript. A integração com CoffeeScript é direta:

Equivale a:

A premissa básica continua sendo a simplificação do código, principalmente devido a remoção de chaves, parênteses, vírgulas e pontos-e-vírgulas.

O código acima é a implementação do Konami Code aqui no Tableless.

Veja o JavaScript original:

Essa foi uma visão geral da linguagem. A desvantagem de implementar CoffeeScript em produtos e aplicativos grandes é o fato de ainda ser difícil debugar o código diretamente, já que as ferramentas disponíveis nos navegadores só indicam os erros no arquivo JavaScript gerado. O compilador aponta os erros de sintaxe, mas erros de lógica dão um pouco mais de trabalho.

Muitos aspectos ficaram de fora deste artigo, como os splats, escopo, propriedades, switches, soaks e, principalmente, classes. No próximo artigo falo mais sobre eles.

Posts Relacionados

• jQuery: conheça os métodos on() e off()
• Manipulação de classes com JQuery
• jQuery: métodos desconhecidos
• 20 plugins jQuery que marcaram 2011
• Testando seu código jQuery com Jasmine – Parte 1

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:

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.

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

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:

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:

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:

E o JQuery:

Link do exemplo

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

Posts Relacionados

• Cut the Rope
• jQuery: métodos desconhecidos
• Introdução aos padrões de codificação
• Vote no Especialista em Usabilidade para Presidente
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas

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:

É 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.

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.

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).

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’.

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().

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.

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.

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

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.

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.

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.

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.

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.

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

• Manipulação de classes com JQuery
• JavaScript com café
• Cut the Rope
• jQuery: conheça os métodos on() e off()
• Introdução aos padrões de codificação

“Codecademy was created out of the frustrations Zach and Ryan felt with learning how to program. Tired with less effective text and video resources, Ryan and Zach teamed up to create Codecademy, a better, more interactive way to learn programming by actually coding. This is just the beginning. Join us as we make it easy for everyone to love and learn how to code.”

Lá você aprende a programar, se baseando em Javascript, de uma maneira facil e assistida. Você consegue facilmente aprender nos primeiros passos como fazer variáveis, arrays e outros pequenos conceitos que precisamos entender ao programar.

Conforme você vai aprendendo, você desbloqueia badges (Como o Campus Online novo, aguarde! ;-D) e acompanha seu ritmo de aprendizado.

Muito indicado para quem quer aprender a programar ou quer ter alguma noção sobre o assunto! Visite o Codeacademy agora e comece sua jornada!

Mais comentados

• Editores
• Quer testar o Google Analytics?
• O Chrome não quer dizer muita coisa
• Desenvolvedor analfabeto (sim, é sobre WYSIWYG)
• Não “otimize” seu código

Definir padrões é normal para que a equipe inteira escreva o código da mesma maneira. Esse assunto é longo e muito importante para todas as equipes de desenvolvimento. Programadores já quiseram me matar várias vezes porque eu uso TABS em vez de ESPAÇOS em arquivos Python/PHP. Programadores gostam de espaços. Eu não. Mas não é o nosso gosto que vai definir quais os padrões de código que devemos seguir.

Quando definimos padrões e boas práticas, garantimos que todos da equipe conseguirão ter o mínimo de entendimento do código daquele projeto que está na empresa a tempos. Se alguém da equipe adoecer ou precisar ir para o Canadá, outro integrante pode assumir o seu lugar sem precisar se preocupar em aprender novas regras, porque elas devem ser as mesmas do projeto anterior.

É importante que os integrantes da equipe sejam sempre fiéis aos acordos firmados no momento em que combinam esses padrões. É importante também que, caso eles encontrem um integrante fora da lei, que eles forcem o meliante a seguir as regras. Já vi gente perdendo o trabalho de uma semana por que estava trabalhando diretamente pelo FTP e o projeto não estava no GIT. O programador simplesmente APAGOU o projeto da pessoa. Nunca mais ela resolveu editar os arquivos fora do controle de versão. Esse tipo de atitude é perigosa mas muito necessárias às vezes. Devemos forçar as regras num ambiente onde todos devem quem, quando e como as linhas de código do projeto foram escritas.

Alguns pontos para se pensar e combinar:

Identação

Como devemos identar o código? Com espaços ou tabs? Se for com espaços quantos?

Espaços em brancos (Whitespaces)

Espaços devem ser incluídos depois de uma operação condicional? Espaços devem ser colocados entre o seletor e as chaves? E no final de cada linha, precisa?

Nomenclatura

Como as classes, ids e variáveis devem ser nomeadas? E as funções? Vamos usar CamelCase?

Comentários

Como faremos com os comentários? Como serão os delimitadores do comentário? O comentário deve ser completo ou precisa ser algo mais resumido?

Arquivos

Como os arquivos, que não fazem parte da estrutura padrão do CMS, Framework e etc deverão ser chamados? E o nome das pastas? Como as páginas serão chamadas?

Chaves e ponto/vírgula

As chaves deverão ser abertas na mesma linha ou devemos quebrar linhas? Vamos sempre usar ponto/vírgula? Vamos usar o padrão K&R ou Allman?

Quando definimos estas pequenas coisas, diminuímos muitos percalços no meio do caminho. Já vi projetos atrasarem meses por que um palerma abriu e salvou arquivos com o charset diferente do que já tinha sido combinado no início.

“It’s more important for people on a team to agree to a single coding style than it is to find the perfect style.” Building Scalable Web Sites: Building, Scaling, and Optimizing the Next Generation of Web Applications
Indico este livro sobre esse e outros assuntos sobre a construção, desenvolvimento e manutenção de websites

Posts Relacionados

• GoMo – Teste seu site mobile
• Agora é a vez dos desenvolvedores
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• ePub: Aprenda a criar um livro digital
• Introdução das premissas dos controles de versão

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:

1. 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.
2. 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 <select> ao invés de uma <input type=”text”> 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 <fieldset> 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.
• 
  
3. 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.
4. 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?
   
   
5. 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.

1. 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:

1. 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.
2. Sofisticação no formulário deve respeitar uso geral dos forms: <input type=”text”> é 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.
3. O form deve respeitar o conhecimento público nos domínios da sua app: É aceitável você usar um <input type=”text”> 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.
4. 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.
5. 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:

1. 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.

2. Texto:

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

3. Números:

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

4. 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:

1. Como combinar elementos;
2. definir relações estruturais entre elementos;
3. 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:

1. remover espaços,
2. inserir apenas números (ou texto),
3. texto sempre em caixa alta (ou caixa baixa),
4. 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

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

Posts Relacionados

• Você sabe o que é a “nova usabilidade”? – parte II
• Usabilidade de interfaces para dispositivos móveis – parte II
• Estabelecendo uma metodologia ágil para avaliação de usabilidade

Quando produzimos um site os problemas de compatibilidade fazem parte da regra do jogo. Para tentar contornar estes problemas utilizamos hacks, comentários condicionais, sniffing de browsers e outras coisas, que muitas vezes mais prejudicam do que ajudam.

Para ajudar mais ainda o CSS3 e o HTML5 apareceram derrubando tudo, e o problema de compatibilidade que já era chato, ficou mais chato que meia molhada. Embora os browsers estejam muito mais atuais e suportando propriedades avançadas de CSS3 e HTML5, não é garantia que todos eles suportem as mesmas propriedades. E é aqui que começamos a ter problemas novamente, como no passado.

Como você consegue reconhecer quem um determinado browser suporta CSS Animation? Como você sabe que o browser conhece LocalStorage do HTML5? Você não vai ficar olhando numa tabelinha toda vez que tiver essas dúvidas para fazer um visual ou uma solução alternativa para tais browsers.

É por essas e outras que você utilizará a Modernizr.

O que é a Modernizr

Modernizr é uma pequena biblioteca Javascript que detecta a disponibilidade das novas características do HTML5 e CSS3 nos browsers. Muitas destas características já estão implementadas nos browsers, mas é muito chato você decorar quais novidades os browsers já estão suportando. O que a Modernizr faz é simples: ela te diz quais features um determinado browser suporta e insere classes no HTML para que você possa utilizar para fazer uma versão alternativa de visual ou solução.

Entenda que a Modernizr não é um sniffing de browser. Ela é diferente. A Modernizr faz o trabalho de detectar das seguintes formas:

• Ela testa 40 features de CSS3 e HTML5 em alguns milisegundos.
• Depois ela cria objetos javascript que contém os resultados destes testes.
• Aí são adicionadas classes no elemento HTML descrevendo exatamente quais propriedades e novidades são ou não nativamente suportadas.
• Depois disso você consegue ter os resultados descritos nos navegadores dinamicamente e então pode tomar decisões criando alternativas para aquelas propriedades não suportadas pelos browsers antigos.

Como funciona

É simples: primeiro você baixa a versão mais atual da biblioteca no endereço http://www.modernizr.com/. O interessante é que você tem a opção para personalizar a biblioteca, indicando quais features você quer que a Modernizr teste no seu projeto.

Depois você inclui esse pacote no seu HTML:

Feito isso, insira uma classe no-js no elemento HTML:

Quando a Modernizr rodar, ela irá substituir essa classe para uma js se o browser estiver com o Javascript ligado, já te dando um feedback para tomar alguma atitude se o usuário estiver com o Javascript desligado.

Junto com essa mudança são adicionadas outras classes, indicando o que o browser aceita nativamente ou o que ele não aceita. Ficará algo parecido com isso:

O browser que eu utilizei é o Safari/Mac. Pelo visto ele aceita bastante coisa.
O que o browser não aceita, a Modernizr insere uma classe com o prefixo no- antes da classe, por exemplo: no-boxshadow, no-geolocation, no-touch etc.

A Modernizr também cria um objeto Javascript contendo um valor booleano para cada uma dessas features, possibilitando a criação de testes. Um exemplo:

Exemplos de utilidade

Exemplo bem básico: imagine que você queira utilizar o box-shadow em seu projeto. Browsers como o IE6,7,8 não reconhecem essa feature, então seria interessante darmos uma alternativa, como por exemplo, colocando uma borda em vez de sombra. Assim o elemento não fica tão diferente do que deveria.

Como a Modernizr colocou uma classe no elemento HTML referente a aceitação das features, podemos utilizá-la fazendo assim:

Assim, se o browser não aceitar a propriedade box-shadow o usuário verá uma borda no lugar. Você pode fazer isso com praticamente qualquer nova feature do CSS3 e do HTML5. Uma listagem completa dessas features suportadas está aqui.

Ah, mais uma coisa: provavelmente você já utiliza um scriptzinho html5.js para fazer com o que os Internet Explorers reconheçam as tags do HTML5, correto? O Modernizr já faz isso automaticamente. Sugiro que pare de utilizar o html5.js e passe a utilizar a Modernizr somente.

A Modernizr facilita demais as coisas. A ideia é que você não prive seus projetos da utilização de features novas. A produção vai ficar mais eficaz e seu projeto sempre estará atualizado com as melhores práticas do mercado. Adote a Modernizr e seja feliz.

Sugiro que você dê uma lida na documentação da Modernizr. Tem bastante coisa interessante lá que você deveria saber.

Posts Relacionados

• CSS3 – Sombras em textos e elementos
• Múltiplos backgrounds com CSS
• CSS3 – Abas com a pseudo-classe :target
• Drops 3 – Duas formas de modular seu CSS
• Introdução ao CSS 3D – Flip Card

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.

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.

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.

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.

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.

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:

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”.

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

• Código fonte dos exemplos deste artigo
• SpecRunner dos exemplos rodando no browser
• Testing jQuery plugins with Jasmine
• HTML fixtures in Jasmine (using jasmine-jquery)

Posts Relacionados

• Testando seu código jQuery com Jasmine – Parte 1