TidBits

Inspirada pelo meu último post, e pelo artigo do Glen Stansberry resolvi aproveitar o momento para incentivar a avaliação não só da usabilidade de um site, mas também do CSS. Agradecendo a dica do Jamaica segue a minha lista “adaptada” do que eu acho que ninguém deve fazer com o CSS do site:

1. Ignorar a compatibilidade de browser
A gente já falou um monte sobre crossbrowser aqui no Tidbits. Já falamos de truques para checar se o seu site está compátivel com todos os navegadores, ensinamos a utilizar os Global Resets para zerar as propriedades automaticamentes setadas pelos browsers, e o Danilo no post anterior falou sobre o CSS compatível sem uso de hacks. Com esse material todo, você não pode nem pensar em deixar o seu CSS “quebrar”…

2. Não validar o HTML e o CSS
Também no post sobre garantir a qualidade do seu site em todos os browsers, eu dei o link de ferramentas de validação. Passem por elas para garantir um código semântico!

3. Não utilizar classes para formatações que se repetem em vários elementos
Se você tem elementos que tem propriedades de formatação iguais, utilize apenas uma class para definir essas propriedades para todos elementos. Se você tem em uma página, por exemplo, todas as fotos e boxes de um site tem borda e flutuam a direita, você pode simplesmente criar uma class para definir esses atributos e invocá-la em todos os elementos que a utilizam. Se, por um acaso, você precisasse mudar a cor da borda, teria que fazer isso em todos os elementos, se não atribuir a propriedade uma única vez.

4. Utilizar nomeclaturas ruins para classes e ids
Isso pode ser uma questão aparentemente insignificante, mas se você precisar fazer qualquer alteração no CSS depois de um tempo, vai se arrepender amargamente de não ter gastado 2 segundos a mais do seu tempo para pensar em um nome mais descritivo do que #box_top ou .coluna_left. Rótulos orientados à posicionamento ou ao formato do conteúdo dificultam a manutenção e substituição desse CSS.

5. Usar CSS para tudo
Quando se abandonaram os layouts com tabelas as tabelas ficaram tão mal faladas que até quando se precisa de tabelas, as pessoas tentam fazê-las da maneira mais díficil. O conceito é “Tableless” e não “Tablenone” - com o perdão do trocadilho infeliz. Enfim, o HTML precisa ser semântico, e quando você exibe dados em uma tabela, nada mais semântico do que utilizar uma tabela mesmo, não?

6. Usar CSS inline
Um dos piores erros que se pode cometer, é não se utilizar o conceito de “layers” (camadas), na hora de desenvolver uma interface. Na época que eu aprendi a mexer com o Photoshop, eu levei um tempo até perceber o qual importante era esse conceito, de manter cada coisa, em um plano diferenciado, e como isso facilitava a aplicação, manutenção e alteração de qualquer erros. Esse conceito é igualmente aplicável para o CSS, mantenha ele sempre em um arquivo externo. Um dos principais problemas remete ao item 3 dessa lista: com o CSS inline, você precisaria atribuir os valores para cada elemento individualmente, o que se transformaria em um caos, quando precisasse fazer modificações no layout.

7. Carregar muitos arquivos de CSS
Dividir o conteúdo do CSS em arquivos separados, facilita a manutenção - até certo ponto. Se você divide demais o CSS, pode acabar dificultando não só a manutenção, pela dificuldade de encontrar o arquivo que exatamente está procurando, como também o carregamento da página. Arquivos de CSS são bem leves (em sua maioria), o problema é que muitas conexões com o servidor, que precisam ser feitas para cada arquivo de estilo que for baixado, normalmente demoram mais que o próprio download. Normalmente, eu e o Danilo utilizamos um arquivo default.css setando propriedades que replicam em todo o site, por exemplo o CSS do Header, Footer, Menu lateral, e coisas do tipo. E criamos para cada área, o arquivo nomedaarea.css com as propriedades específicas da página, ou por exemplo um conteudo.css com as propriedades de css de páginas geradas dinamicamente.

8. Não utilizar o Firebug para acelerar os ajustes do css
O Firebug é uma ferramenta mais importante que o editor de códigos. Se um layout está com problemas de posicionamento, ou você está com dificuldades de entender porque uma div está herdando um padding fantasma de algum lugar, o Firebug ajuda você identificar quais são as propriedades de css que estão influenciando aquele elemento. Além do CSS, ele também facilita visualizar a estrutura do HTML, e identificar possíveis erros.

Acho que seguindo essa lista, já é possível otimizar o tempo de desenvolvimento, e ao mesmo tempo fazer um CSS de melhor qualidade. E se alguém se lembrar de algum outro erro que também poderia ser evitado, fique a vontade para comentar, e construirmos nossa lista juntos

Em quase todo blog tem uma coleção de hacks css, para todos as versões de todos os navegadores, opera, safari, ie6, ie7, firefox 2, firefox 3 etc etc… mas aqui você não vai encontrar, porque? Porquê você não precisa de hacks pra fazer um layout!

O jeito correto de escrever css é encontrar uma estrutura que funcione em todos os navegadores. Não faça o site pensando apenas no seu navegador favorito para depois encher de hacks para os demais e meter a culpa neles.

Navegadores são atualizados sempre, isso quando não surgem novos. A 6 meses atrás não existia o Google Chrome, Firefox 3 e pouco era utilizado internet em celulares no Brasil. Se o layout de um site foi construído errado e “consertado” com hacks, provavelmente o mesmo site está quebrando o layout nesses novos navegadores, por isso não vale a pena. Antes de criar uma hack, pense 10 minutos a mais resolver seu problema de outra forma. Tudo bem, tem hacks que realmente precisamos colocar por falta de suporte do ie6. min-height e max-height, o suporte a imagens alpha ( pgn24 ) tão usado pelos designers hoje em dia e os pseudo seletores :first-child e :last-child. Essas 3 opções, somente essas 3 não tem jeito mesmo, é colocar expression no seu css e filter pro png, mas de resto, nenhuma hack é necessária.

Outras técnicas que não recomendo são: display table, uso excessivo de float, margin com valores negativos, tudo isso não passa de gambearra para fazer o layout ficar no lugar onde está dando erro.

Dicas para ter menos problemas ao construir um css :

Utilize o CSS Global Reset para diminuir as diferenças entre os browsers. Cada browser, coloca por sua conta, qual vai ser o tamanho dos títulos, dos paragráfos, a margin entre elementos, a fonte padrão, o padding da página, etc… Com esse código, essas diferenças caem quase que por completo.

Para elementos fixos (que não tem variedade de tamanho) dentro de um container, tipo botões ou input / label de formulário, pense em utilizar position absolute, é uma técnica muito simples de se trabalhar quando se tem um xhtml válido, pois todos os navegadores interpretam da mesma forma a posição do elemento, ao contrário de float e margin que dão muitos problemas. O site americano Position Is Everything recomenda a técnica e explica melhor como utilizar.

Aqui no TidBits também nós disponibilizamos uma apostila e material de estudo sobre padrões web em português

Jakob Nielsen é um cara polêmico no mundo da usabilidade, talvez pelo fato de ser o mais conhecido analista de usabilidade do mundo, ou talvez seja o mais conhecido analista de usabilidade do mundo pelo fato de ser polêmico. O fato é que ele fala de usabilidade há muito tempo, e mais do que falar, ele sempre promove testes e pesquisas para embasar suas falas (para quem costuma ler os rodapés das pesquisas, ele é o dono da Norman e Nielsen Group - uma grande empresa de pesquisas e análises de dados do mundo).

Ele também escreve uma coluna em seu site (Useit.com), chamada Alertbox, onde constantemente apresenta os resultados de várias dessas pesquisas, ajudando a implantar certos parâmetros de usabilidade que passam a ser adotados por um grande número de profissionais.

Um desses parâmetros, são suas heurísticas. São 10 itens para a avaliação da usabilidade de um site, com intuito de evitar erros comuns - as heurísticas foram baseadas em 294 tipos de erros de usabilidade que o Nielsen comumente encontrava em suas análises - e que podem prejudicar e muito a experiência do usuário em seu site. Uma avaliação heurística, ao pé da letra, é feita por no mínimo 3 e no máximo 5 profissionais especializados nesse tipo de avaliação.

Mas mesmo que você não seja nenhum analista de usabilidade, checar esses itens com certeza irá tornar a experiência do usuário em sua interface uma experiência menos frustante. Vamos às heurísticas:

1. Visibilidade de Status do Sistema
Isso significa que você precisa se certificar de que a interface sempre informe ao usuário o que está acontecendo, ou seja, todas as ações precisam de feedback instantâneo para orientá-lo.

2.Relacionamento entre a interface do sistema e o mundo real
Ou não usar palavras de sistema, que não fazem sentido pro usuário. Toda a comunicação do sistema precisa ser contextualizada ao usuário, e ser coerente com o chamado modelo mental do usuário.

3. Liberdade e controle do usuário
Facilite as “saídas de emergência” para o usuário, permitindo desfazer ou refazer a ação no sistema e retornar ao ponto anterior, quando estiver perdido ou em situações inesperadas.

4. Consistência
Fale a mesma língua o tempo todo, e nunca identifique uma mesma ação com ícones ou palavras diferentes. Trate coisas similares, da mesma maneira, facilitando a identificação do usuário.

5. Prevenção de erros
Na tradução livre das palavras do próprio Nielsen “Ainda melhor que uma boa mensagem de erro é um design cuidadoso que possa prevenir esses erros”. Por exemplo, ações definitivas, como deleções ou solicitações podem vir acompanhadas de um checkbox ou uma mensagem de confirmação.

6. Reconhecimento ao invés de lembrança
Evite acionar a memória do usuário o tempo inteiro, fazendo com que cada ação precise ser revista mentalmente antes de ser executada. Permita que a interface ofereça ajuda contextual, e informações capazes de orientar as ações do usuário - ou seja - que o sistema dialogue com o usuário.

7. Flexibilidade e eficiência de uso
O sistema precisa ser fácil para usuários leigos, mas flexível o bastante para se tornar ágil à usuários avançados. Essa flexibilidade pode ser conseguida com a permissão de teclas de atalhos, por exemplo. No caso de websites, uso de máscaras e navegação com tab em formulários são outros exemplos.

8. Estética e design minimalista
Evite que os textos e o design fale mais do que o usuário necessita saber. Os “diálogos” do sistema precisam ser simples, diretos e naturais, presentes nos momentos em que são necessários.

9. Ajude os usuários a reconhecer, diagnosticar e sanar erros
As mensagens de erro do sistema devem possuir uma redação simples e clara que ao invés de intimidar o usuário com o erro, indique uma saída construtiva ou possível solução.

10. Ajuda e documentação
Um bom design deveria evitar ao máximo à necessidade de ajuda na utilização do sistema. Ainda assim, um bom conjunto de documentação e ajuda deve ser utilizado para orientar o usuário em caso de dúvida. Deve ser visível, facilmente acessada, e com oferecer uma ferramenta de busca na ajuda.

Ví hoje no DGmike que saiu uma matéria no Ajaxian dizendo que o Firefox 3.1 que deve sair em breve vai suportar as tags de áudio e vídeo. Atualmente o formato suportado pra vídeo é somente o ogg mas outros formatos estão sendo discutidos para serem implementados no futuro.

Para chamar, vai ser bem simples:

<video src="videos/teste.ogg" autoplay="autoplay">
Seu navegador não suporta vídeo
</video>

E se quiser mandar dar play ou pause com javascript, será bem simples também:

<script type="text/javascript">
    document.getElementsByTagName('video')[0].play()
</script>  

Ou por jQuery:

<script type="text/javascript">
    $('video')[0].play();
</script>  

O HTML5 está apenas iniciando a ser implementado nos novos browsers, mas dá pra ver que vai mudar muita coisa, dando muito mais ferramentas a nós, programadores de interface.

Em momentos pós-eleições americanas, nas quais a web foi fundamental para a campanha de Obama e teve peso decisivo na escolha do novo grande líder mundial, é hora de nós repensarmos um pouco o espaço com o qual aprendemos, nos conectamos e principalmente, colaboramos - como não poderia deixar de ser em tempos “2.0″ - embora essa palavra me parece uma gradessíssimo clichê.

Repensar nossa postura, como profissionais do meio, é uma reflexão necessária. O mundo moderno se tornou de tal forma tão dependente da rede, e ao mesmo tempo tão vulnerável em sua depêndencia que nossa responsabilidade cresce e muito.

Construir interfaces para web, também se tornou uma tarefa que vai além da relação com o desktop, e abrange um universo bem maior de gadgets, que aumentam ainda mais nosso desafio de planejar, desenvolver e apresentar essas interfaces.

Pra complementar a discussão, um vídeo interessante (que não é inédito) mas aborda de uma maneira bastante criativa a importância da web (e das novas tecnologias), e sua influência sobre nossas vidas, no presente e no futuro próximo.

Bom final de semana a todos.

Recentemente o site do Governo Eletrônico lançou um projeto implementar padrões web no site do governo. E inclusive lançou uma cartilha de codificação para auxiliar as administrações públicas.

O objetivo da cartilha é:

• Estabelecer padrões de qualidade de uso, desenho, arquitetura de informação e navegação;
• Estabelecer um fluxo de criação, desenvolvimento e manutenção na gestão dos sítios governamentais;
• Consolidar a acessibilidade;
• Criar artefatos de acordo com os padrões estabelecidos pelo W3C.

A apostila pode ser lida por qualquer desenvolvedor web, pois fala de padrões web em geral e não de sites do governo.

Clique aqui para baixar a cartilha.

Outra coisa que chamou a atenção essa semana, foi o blog do Danilo Nunes, ele está traduzindo um curso sobre padrões web que funcionários da Opera fizeram pra implementar nas universidades americanas, um projeto bem legal.

O curso (original, em inglês) tem 50 artigos, cada um bem detalhado. O Danilo Nunes disse que vai traduzir um por semana.