Para participar, é preciso seguir o @tableless e a @BookmanEditora no twitter. O sorteio será realizado no dia 20, às 10h, por meio do site sorteie.me. Um sortudo vai ganhar um exemplar do livro Smashing HTML5, de Bill Sanders. O ganhador será avisado pela rede social e deverá enviar seus dados via Direct Message para a @BookmanEditora em até 72 horas.

Não esqueça:

• Siga @tableless e a @BookmanEditora no Twitter
• Dê RT na mensagem “O @tableless vai me dar o livro Smashing HTLM5, da @BookmanEditora! http://kingo.to/XyZ. Para concorrer, a mensagem deve ter o link da promoção!
• Aguarde o sorteio no dia 20 e boa sorte!

Conheça mais sobre o livro:
Smashing HTML5, de Bill Sanders
Fiel à missão do Smashing Magazine (smashingmagazine.com), um dos sites de Web design mais populares do mundo, este é um guia prático para a construção de sites modernos e atraentes que aproveitam todas as vantagens dos recursos oferecidos por HTML5. Com Smashing HTML5, você tem tudo o que precisa para fazer a transição para a nova versão da linguagem e começar a trabalhar rapidamente.

Desconto especial para leitores Tableless: Quem é leitor do tableless têm 20% de desconto para adquirir o livro Smashing HTML5 no site da Bookman! Basta acessar este link e digitar o código tableless no carrinho de compras. A promoção é válida até dia 16/02/2012.

Posts Relacionados

• Declarando idiomas no HTML
• Guia de Referência de HTML5
• Google Chrome para Android
• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital

Eu criei o Tableless a mais ou menos uns 8 anos. Ele começou como um simples blog no saudoso cjb.net. Depois eu migrei para o .kit.net. Então ganhei o domínio .com.br na época em que trabalhava na Atípico. E a partir daí tudo mudou. A minha ideia inicial era compartilhar meus estudos e mostrar para outros profissionais o que eu estava aprendendo. O que eu não sabia era que uma comunidade cresceria em volta e que juntos mudaríamos a forma com que fazíamos web no Brasil.

Durante muito tempo eu mantive este site sozinho. Não porque ninguém queria ajudar, pelo contrário, porque eu não queria que ninguém encostasse no “meu bebê”. Nunca foi fácil para mim deixar algo que construí nas mãos de outras pessoas. Mas eu percebi que o site não ia muito longe se eu continuasse centralizando todas as tarefas. Foi aí que eu decidi aceitar a ajuda de pessoas mais capazes que  eu. Então o Alysson, a Talita, a Thaiana, o Davi, o Paulo e posteriormente o Keppelen e o Moacyr apareceram para salvar a pátria. Gente fera, com opiniões fortes e que representa muito bem o nome deste site quando estão por aí falando sobre Padrões.
Mas ainda existia o nosso Twitter que estava precisando de atenção. Decidi então, depois de muito pensar, abrir para mais 2 pessoas me ajudarem a levar links interessantes para a comunidade, para isso contei com a agilidade do Luiz e do Henrique, que twitam links que eu nunca teria encontrado.
E claro, não podia esquecer do Gui, Felquis, Riccardo e Deivid que estão lá, cuidando do nosso fórum, fazendo com que as dúvidas de diversos desenvolvedores sejam respondidas.

Depois que tomei estas decisões o site cresceu demais. Não tenho nem como agradecer a não ser aqui, em público: muito, muito obrigado galera. Eu seria um nada sem vocês. Segurar tudo isso aqui é muito mais fácil quando há pessoas inteligentes e dispostas como vocês. Aposto que não é somente eu que agradeço, mas toda a comunidade que envolve este site. Obrigado e meus parabéns.

Outro ponto que eu deveria resolver era sobre a colocação de publicidade no site. Eu nunca gostei de fazer isso e muitos leitores reclamavam. O problema é que um site gera despesas. Estas despesas vão desde o tempo gasto até o servidor… Quem paga por isso?
Resolvi então inserir alguns blocos de banners para gerar alguma renda. Estamos terminando agora o livro do Tableless. Paguei a editoração básica do livro com o dinheiro gerado com propaganda no Twitter feito via seeding da Boo-box.

A partir de agora, quero profissionalizar cada vez mais o site, de forma que consigamos chegar mais longe. O ano de 2012 vai ser diferente. Graças a você, desenvolvedor sedento por informação de qualidade e com vontade de mudar ao seu redor, estamos nos mobilizando para fazermos cada vez melhor. Obrigado por estar conosco o tempo inteiro e obrigado por nos fazer crescer. Por nos mostrar onde erramos e principalmente quando acertamos. Não posso deixar de cobrá-lo: divulgue nosso site. Não porque eu quero que as vistas aumentem, mas porque eu sei que tem um monte de desenvolvedores por aí que precisam ouvir sobre boas práticas de client-side. Essa evangelização só pode ser bem feita por você.

O ano que vem vai ser grande. O ano que vem vai ser de tirar o folêgo, de novo.

If not now, when? If not you, who? Web Standards Project

Posts Relacionados

• Google Chrome para Android
• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• jQuery: métodos desconhecidos
• A melhor parte da viagem é o caminho

Eu criei a Visie com o Elcio porque queríamos mudar a forma com que a Web brasileira era feita. Eu criei o Tableless por este mesmo motivo. Quando todo mundo não estava botando fé na ideia de um blog sobre padrões web, eu arrisquei e criei sozinho. A Visie surgiu com o mesmo pensamento. Nós não sabíamos que a Visie seria a empresa que ela é hoje. Não sabíamos a imagem que formaríamos perante a comunidade e os clientes, mas moldamos uma empresa firme nos princípios e com uma missão clara.

Nesse tempo, além de aprender a dirigir uma empresa, eu geri projetos incríveis e trabalhei com pessoas excepcionais (nos dois sentidos ). Treinei equipes inteiras de empresas gigantes. Tive uma série de problemas também. Não pense que era uma maravilha 100% do tempo, porque não era. Toda empresa tem problemas, de diversos tipos, e é debaixo de porradas que você aprende mais.

Decidi seguir conhecer novos ares e aumentando minha bagagem de conhecimento e experiência. Quero trabalhar em empresas inovadoras, que enxergam a web de forma singular. Se você conhece uma empresa assim, que está precisando de alguém como eu, me avise!

Mais sobre mim, visite meu LinkedIn.

–

Perguntas que fizeram para mim e que respondo agora:
1. O Tableless não vai terminar. Eu fundei o Tableless e ele é meu xodó. Mas a partir de agora vou começar um processo de “profissionalização” do blog. Está comigo agora toda a responsabilidade sobre Treinamentos e aulas particulares que antes era da Visie. Eles serão oferecidos pelo nome do Tableless, tanto treinamento e consultoria para empresas quanto as aulas particulares.

2. E agora o que você vai fazer? Vou buscar oportunidades em empresas que inovam na web. Gerente de produto, projeto, liderança de equipes, me interessam. Não sei se valerá a pena me contratar para ser um coder html/css/javascript, mas podemos conversar.

3. Quero te contratar, como falo contigo? Fácil: diego[at]tableless.com.br, twitter.com/diegoeis, about.me/diegoeis.

Mais comentados

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

Entender realmente como um navegador funciona é importante, e garante seu entendimento do real dos problemas que está enfrentando no código que está implementando. Tem mais! Criar um código que manipula o layout (leia-se DOM) fica mais fácil, é uma relação win-win.

Criado pelo W3C, O DOM é uma multi-plataforma que representa como as marcações em HTML, XHTML e XML são organizadas e lidas pelo navegador que você usa. Uma vez indexadas, estas marcações se transformam em elementos de uma árvore que você pode manipular via API – que é o que fazemos quando usamos programas ou scripts para alterar funcionalidades de uma página: conteudo, estrutura ou folha de estilo.

Um pouco de história

Não tem graça falar sobre o assunto sem mostrar como ele surgiu. Isso só reforça ainda mais a importância de conhecermos bem o assunto pois mostra sua relevância (e porque falar de browser wars é bem legal, apesar de evidenciar os cabelos brancos).

Netscape e Microsoft guerreavam com Netscape 2 e IE3.0 lá em 1996 e enquanto a Netscape lançava o Javascript a Microsoft lançava o JScript. A diferença entre um e outro não é nada mais além do nome – acredite! Por razões comerciais devido as “sangrentas” browser wars as empresas decidiram adotar nomes diferentes para a mesma coisa – que na verdade era (e continua sendo) o ECMAScript, a linguagem que comecou a ser criada em 1994 quando o W3C colocou na mesma mesa as duas empresas e várias outras para desenvolver um padrão para linguagens de script para os navegadores. Javascript, JScript e ActionScript não são nada mais que dialetos de ECMAScript.

O DOM em sua forma e como é reconhecido pelos navegadores

Representação de um documento HTML e sua árvore DOM

A figura acima mostra a estrutura de uma árvore DOM, a linearização  das marcações de modo que ela possa ser montada inicialmente por um navegador. Esta estrutura não será o que veremos no navegador – o layout em si. O DOM é a base para uma outra árvore que é o que realmente um browser monta na tela, a Árvore de Renderização - aka Render Tree.

A base para todos os nós da árvore DOM é o base class chamado Node.h. Ele possui várias categorias, e as relevantes para renderizarmos código no navegador são os nós de documentos, elementos e texto.

1. Documentos é o nó mais importante do DOM, com três classes diferentes: Document, que é usado por todos os documentos XML e outros que não sejam SVG (que também é um XML, porém com marcação já padronizada), HTMLDocument que como o nome diz, cuida de documentos HTML e SVGDocument, responsável pelos documentos SVG e tambem por outros documentos herdados da classe Document (Como o Document.h e o HTMLDocument.h).
2. Elementos são todas as tags que estão em arquivos HTML ou XML se transformam em elementos da árvore DOM. Considerando a renderização do navegador, um elemento é um nó com uma tag que pode ser usada para fazer subclasses específicas que podem ser processadas de acordo com as necessidades da Render Tree (Element.h).
3. Texto: É o texto que vai entre os elementos. Todo o conteúdo das tags (<p>Isto é um text node</p>). O nó de Texto guarda basicamente texto puro, que pode ser renderizado ou trabalhado via script.

A Render Tree

Como a render tree é montada

A Render Tree é a parte mais importante do processo de renderização. Bem parecida com a árvore DOM, cada objeto corresponde a nós de Documentos, Elementos ou Texto. A diferença é que q Render Tree possui tambem objetos que não possuem nós na árvore DOM, como scripts e folhas de estilos.

O processo de criação da Render Tree passa pelos seguintes passos:

1. Attachment: Após finalizar o parse do DOM e a criação de seus nós, os navegadores chamam um método chamado attach para começar a renderização. O attach adiciona primeiramente as folhas de estilo a árvore DOM e começa a estilização da página. Um bom exemplo é o uso das propriedades CSS display x visibility: Caso um elemento da árvore DOM tenha uma propriedade display:none, este elemento (e seus nós filhos) não será criado na Render Tree. Ao contrário do uso de visibility:hidden, que vai renderizar o elemento na árvore, porém  ele irá remover (ou adicionar quando visibility:visible) via Repaint as cores (ou propriedades) que formam este elemento. Vale lembrar também que este processo de attach é top down, criando sempre inicialmente os nós parent e depois seus descendentes (nós filhos). (Para saber mais sobre Repaint e Reflows, veja este outro artigo)
2. RenderStyle.h: Durante o processo de attach um método é criado, o RenderStyle.h que vai guardar objetos de referência com cada uma das propriedades CSS do documento. O nó criado no DOM é verificado no documento de CSS e caso existam propriedades que incidam naquele elemento, ela é aplicada. Esta propriedade fica salva dentro da Render Tree até que ela seja destruída ou que este valor seja alterado por algum script.
3. CSS Box Model: Após o método RenderStyle ser criado, ele é acessado via RenderObject. O Box model é usado para posicionar um elemento dentro da página, oferecendo suporte para o conteúdo, padding, bordas e margens que envolvem este elemento

Destruindo (ou atualizando) a Render Tree

A Render Tree é destruída quando nós da árvore DOM são removidos, causando a necessidade de um novo parse no DOM, ou quando uma tab do navegador com a árvore DOM usada é fechada. Após o refresh da árvore DOM, todo o processo acima é refeito, com attach chamando o RenderStyle, que montado chama o método style() do RenderObject que acessa o CSS BOX model.

Como os navegadores interpretam todos estes elementos criados por DOM e Render Tree antes de aplicar o estilo?

Todo navegador tem uma lista de elementos HTML suportados. Quando o seu markup possui tags presentes na lista, a árvore DOM é montada e o processo de attachment começa logo na sequência e os estilos são aplicados, dando continuidade a criação da Render tree.

O grande problema é que cada navegador tem a sua própria lista, que trata situações similares de maneiras diferentes. Obviamente já sabemos que o navegador que mais apresenta problemas para as situações acima é o Internet Explorer, mas acredite, todos os navegadores apresentam problemas quando um elemento não está em sua lista de elementos permitidos, e precisa de um trabalho para fazer tudo acontecer na Render Tree como deve ser feito.

Elementos fora desta lista são tratados como Elementos desconhecidos. E eles são uma grande fonte de problemas:

1. Como estilizar este elemento?Por exemplo, a tag <p> tem por padrão espacamento no topo e bottom, <blockquote> possui uma indentação automática adicionando uma margem à esquerda ou <h1> tem uma fonte maior que o <p> por ser um cabeçalho. Tudo isso esta padronizado, mas como cuidar de algo que não existe?
2. Como este elemento deve aparecer na árvore DOM?Os navegadores também possuem uma lista que mostra quais elementos podem ser filhos de outros elementos. Por exemplo, se você adiciona por engano no seu markup <p><p> o segundo paragrafo implicitamente fechará o primeiro <p>, fazendo que os dois elementos sejam irmãos (no mesmo nível na árvore DOM) e nao como nós filhos como de maneira linear pode parecer. Porém se vc adiciona um <p><span>, este paragrafo inicial não será fechado, porque o navegador permite que <span> seja filho de elementos de paragrafo, fazendo assim o <span> ser nó filho de <p>

Para elementos desconhecidos, a ideia é não estilizar. Caso queira algum estilo em elementos desconhecidos, você deve colocá-lo no nó acima (se necessário um wrapper), para fazer com que ele herde o estilo.

Perceba a sutileza de como isso funciona. Os dois diagramas mostram uma árvore DOM, montada por um navegador suporte HTML5 nativo e o Internet Explorer 8 (navegadores que não suportam HTML5 tem funcionamento semelhante):

Arvore DOM com suporte HTML5

Arvore DOM IE e outros navegadores sem suporte HTML5

É por essas e outras que a gente usa o modernizr, o HTML5shiv ou um simples document.create(“SECTION”) / document.create(“ARTICLE”). E é isso que acontece quando navegadores interpretam elementos desconhecidos. Eles desconsideram o nó real aonde o elemento está, e o reconhece como filho de <BODY>. E por favor, sem trocadilhos com o filho dos outros.

Ver como uma árvore DOM é montada  e como a Render tree é feita nos dá idéia do quão importante é ter um documento semântico. Realmente semântico. Uma vez entendidos os conceitos, a manipulação e a programação dos elementos fica mais fácil.

E você começa a entender como os navegadores funcionam.

Referências

Entendendo os Reflows por Alysson Franklin

Modernizr para suporte HTML5

HTML5shiv para suporte HTML5

Browser Wars pela Wikipedia

ECMAScript pela Wikipedia

Javascript pela Wikipedia

JScript pela Wikipedia

CSS Box model pelo W3C

DOM pela wikipedia 

Renderização no webkit, o básico pela webkit

W3C Overview do DOM

Declaração de atividades do DOM pelo W3C

Uma discussão sobre como Navegadores entendem elementos desconhecidos por Mark Pilgrim  

Traversing the DOM by Mike West

Progressive enhancement demystified by Aaron Gustafson

DOM, HTML5, CSS3 e Performance – Slides por Paul Irish

E também o @mariocaixa, esse cara tem o DOM!

Posts Relacionados

• Entendendo os Reflows
• Conteúdo, Flash e HTML
• Ah, o maravilhoso mundo real
• Agora é a vez dos desenvolvedores
• WebIntents – Framework para WebApps

CSS3 PIE

Aplicar propriedades CSS3 é bastante simples e nenhum segredo para desenvolvedores experientes, porém fazer com que estes atributos sejam aplicados aos novos e aos atuais browsers de mercado pode representar uma tarefa um pouco mais trabalhosa.

O browser IE (sempre ele) é um dos responsáveis por esse trabalho. Nas versões 7 e 8, não interpreta as propriedades que vamos demonstrar em nosso tutorial, desta forma, a renderização deverá acontecer através do uso de javascript (neste caso PIE) e mesmo que você não tenha familiaridade com a linguagem, não se preocupe, pois a aplicação deste é simples e baseada apenas na hospedagem de alguns arquivo no servidor e a chamada destes na classe ou ID correspondente no css.

Para iniciar, clique aqui e baixe os arquivos CSS3 PIE.
Após, descompacte os arquivos e os hospede no diretório raiz de seu site (seja online ou local) e pronto! Já podemos começar a utilizar bordas arredondadas, gradientes e sombras no IE 7 e 8.

Firefox, Chrome, Safari e Opera.

Todos os browsers acima citados, em suas versões de mercado, renderizam as propriedades que vamos aplicar neste tutorial, porém o Opera 10 não identifica o atributo que cria gradientes de background e desta forma, utilizaremos valores diferenciados para esta exceção.

Bordas arredondadas

Para inserirmos bordas arredondadas utilizando CSS3, basta inserirmos a propriedade border-radius e atribuir um valor para tanto, porém devido as diferenças entre browsers e considerando que suas versões de mercado ainda não suportam completamente o parâmetros, distribuimos esta declaração para cada navegador.

Como utilizar a propriedade?
border-radius – declaração integral para todas as bordas do box

Na prática:

.boxBorda{
border-radius: 15px; /* Implementação W3C */
-moz-border-radius: 15px /* Implementação Mozilla */
-webkit-border-radius: 15px; /* Implementação para browsers que renderizam via webkit */
behavior: url(PIE.htc); /* Comportamento adicionado para renderização das propriedades acima no IE 7 e IE 8 */
}

E pronto! A borda arrendonda dos elementos será renderizada.
Outras possibilidades de valores ainda são permitidas, por exemplo quando pretendemos atribuir um valor diferenciado entre a distância do centro do círculo imaginário ao topo ou à lateral.

Como utilizar a propriedade?
border-[top/bottom]-[left/right]-radius – declaração segmentada para cada uma das bordas do box

Na prática:

.boxBorda{
border-top-left-radius: 15px 20px; /* Implementação W3C */
-moz-border-radius-topleft: 15px 20px; /* Implementação Mozilla */
-webkit-border-top-left-radius: 15px 20px; /* Implementação para browsers que renderizam via webkit */
behavior: url(PIE.htc); /* Comportamento adicionado para renderização das propriedades acima no IE 7 e IE 8 */
}

Sombras

A propriedade que define sombra à um box, no CSS3, pode criar diversas possibilidades visuais desde que os atributos sejam declarados. Na totalidade da propriedade, o que podemos declarar é:

Como utilizar a propriedade?
box-shadow: [inset (declaração opcional e referente a shadow interna), posição X, posição Y, blur, largura, cor ]

Abaixo, as declarações para nosso exemplo:

.boxSombra{
box-shadow: 0 0 .25em #CCC; /* Implementação W3C */
-moz-box-shadow: 0 0 .25em #CCC;  /* Implementação Mozilla */
-webkit-box-shadow: 0 0 .25em #CCC; /* Implementação para browsers que renderizam via webkit */
behavior: url(PIE.htc); /* Comportamento adicionado para renderização das propriedades acima no IE 7 e IE 8 */
}

Background: linear-gradient ou radial-gradient
Para definir um degradê de fundo à um box utilizando CSS3, basta inserir a propriedade background: linear-gradient ou radial-gradient e declarar os devidos valores, porém esta propriedade ainda pode ser renderizada de forma diferente entre os browsers, inclusive nas porcentagens que saem de uma cor migrando para outra. De qualquer forma, dependendo do resultado que você pretende obter em tela é perfeitamente aplicável.

Como utilizar a propriedade?
background: linear-gradient{posição, cor (from), cor(to) porcentagem};

Segue o exemplo:

.boxGradiente{
background: linear-gradient(#EEF, #FFF 70%); /* Implementação W3C */
background: -moz-linear-gradient(#EEF, #FFF 70%); /* Implementação Mozilla */
background: -webkit-gradient(linear, 0 0, 0 70%, from(#EEF), to(#FFF));/* Implementação para browsers que renderizam via webkit */
-pie-background: linear-gradient(#EEF, #FFF 70%); Propriedade adicionada para renderização das propriedades acima no IE 7 e IE 8 */
background: url (image.png) repeat-x 0px 0px; /* Background com imagem para degradê para o Opera 10 */
}

Leia mais sobre gradientes em css, clicando aqui.

Veja um exemplo, clicando aqui. E baixe o código pelo nosso GitHub aqui.

Até a próxima.

Posts Relacionados

• Introdução ao CSS 3D – Flip Card
• CSS3 – Sombras em textos e elementos
• CSS3 – Módulo Template Layout
• CSS3 – Animation e regra keyframe
• CSS3 – Breve introdução ao RGBA

Coda e Textmate

Eu não consigo usar apenas um deles. O Coda tem um find/replace sensacional que me permite procurar pela pasta do projeto inteira ou pelo diretório atual. Infelizmente ele não tem uma série de outras facilidades que o Textmate tem, como macros e snippets. Na verdade o Coda tem sim suporte a isso, mas as features do Textmate são bem melhores. Em compensação o Textmate não tem um find/replace tão útil quanto o Coda e também não mantém a árvore de diretórios ao lado do editor, a não ser que você crie um projeto, o que é um pouco chato…

Os dois precisam se atualizar. O HTML5 está aí, juntamente com o CSS3 e o JQuery, mas eles continuam tendo só o doctype do HTML4.01 e XHTML 1.0. O Textmate tem alguns bundles que atualizam o código para entender essas novas tags.

GIT

Na Visie usamos o GIT como o controle de versão padrão. No começo eu era meio avesso a qualquer controle de versão. Não queria ter que ficar escrevendo a cada tarefa concluída o que exatamente eu fiz e como resolvi. É muito chato. Mas depois que eu me entreguei a essa “burocracia” já fui salvo diversas vezes. Não recomendo nenhum sistema de interface gráfica para utilizar o GIT, tem alguns muito bons, mas prefiro ainda fazer tudo via terminal.

Redmine

Todo gerente precisa de um ambiente onde ele possa contabilizar o processo de produção do seu projeto. Hoje, eu posso dizer que eu não sou nada sem o meu Redmine. Ele me avisa por email se alguém modificou o status do ticket, avisa o desenvolvedor que foi criado um ticket para ele, me avisa se alguém do projeto criou um novo ticket, me dá o relatório detalhado de horas de todo o projeto e uma das features mais importantes: integra com GIT e SVN… Coisa linda de Deus.

Illustrator

Nem preciso dizer muito. Uso o Illustrator para fazer quase tudo gráfico, desde layot até rascunhos de wireframes, embora o Axure seja mais adequado. Mas o Illustrator me traz uma flexibilidade como nenhum outro programa gráfico.

Migre.me ou Google Shortener

Qualquer um dos dois é uma boa pedida. A maioria dos links que posto no twitter do Tableless eu é feito com o Migre.me ou Google Shortener. Ambos trazem informações bem diferentes: o Google Shortener me passa o relatório de browsers, clicks, sistemas operacionais e etc… O Migre.me me mostra a quantidade de retweets, quem retweetou minha mensagem, quantidade de clicks e ainda me dá badges quando ultrapasso uma determinada meta.
Os dois são indispensáveis para quem quer resultado rápido e usa o Twitter para conversar com a comunidade.

OS X

Eu não consigo mais desenvolver em ambiente diferente. Tem que ser MacOS (o que me leva ao próximo tópico). Com um macbook pro padrão de 13” consigo abrir 3 máquinas virtuais, Photoshop, Illustrator, dois editores e 3 browsers… com uma máquina Windows eu nem podia sonhar com algo parecido. Só se comprasse uma máquina parruda demais.

Os atalhos de mouse e teclado me acostumaram mal. Um exemplo clássico são os malditos Hot Corners. Não vivo sem! Sem contar os Spaces, gerenciamento de memória, interface mais organizada, programas de terceiros bem feitos e que realmente funcionam.

Parallels

Com o Mac consigo cobrir as minhas necessidades de Firefox, Chrome e Safari. O problema é que o IE ainda existe, por isso uso o Parallels com 3 máquinas virtuais distintas: WinXP com IE6, WinXP com IE7 e Win Vista com IE8. Já sei que vou ter que instalar outra máquina virtual para o IE9, mas essa é outra história.

Vou convidar o @davitferreira, @thaipoplade, @talitapagani, o Pedro Rogério e o Henrique Pereira.

Posts Relacionados

• Experiência cross-device
• Especificação para touch screens
• Agora é a vez dos desenvolvedores
• Introdução aos padrões de codificação
• CSS1K

Com este pensamento, criei um PDF simples, onde cito os principais problemas se prever o desenvolvimento para browsers ou meios de acesso antigos. É um documento onde você poderá imprimir e dar para o seu chefe e integrantes da sua equipe. É uma ferramenta para que você tenha alguma munição para te ajudar a convencer aqueles que tentam insistir no erro de manter uma compatibilidade perfeita entre browsers atuais e browsers de 12 anos.

Baixar o PDF – Guerra contra o Terror

Update A Microsoft anunciou sue a partir de 2012 o IE terá atualização automática nos sistemas Windows XP, Windows Vista e Windows 7. Isso quer dizer que estamos mais perto da salvação.

Posts Relacionados

• Experiência deve ter começo, meio e fim
• Manipulando a metatag Viewport
• Novo parser HTML5 – FF4
• Convertidos do Tableless
• Quem precisa de versão mobile?

Programador Python (2)

Conhece todos os misteriosos acrônimos do mês e já desenvolveu coisas úteis com metade deles. É capaz de construir e manter funcionando um grande sistema inteiro sozinho, desde a contratação e configuração do servidor. Preferências para os que souberem:

• Bons conhecimentos de padrões web
• Bons conhecimentos de Javascript e Ajax
• Administração e uso de sistemas Linux
• Capacidade de trabalhar sem supervisão

São adicionais interessantes:

• Ruby
• Subversion
• Vim

Programador PHP (1)

Programador PHP Absurdamente Rápido. É um gênio do PHP. Come PHP com farinha. Requisitos:

Pelo menos 3 anos de experiência comprovada em PHP:

• PHP5 e orientação a objeto
• Experiência na modelagem de sistemas orientados a objeto
• Experiência na construção de sistemas de grande porte (muitas telas, muitos requisitos, muitos acessos, muuuuuitas transações)

São adicionais interessantes:

• Bons conhecimentos de padrões web
• Bons conhecimentos de Javascript e Ajax
• Experiência no gerenciamento de equipes
• Experiência com Smarty
• Experiência com sockets

UX especilista em Web

O cara que sabe o que é bom. Tem aquela visão que ninguém tem. Requisitos:

• Arquitetura de Informação
• Illustrator
• Photoshop
• Usabilidade

São adicionais interessantes:

• HTML
• CSS

Especialista client-side

Come HTML no café da manhã, CSS no almoço e Javascript no jantar. Só há um problema: somos muito, mas muito chatos com código html/css/javascript. Requisitos:

• HTML5
• CSS
• Javascript e JQuery

São adicionais interessantes:

• Outros frameworks de javascript como Mootools
• WordPress
• Sites para mobiles

Para todas as vagas

Esta vaga é para quem não gosta de rotina. Horário flexível, trabalho parcialmente à distância, uma coisa nova a cada dia. Muito, muito, muito trabalho, muita pesquisa, muito comprometimento e muita pressão. Também muita liberdade e a chance de aprender muito.

Envie seu curriculo com as informações abaixo para trampo@visie.com.br:

/
• Qual sua pretensão salarial?
• Trabalha como PJ?
• Morar em São Paulo
• Qual o seu sonho?

Mais comentados

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

Para que estes critérios sejam cumpridos, é necessário estabelecer uma abordagem para aplicar e garantir a efetividade da usabilidade através de padrões concisos de interfaces e rotinas de avaliação próprias para mensurar os diversos quesitos de interação do usuário com o website.

O Alysson Franklin já havia detalhado em um artigo aqui no Tableless um plano de usabilidade que passa por diversas etapas. Embora seja a metodologia mais adequada, em muitos casos é preciso adotar procedimentos mais ágeis e que também sejam eficientes.

Como forma de estabelecer um processo ágil para avaliação de usabilidade, uma das abordagens mais viáveis é a avaliação heurística, um método de inspeção onde os próprios especialistas da empresa avaliam a interface de acordo com as heurísticas de usabilidade. Neste tipo de teste, não há a presença dos utilizadores reais do sistema.

Checklist para avaliação heurística

Cada website irá demandar um roteiro mais específico de avaliação da usabilidade. Bastien e Scapin (1993) definiram 8 critérios ergonômicos para interfaces humano-computador: Condução; Carga de Trabalho; Controle Explícito; Adaptabilidade; Gestão de Erros; Homogeneidade; Significado de Códigos e Denominações; Compatibilidade.

Nem todos os projetos precisarão ser verificados em todos estes critérios. Sites corporativos que apresentam, em sua maioria, apenas textos e imagens têm uma avaliação diferente em aplicação web composta de diversas ações, formulários e requisições, mas alguns itens são elementares a qualquer tipo de website.

Abaixo apresento uma listagem de critérios que pode ser utilizados para avaliar desde websites estáticos a aplicações web, adaptado de um artigo do TestingGeek. É uma avaliação rápida e sobre questões mais triviais, mas se bem analisada e reportada pode ajudar a melhorar de forma considerável a interface com o usuário.

Cores

• O site deve utilizar (aproximadamente) cores padrões de links. Isto não significa utilizar links azuis, mas a cor e o estilo utilizados devem indicar que seja um hiperlink e necessitam permanecer consistentes.
• Os botões devem estar um formato e tamanho padrão. Se você utiliza botões em formatos ou estilos distintos para diferenciar a funcionalidade de cada grupo, garanta que cada botão esteja consistente em seu grupo e que os agrupamentos também estejam consistentes com o estilo geral utilizado no website.
• O plano de fundo da página não pode ser propenso a distrair o usuário do foco do site.

Conteúdo

• Todas as fontes devem ser as mesmas. Por exemplo, uma fonte escolhida para um subtítulo deve ser a mesma sempre na ocorrência deste tipo de texto e isto vale também para o estilo (negrito, itálico, etc).
• Os textos devem estar apropriadamente alinhados. Evite também utilizar vários alinhamentos de texto no site, preferencialmente escolha apenas um. Evite centralizar corpo de texto.
• Logo e textos de cabeçalho devem estar alinhados à esquerda. Esta é uma questão da cultura de leitura e escrita. No ocidente utilizamos a leitura da esquerda para a direita mas isto varia em outras regiões.
• Evitar o uso de caixa-alta em textos. Utilizar com moderação e para casos (muito) específicos avaliando se não há dificuldade de leitura.

Imagens

• Todas as imagens devem estar alinhadas apropriadamente.
• Deve-se garantir que os botões que representam comandos estejam todos com tamanhos e formas similares, além de fonte e tamanho de fonte consistentes.
• O formato dos banners (estilo, tamanhos e forma de exibição) devem ser os mesmos em todas as seções do site.
• O texto deve se ajustar corretamente ao redor das imagens e possuir um espaçamento, para que não passe a impressão de estar “aglutinado” à imagem.
• As páginas devem ser visualmente consistentes mesmo sem imagens.

Instruções

• As mensagens de erro e os textos de ajuda nos campos de formulários devem estar grafadas corretamente.
• Todos os campos e botões habilitados devem possuir texto de ajuda. Isto pode ser através de um texto próximo ao campo, o value do campo do formulário ou o atributo title.
• Mensagens de progresso devem estar presentes em ações que são dividas entre etapas durante várias páginas.

Navegação

• Todos os campos desabilitados e somente leitura devem ser evitados na navegação entre os campos do formulário pela tecla TAB.
• As barras de rolagem devem aparecer se necessário.
• Deve haver um link para a página inicial em cada página.

Usabilidade

• Todos os rótulos dos campos de formulário devem ser escritos corretamente e de maneira clara.
• As fontes não devem ser muito grandes nem tampouco muito pequenas para ler.
• Os nomes em botões de comando e caixas de opção não devem estar abreviados.
• Garantir que caixas de opções, botões de opção e botões de comando estão logicamente agrupados em áreas de agrupamento claramente demarcadas.
• As páginas devem ser impressas de modo legível sem cortar o texto.
• O site deve possuir um visual consistente e claramente reconhecível.
• Caso o site possua uma área de login, os usuários devem possuir a opção de efetuar login utilizando tanto um nome de usuário quanto um e-mail como ID.
• O site deve se ajustar às resoluções de tela mais comuns.
• A terminologia do site deve ser adequada aos usuários-alvo do site.

Como pode ser aplicado

No meu TCC, utilizei heurísticas para avaliar a interface de intranet que havia desenvolvido. Como forma de mensurar quais critérios atendiam às recomendações, inseri as heurísticas em uma planilha separadas por categorias semelhante às descritas acima. Ao lado de cada heurística, eu atribuía a seguinte pontuação:

• -1: não atende às recomendações
• 0: atende parcialmente às recomendações
• 1: atende completamente às recomendações

Os critérios que não atendem ou que atendem parcialmente às heurísticas devem ser analisados e reportados à equipe de desenvolvimento para montar um plano de melhoria e correção.

Se você deseja utilizar os critérios apresentados neste artigo, disponibilizei esta planilha para download.

Posts Relacionados

• Declarando idiomas no HTML
• WebIntents – Framework para WebApps
• Mobile First – A arte de pensar com foco
• Você sabe o que é a “nova usabilidade”? – parte II
• Você sabe o que é a “nova usabilidade”? – parte I

Apesar de ser um assunto antigo, a Usabilidade (assim como a Acessibilidade) engatinha no Brasil e, se nao fossem os Bandeirantes da Usabilidade que temos aqui, ainda estaríamos aprendendo a fazer faíscas. Por causa deles, parece que 2011 será o ano que vamos começar realmente a criar a roda. Agradecimento mais do que justo a quem desde 2007 tenta mostrar que sim, é uma cadeira que vale a pena conhecer.

Criar um Plano de Usabilidade é uma atividade que não deve ser feita com olhos de desenvolvedor. Poderíamos falar que um Arquiteto de Software teria mais facilidade de trabalho que um desenvolvedor web em si, puramente por questão de perfil. A infraestrutura de um produto é algo que usualmente fica sob a responsabilidade destes profissionais. Mas quando o assunto é internet, eu defendo que o Especialista em Usabilidade seja o Desenvolvedor, e não o Arquiteto. A não ser que o Arquiteto tenha sido no passado um desenvolvedor fervoroso de aplicações para internet. Nada contra, eu mesmo planejo tirar o meu ITAC* este ano, mas explico a minha posição:

O Desenvolvedor Web, com treinamento específico sobre o assunto pode oferecer mais a profissão por ter vivência na depuração de erros relativos a navegadores, agregando este valor no Plano de Usabilidade, salvando horas e barateando o custo do projeto ao longo do seu ciclo de vida. Arquitetos ou designers podem fazer Planos brilhantes, porém a possibilidade deste plano ser mais caro que um elaborado por um Desenvolvedor Web Sênior é muito maior.

Muito da profissão de Desenvolvedor é aprendido na base da tentativa e erro, pegando artigos e referências, testando, aplicando, aprendendo. Um arquiteto que estudou para isso, sem passar pelo desenvolvimento pesado, perde uma perna fundamental de aprendizado quando o assunto é Usabilidade. A perna do desenvolvimento nos permite pensar, planejar e aplicar uma solução para um determinado fim. E depois de desenolvido, podemos testar, entender como funcionou sua solução em cenários pre-determinados, mensurar os resultados. Isso nos fornece material para pensamento crítico, entendendo como algumas situações de erro podem ocorrer para que no futuro elas não se repitam. Se um desginer monta um layout que o desenvolvedor percebe a necessidade de uso em demasia de float e position por exemplo, ele poderá se preocupar com problemas de renderizacao com browsers antigos como o IE6 logo de cara. Se o desenvolvedor perceber que o position:absolute será usado por exemplo, ele já saberá que para que tudo fique bonitinho no IE6, ele terá que usar o atributo clear em todas as classes aonde o position estará presente por exemplo. Isso evitará problemões la na frente, quando nos testes se perceber que o IE6 se tornaria o seu pior pesadelo por exemplo. Esse diferencial da experiência, o Arquiteto não terá. Um Designer também não, mas um Developer sim.

Mas a experiência não é nada sem conhecimento, e se um dev quer realmente enveredar pelos mares da Usabilidade, ele precisa entender as fases de um Plano de Usabildade, e, principalmente, como aplicar um Teste de Usabilidade.

Criando um Plano de Usabilidade

Um Plano de Usabilidade é definido por 4 fases distintas: Planejamento, Análise, Design e Testes e Upgrades. Um plano como esse abraça muito mais que a Usabilidade em si, mas fala tambem sobre o projeto e o time como um todo.

O planejamento do projeto é fundamental porque ajuda a focar seus objetivos. Ele também ajuda a planejar as atividades de usabilidade que são parte do processo de desenvolvimento de um site. Você deve pensar sobre o que você quer alcançar e criar uma visão direcionada que irá beneficiar tanto os usuários quanto sua empresa. Um site usualmente está disponível para todos. Mas “todos” não é necessariamente a melhor definição da audiência do seu site. Um portal de conteúdo por exemplo estará aberto para quem quiser acessar suas notícias, mas se o portal não se preocupar em montar uma versão acessível de seu site para todos os navegadores, provavelmente usuários de regiões mais pobres (e por consequência donos de hardware mais desatualizado) vão experimentar problemas – quando conseguirem – ao acessar uma informação. Sinto falta de uma granularidade maior para defender aqui o meu ponto de vista (tenho apenas os números de versão de navegador no Brasil, e se você por favor tiver outros números, me envie a fonte, por favor) mas acredito fortemente que usuários de internet que estão no Amapá vao experimentar problemas de largura de banda, navegadores e resiliência por exemplo. Sem planejamento estes usuários ficariam no escuro e a penetração do seu produto em um mercado em potencial seria jogado no lixo. Para que isso nao aconteça, você precisa planejar antes de colocar a mão na massa – digo, no código.

Planejamento:

1. Desenvolvimento do Plano de Usabilidade
   Determinar o escopo do projeto, identificar audiência do site e definir objetivos do site.
2. Montar equipe do projeto
   A utopia começa cedo, logo no planejamento. Em tese, uma equipe de produção web deve ter Gerente de Projetos, Especialistas em Usabilidade, Editores de Conteúdo, Arquitetos de Informação, Designers Gráficos, Developers, e Especialistas no Conteúdo do site. Obviamente que estas 7 pessoas normalmente são apenas uma, no máximo 3 pessoas, mas é assim que as coisas funcionam e mesmo sendo um exército-de-um-homem-só, você precisará produzir por 7 se quiser vencer esta batalha.
   • Gerente de projetos: um profissional gabaritado para liderar e gerenciar um projeto complexo;
     Especialista em Usabilidade: Deve trabalhar no processo de design centrado no usuário (o famoso UCD). Vai ser o responsável por availar o site atual (se existente), a concorrência, conduzir as análises de tarefas, desenvolver os atores, escrever os cenários de teste, definir as métricas e objetivos, analisar os protótipos para encontrar problemas de Usabilidade, conduzir a análise de cartas com usuários do website e recomendar melhorias;
   • Editores de Conteúdo: Os escritores responsáveis por produzir o conteúdo que será colocado no website;
   • Arquitetos de Informação: Organizam a informação produzida de um modo lógico para a audiência. Trabalham próximos dos Arquitetos de Usabilidade para definir a nevegação do website;
   • Designers Gráficos: Responsáveis pelo design do website, trabalham na criação do mesmo e também do Design Paralelo.
   • Developers: Responsáveis pelas características técnicas do website, são também os que programam, colocando a mão na massa fazendo acontecer o trabalho dos designers gráficos, arquitetos de informação e especialistas de usabilidade.
   • Especialistas em Conteúdo: Revisores ou consultores sobre o conteúdo do seu website. Trabalham próximos dos editores para garantir que o conteúdo produzido esteja alinhado com os objetivos da empresa e também com as tendências de mercado.

   Normalmente, este exército numeroso se resumem a 4 pessoas apenas, um gerente de projetos (que pode ser o próprio contratante), um editor de conteúdo, um desenvolvedor e um designer. Sabemos que este número é ainda menor dependendo do contexto. Não é difícil uma única pessoa (ou duas) ser(em) a(s) responsável(is) por todas as fases do projeto.

3. Contratar Especialista de Usabilidade
   Com olhos de um developer, é fácil dizer que tirando o conteúdo e o design tudo pode ser feito por ele, afinal um gerente só se faz necessário quando temos uma equipe de trabalho com algumas pessoas. Mas desenvolver não é pensar em Usabilidade, e vice-versa. Um Especialista em Usabilidade deve estar preparado para:
   • efetuar pesquisas de/com usuários,
   • Fazer análise de tarefas e usuários,
   • Dar assistência ao nível executivo estabelecendo métricas de avaliação dos resultados de Usabilidade alinhados com a estratégia da empresa,
   • Escrever web services
   • Dominar a arquitetura da informação.

   Mas não é só isso, não falamos dos Testes de Usabilidade ainda. Um profissional destes deve estar preparado para:

   • Criar e aplicar os Testes de Usabilidade,
   • definir e recomendar os momentos do projeto aonde Testes de Usabilidade precisam ser feitos,
   • definir a quantidade de usuários e métodos de recrutamento para os testes,
   • definir os equipamentos e suas configurações para os Testes de Usabilidade (incluindo testes remotos),
   • definir as metricas coletadas, como elas serão usadas e como as informações serão reportadas, oferecendo com uma linguagem simples explicações sobre métricas ou problemas de Usabilidade encontrados (recomendações de mudança com documentação válida, tutoriais – preferencialmente em vídeo – para recriar bugs e como consertá-los,
   • Oferecer assistência para o time de desnvolvimento para implementar as recomendações.

   Percebe-se que o trabalho deste profissional é mais consultoria que mão na massa, mas fica visível que um developer precisa ir mais a fundo caso queira oferecer serviços nesta área também.

4. Declaração de trabalho SOW
   A Declaração de trabalho é uma ferramenta poderosa para o dono do negócio, e se bem montada, pode ser usada para obter estimativas de custo de fornecedores (agências web) realistas, ajudando na escolha da melhor entrega e do melhor custo. A Declaração de trabalho deve oferecer informações sobre o processo de Design Centrado no Usuario (UDC), avaliação do site atual, avaliação do usuário, arquitetura da informação e organização do conteúdo, testes interativos de usabilidade, definição do perfil de usuários para testes, definição de como a análise e testes serão feitos, definição de como a documentação deve ser produzida.
5. Reunião de Kick-off do projeto
   Hora de conhecer seus colegas de trabalho, como, quando e onde o trabalho será feito.

Como vimos, nesta fase definimos o que vamos fazer, em qual período de tempo, com quais pessoas e a qual custo. Esta é uma tarefa dos gerentes de projeto, e normalmente profissionais de desenvolvimento e design estão fora desta fase, assim como os profissionais de Usabilidade. Mas é uma boa recomendação é inverter os passos 2 e 3 e ter o Profissional de Usabilidade já neste momento de montagem da equipe, pois ele pode indicar de acordo com as necessidades do projeto o melhor leque de skillsets para profissionais de design e desenvolvimento, por exemplo. Para PMEs, esta fase pode ser customizada, e mesmo desenvolvedores freelancer podem utilizá-la.

Considere um representante de auto-peças automotivas por exexmplo; o seu cliente descobriu ontem que para ter mais penetração no mercado ele precisaria de um site na internet, que vai ter um cadastro básico de clientes para relacionamento e compra de peças, além de uma área institucional para apresentar a empresa. Isso é tudo que o dono dessa representação sabe. Nesta fase de Planejamento caberia a desenvolvedor ajudar o “nivel executivo” da auto-peças que o contratou a montar o SOW, mostrando que o site a se desenvolver, deverá ser funcional tanto para a Mecânica do Zezinho ali da esquina, que provavelmente tem um K6-2 com acesso de 100kbps quanto para as maiores lojas de mecânica do shopping, aonde o cliente vai com a família passar a tarde enquanto mecânicos deixam o seu carro como novo. Se a representação desta auto-peças tiver estes dois tipos de cliente, a página de pedidos deverá ser extremamente leve e funcional em vários tipos de browser, garantindo que o pedido, que é o que faz a representação comercial funcionar, seja feito, independente de usuário, plataforma ou velocidade de acesso.

Análise:

Analisar é fundamental antes de codificar, e, nesta fase, o quanto mais você coletar informações sobre seu site e seus usuários, melhor.

1. Analisando o Site atual
   Analisar o site atual quando o existente nos mostra aonde estamos e aonde queremos chegar. Pesquise o log do servidor e o log de termos pesquisa, reveja emails ou ligações feitas pelos clientes sobre os problemas que eles usualmente tem no website atual, faça um Teste de Usabilidade no site atual, conduza uma pesquisa online se possível e analise no site atual as diretivas básicas de desenvolvimento web para:
   • Processo de design;
   • Otimização da experiência do usuário;
   • Acessibilidade;
   • Página inicial;
   • Layout de páginas;
   • Navegação;
   • Scroll e paginação;
   • Cabeçalhos, títulos e labels;
   • Links;
   • Aparência do texto;
   • Listas;
   • Widgets e dispositivos de controle da tela;
   • Gráficos, imagens, ícones e multimídia;
   • Conteúdo;
   • Organização do Conteúdo;
   • Pesquisa interna;
   • Usabilidade

   Quando estes objetivos de Usabilidade estão definidos, podemos nesta fase documentar as métricas atuais para a famosa comparação antes-depois, que é uma das ferramentas que vai availar o seu trabalho. Caso o site não exista, recomenda-se contato com o time da empresa para responder questões de negócio que podem clarear ou direcionar o desenvolvimento do site.

2. Aprendendo sobre a Audiência
   Para mim, a principal parte do planejamento e análise é conhecer a sua audiência. Quem é o seu usuário? O que ele espera ao acessar o seu site? Como ele pensa, agrupa e organiza a informação encontrada em seu site? Como ele trabalha com a informação que você provê a ele? O quanto sua audiência quer ler em seu website? Qual o formato desta leitura? Como ele acessa esta informação? Todas estas são perguntas que você precisa saber antes de começar a codificar o seu website.

   Existem várias técnicas de se obter estas informações, e algumas delas são inclusive etapas do Plano de Usabilidade:

   • Teste de Usabilidade: sim, um teste de usabilidade mostra muito sobre a sua audiência e como o acesso ao seu site é feito. Pode ser feito remotamente.
   • Entrevistas contextuais: Um diálogo informal e presencial com um ou dois usuários por vez pode mostrar observações e principalmente, padrões de comportamento dos usuários ao navegar/usar seu website;
   • Pesquisas online: Coleta expectativas, experiências e opiniões sobre o seu site com um número pré-definido de pessoas.
   • Entrevistas individuais: Presencialmente ou via telefone, IM ou qualquer outro modo, fornece uma maior quantidade de informações devido ao formato com perguntas e respostas.
   • Análise de Cartas: Aplicada individualmente com cartas ou outros métodos de análise, consiste no feedback de como os usuários agrupam a informação disponível no seu website, mostrando os níveis lógicos e desvios entre como o cliente quer disponibilizar a informação e como a audiência a recebe de verdade.
   • Entrevistas de grupo: técnica de pesquisa de tradicional muito utilizada em marketing, produz diferentes tipos de informação das entrevistas contextuais: Em uma entrevista de grupo, os participantes falam sobre suas atividades e você ouve-os falar sobre seu trabalho. Em um Teste de Usabilidade típico ou entrevista contextual, os usuários falam e fazem suas atividades e você assiste e ouve-os durante o todo o processo.
3. Conduzindo Análises de Tarefas
   De forma sucinta, mostra quais os objetivos dos usuários ao acessar o seu site, o que eles fazem e como. Deve mostrar os passos efetuados para efetuar uma determinada ação e como agir diante das opções possíveis. Uma Análise de Tarefas deve oferecer para usuários únicos e grupos de usuário:
   • Mostrar as atividades (o que) os usuários fazem em seu website e como fazem;
   • Mostrar fatores pessoais, sociais e culturais que os usuários tem ao efetuar estas atividades;
   • Como o ambiente físico e suas limitações podem impactar nas atividades efetuadas pelo usuário?
   • Como o conhecimento prévio do usuário sobre o assunto influencia o modo como ele pensa durante o período de utilização do seu website.
4. Definindo Atores
   Para se mensurar as análises de tarefas, precisamos definir os tipos de usuários que acessam o seu site e o que eles fazem. Mantendo o exemplo da Representante Comercial de Auto-peças, poderíamos elencar perfis de Mecânicos, que pesquisariam informações técnicas sobre as peças e fariam pedidos, Atendimento ao cliente que pesquisam informações sobre os pedidos efetuados, público em geral que vai navegar pela parte institucional do site e Administradores que vão inputar informações sobre as peças e sobre o negócio em si. Cada um destes perfis vai executar uma determinada gama de tarefas, acessar um número autorizado de páginas e tudo isso deve ser documentado na análise feita no tópico 3. Cabe agora definirmos os atores, estes perfis hipoteticamente pensados, para depois podermos aplicá-los as Análises de Tarefas nos Cenários para Teste.
5. Escrevendo Cenários para teste
   Já explicado no tópico acima, mostra em detalhes as tarefas que devem ser feitas pelos atores para se atingir uma determinada atividade no website.
6. Estabelecendo Objetivos e Métricas
   Definir valores racionais para os cenários de teste com base em tempo, acurácia, eficácia e satisfação do usuário. No nosso exemplo de representante de auto-peças, poderíamos dizer que uma métrica de sucesso seria:
   • Fazer o usuário entender o fluxo de informação das páginas em 30 segundos para que ele possa rapidamente identificar a área de pedidos, parte principal do site;
   • Fazer a página de pedidos renderizar em qualquer navegador e qualquer conexão em até 35 segundos;
   • Fazer o usuário conseguir chegar a página de pedidos e fazer o seu pedido em até 2 minutos, pedindo a peça correta do fornecedor correto;
   • Errar no máximo um passo do cenário de teste e conseguir retornar ao fluxo correto de ações em no máximo 30 segundos,
   • Usuário rankear a experiência de fazer o pedido entre 4 e 5, em uma escala de 1 a 5.

   Verificadas os objetivos acima, devemos ponderar sobre o tempo de navegação, entendimento e renderização além do número de escolhas erradas na navegação, pesquisas improdutivas, erros usando a aplicação e erros de entendimento de página. Somado a satisfação do usuário em todo o processo, podemos quantificar o nosso sucesso (ou falha) definidos nos objetivos primários. Alguns outros exemplos seriam de objetivos seriam:

   • Website: 95% mínimo de usuários deve ser capaz de procurar uma peça e fazer um pedido no site;
   • Website: 100% dos mecânicos deve ser capaz de ler as informações das áreas de peças automotivas e entende-las completamente antes de fazer o pedido;
   • Website: O serviço de suporte ao usuário deve ser capaz de responder a perguntas por telefone dos clientes em até 3 minutos;
   • Cenário: 90% dos mecânicos deve conseguir achar a página sobre o Eixo Cardã em ate 45 segundos;
   • Cenário: 100% dos mecânicos deve conseguir identificar os updates em uma página, diferenciando novo conteúdo do conteúdo antigo em ate 5 segundos;
   • Cenário: 80% dos usuários deve ser capaz de encontrar e clicar em um link em ate 15 segundos;
   • Página: A pagina deve renderizar em ate 45 segundos em conexões discadas;
   • Página: A pagina deve renderizar em ate 15 segundos em conexões de banda larga;
   • Widgets: 100% dos usuários deve ser capaz de usar o filtro de range para selecionar peças em uma determinada faixa de preço;
   • Widgets: 100% dos usuários deve ser capaz de usar o filtro alfabético para encontrar informações sobre uma peça específica.

   No próximo artigo vou falar sobre a fase de Design e dos Testes e Upgrades. Namastê!

   Referências

   • ITAC
   • IE6 absolute positioning bug
   • Browser Wars no Brasil – Navegadores por versão de 01/10 a 12/10
   • Usability Statement of Work (DOC – 93KB)
   • Usability and Focus Group Participant Recruitment (DOC – 36KB)
   • Web Usability Consulting (DOC – 42KB)
   • Web Usability Testing (DOC – 48KB)

   Posts Relacionados

   • Declarando idiomas no HTML
   • WebIntents – Framework para WebApps
   • Mobile First – A arte de pensar com foco
   • Você sabe o que é a “nova usabilidade”? – parte II
   • Você sabe o que é a “nova usabilidade”? – parte I
   ]]> http://tableless.com.br/aplicando-um-plano-de-usabilidade-parte-1/feed/ 9