Tableless » padroes web

Experiência deve ter começo, meio e fim

Diego Eis — Mon, 28 Nov 2011 23:55:31 +0000

Esse artigo pode parecer meio confuso, mas é apenas um pensamento que estive matutando. Não ligue se a ordem das ideias estiverem tortas e sinuosas.

Tive uma experiência muito ruim no primeiro dia de 2010: pulei na piscina com meu iPhone no bolso.
Ok, pode me xingar agora.

Depois da tragédia, ele durou rápidos 5 segundos, e faleceu. Não ligava, não apitava, não fazia nada. “Paciência”, falei para mim mesmo. No dia seguinte peguei um celular reserva que eu tinha guardado: um HTC Touch, com Windows Mobile 6 (não Windows Phone). Foi então que eu notei o porque o trabalho da Apple vicia os consumidores.

Estamos bem acostumados a utilizar um notebook ou um computador desktop, com monitor, teclado e mouse. A interface do sistema muitas vezes parece desaparecer quando se abre o navegador. A experiência de uso dos periféricos já é bastante conhecida e isso facilita muito a forma com que o usuário interaje com a interface. Há uma harmonia, se é que você me entende. A mesma coisa é dificil de acontecer quando utilizamos um dispositivo mobile. Em um dispositivo móvel você precisa de foco. Não há espaço para milhares de botões com dezenas de ações. É SIM e NÃO. É OK ou CANCELAR e mais nada. O que não é o caso do Windows Mobile. O Windows Mobile foi feito daquele jeito Microsoft. Muito, mas muito diferente do Windows Phone que está um primor. Com uma interface totalmente repensada, do zero, onde seu visual se integra com os outros sistemas da marca. Há uma homogeneidade na experiência do usuário quando ele usa a Live do XBOX, o Windows Phone e o Windows 8. A experiência é cross-platform. A Apple faz isso durante anos. E durante todos estes anos esse foi seu segredo. O famoso “eco sistema Apple”. Tudo funciona muito bem quando estamos com nossos iPhones, iPads, MacBooks e iPods. Se eu tenho um iPad, mas utilizo um PC, algo fica estranho. Funciona, mas fica estranho.

Assim como sistema dos mobiles, os sites precisam seguir a mesma fórmula de simplicidade e foco. Por isso, criar sites para mobiles é uma arte. É um jogo de prioridades. Você precisa saber o que é importante na página e focar naquilo. Há um bom trabalho de arquitetura de informação que precisa ser feito. E não se engane, as vezes é muito mais dificil desenvolver um projeto de arquitetura para mobiles do que para versões full.

O iPhone, e agora o Windows Phone, se destacam muito por conta dessa harmonia que citei acima. Há uma ligação em tudo ali. Quando você aciona o Safari, ele tem uma interface intuitiva, bem acabada e que não agride a usabilidade do site. O iPhone tem um browser 100% atualizado com os Padrões Web e isso ajuda um bocado o desenvolvimento de interfaces inteligentes.
E a Apple se preocupa com essa harmonia da qual estamos falando, ela prepara uma série de materiais que ajudam os desenvolvedores. São guias de desenvolvimento e referência com os princípios de design e usabilidade que garantem a experiência completa. Por causa disso os desenvolvedores e designers fazem ótimos apps, tornando a experiência do usuário completa e uniforme durante o uso do dispositivo.

É por isso que a vale a pena municiar os desenvolvedores e designers do mundo todo, para que a experiência não termine quando o consumidor feche o seu aplicativo ou abra o navegador. Experiência tem começo, meio e fim. A Apple se preocupa com essas etapas. Ela sabe que se o site abrir “quebrado” o consumidor vai xingar primeiro o aparelho e não site. Tudo é uma única experiência. Começa no sistema do aparelho e termina no site de um terceiro.

O resto dos aparelhos começam pecando por ter um browser ruim ou uma interface de uso complicada. Na maioria os browsers não dão suporte algum aos Padrões. Isso é um pecado. Se eu tenho um Smartphone, eu passarei mais tempo na internet, conectado, do que falando ao telefone. Esse é apenas um ponto sobre o porque um dispositivo móvel precisa ter um browser decente.

O usuário tem uma boa experiência quando consegue com sucesso a informação que procurava, sem bloqueios. Se ele consegue passar esse processo com sucesso, como se o dispositivo (mobile, desktop, notebook, leitor e tela etc) e o site/sistema fossem transparentes, aí cumprimos com o nosso dever.

Posts Relacionados

O que é Usabilidade?

Talita Pagani — Mon, 22 Aug 2011 21:44:42 +0000

Já vimos em um artigo anterior como a usabilidade beneficia o desenvolvimento web. Mas, o que de fato compreende a usabilidade? Nem tudo que se refere à experiência de uso está dentro do escopo dela. Sim, a usabilidade tem limitações e lacunas que são complementadas por outros paradigmas, como o design de interação. Porém, podemos considera-la a base da pirâmide que sustenta o projeto de uma aplicação com boa experiência de uso. Neste artigo, veremos brevemente o que faz parte do conceito de usabilidade e qual o papel que ela tem no processo de desenvolvimento de aplicações.

Afinal, o que é usabilidade?

A Usabilidade é “filha” da Interação Humano-Computador (IHC) e “neta” da Engenharia de Software, carregando esse legado ao longo de sua evolução, podendo ser definida como o grau de facilidade com que o usuário consegue interagir com determinada interface.

Partindo da IHC, a usabilidade aborda a forma como o usuário se comunica com a máquina e como a tecnologia responde à interação do usuário, considerando as seguintes habilidades, de acordo com a norma ISO 9241:

Facilidade de aprendizado: a utilização do sistema requer pouco treinamento;
Fácil de memorizar: o usuário deve lembrar como utilizar a interface depois de algum tempo;
Maximizar a produtividade: a interface deve permitir que o usuário realize a tarefa de forma rápida e eficiente;
Minimizar a taxa de erros: caso aconteçam erros, a interface deve avisar o usuário e permitir a correção de modo fácil;
Maximizar a satisfação do usuário: a interface deve dar-lhe confiança e segurança.

Partindo da Engenharia de Software, a usabilidade é englobada dentro da qualidade e visa garantir uma parte da eficiência e eficácia do sistema. A eficiência refere-se a uma interação produtiva entre o usuário e o sistema, permitindo a realização de tarefas com menor esforço sob uma experiência agradável. A eficácia pode ser entendida como a capacidade do sistema e da interface possibilitarem ao usuário a completude da tarefa e o alcance de seus objetivos no sistema.

A importância da usabilidade no desenvolvimento de projetos

A usabilidade se encaixa em qualquer tipo de projeto de interface, tendo amplitude diferente de acordo com a criticidade do projeto, ou seja, quanto mais crítico for o sistema, maiores serão as perdas caso ele não seja de fácil utilização e proporcione satisfação. Ela deve ser pensada desde o planejamento do projeto, até a etapa de desenvolvimento e teste.

As empresas têm consciência da importância da usabilidade. Porém, muitas ainda a veem como um fator que só deve ser levado em conta durante o desenvolvimento se houver tempo e recurso, como se ela representasse um custo adicional, fora do que é essencial. Mas as empresas têm muito mais a perder ao minimizar a usabilidade dessa forma. De acordo com Cybis, Betiol e Faust (2007):

“Dependendo da frequência com que o software é empregado, os prejuízos para as empresas podem também ser expressivos, não só em decorrência do absenteísmo e da rotatividade do pessoal, mas também pela baixa produtividade, competitividade e menor retorno de investimento. Sistemas difíceis de usar implicam em erros e perda de tempo, fatores que se multiplicam com a frequência das tarefas e o número de usuários. A perda de dados e informações pode implicar na perda de clientes e de oportunidades. Acontecimentos deste tipo causam desde uma resistência ao uso do sistema até a sua subutilização e abandono completo, com o devido consentimento da empresa. O barato terá custado caro.”

A usabilidade pode ser abordada de diferentes formas ao longo do projeto:

Técnicas utilizadas para garantir e verificar a usabilidade em diferentes etapas

Lacunas a serem preenchidas

Apesar de a usabilidade ser responsável por assegurar grande parte dos quesitos de experiência do usuário, ela possui duas grandes limitações:

Embora considere a satisfação do usuário, trata apenas dessa satisfação perante a realização de uma determinada tarefa, concentrando-se na função, sem considerar fatores físicos, ambientais e emocionais inerentes ao contexto de utilização do sistema. Mais do que ser de fácil utilização, aprendizagem e permitir completude da tarefa, uma boa experiência de uso está baseada em uma interação agradável, considerando a forma como as pessoas percebem a interação com o sistema;
O contexto usualmente analisado pela usabilidade é mais restrito: abrange apenas a visão do usuário. Para garantir uma boa experiência de uso, é necessário abranger a visão de diferentes stakeholders: do usuário, da organização e da equipe de desenvolvimento, cada qual com requisitos e necessidades diferentes frente ao sistema.

Adaptando um gráfico apresentado durante a nnGroup Conference de 2008, podemos ver a usabilidade enquadrada da seguinte forma:

O escopo da usabilidade

Referências e Leitura Complementar

ABRAS, C.; MALONEY-KRICHMAR, D.; PREECE, J. User-Centered Design. In: Bainbridge, W. Encyclopedia of Human-Computer Interaction. Thousand Oaks: Sage Publications, 2004.

CYBIS, W.; BETIOL, A. H.; FAUST, R. Ergonomia e Usabilidade: Conhecimentos, Métodos e Aplicações. São Paulo: Novatec Editora, 2007. 344p.

SUMATHI, B. Chapter Three: User Centered Design Approach. Disponível em: http://dspace.fsktm.um.edu.my/bitstream/1812/214/8/Chapter%20Three.pdf.

NIELSEN, J.; LORANGER, H. Usabilidade na Web: Projetando Websites com qualidade. Rio de Janeiro: Elsevier, 2007. 406p.

OLIVEIRA NETTO, A. A. IHC – Interação Humano Computador: Modelagem e Gerência de Interfaces com o Usuário. Florianópolis: VisualBooks, 2004. 120p.

PREECE, J.; ROGERS; Y.; SHARP, H. Interaction Design: Beyond Human-Computer Interaction. New York: John Wiley & Sons, Inc., 2002. 551p.

ROCHA, H. R.; BARANAUSKAS, M. C. C. Design e Avaliação de Interfaces Humano-Computador. Campinas: Universidade Estadual de Campinas, 2007.

UX Revisions. The Difference Between Usability and User Experience. Disponível em: http://www.uxrevisions.com/user-experience-design/the-difference-between-usability-and-user-experience/18/

UX Revisions. User Experience vs User Interaction. Disponível em: http://www.uxrevisions.com/user-experience-design/user-experience-vs-user-interaction/16/

Usability Geek. The Difference (And Relationship) Between Usability And User Experience. Disponível em: http://usabilitygeek.com/the-difference-between-usability-and-user-experience/

NeoSpot. Usability vs. User Experience (UX). Disponível em: http://neospot.se/usability-vs-user-experience/

Interaction by Design. Usability vs. user experience. Disponível em: http://www.interactionbydesign.com/thoughts/thumbnails/00000050.html

Posts Relacionados

CSS3 – Breve introdução ao RGBA

Diego Eis — Mon, 02 May 2011 13:18:56 +0000

Introdução ao RGB

Normalmente em web trabalhamos com cores na forma de hexadecimal. É a forma mais comum e mais utilizada desde os primórdios do desenvolvimento web. Mesmo assim, há outros formatos menos comuns que funcionam sem problemas, um destes formatos é o RGB. O RGB são 3 conjuntos de números que começam no 0 e vão até 255 (0% até 100%), onde o primeiro bloco define a quantidade de vermelho (Red), o segundo bloco a quantidade de verde (Green) e o último bloco a quantidade de azul (Blue). A combinação destes números formam todas as cores que você pode imaginar.

No HTML o RGB pode ser usado em qualquer propriedade que tenha a necessidade de cor, como: color, background, border etc. Exemplo:

1
2
3
4
5

p {
background:rgb(255,255,0);
padding:10px;
font:13px verdana;
}

Este código RGB define que o background o elemento P será amarelo.

Aplicando o RGBA e a diferença da propriedade OPACITY

Até então nós só podíamos escrever cores sólidas, sem nem ao menos escolhermos a opacidade dessa cor. O CSS3 nos trouxe a possibilidade de modificar a opacidade dos elementos via propriedade opacity. Lembrando que quando modificamos a opacidade do elemento, tudo o que está contido nele também fica transparente e não apenas o background ou a cor dele. Veja o exemplo e compare. É aí que entra o RGBA.

O RGBA funciona da mesma forma que o RGB. No caso do RGBA, além dos 3 canais RGB (Red, Green e Blue) há um quarto canal, A (Alpha) que controla a opacidade da cor. Nesse caso, podemos controlar a opacidade da cor de background, borda, color ou qualquer propriedade que contenha cor sem afetar a transparência dos outros elementos:

Veja um exemplo aplicado abaixo:

1
2
3
4
5

p {
background:rgba(255,255,0, 0.5);
padding:10px;
font:13px verdana;
}

O último valor é referente ao canal Alpha, onde 1 é totalmente visível e 0 é totalmente invisível. No exemplo acima está com uma opacidade de 50%.

Como o Hexadecimal, você não precisa decorar todos estes números. Hoje, qualquer programa gráfico já dá o código do RGB da cor utilizada. O Hexadecimal não foi descontinuado. Se caso você tenha alguma cor que não ficará transparente ou algo do tipo, você pode continuar utilizando hexa e para aqueles que tem transparência, você pode utilizar o RGBA sem problemas.

Veja novamente o exemplo aqui e o código no github do Tableless.

Posts Relacionados

Manipulando a metatag Viewport

Diego Eis — Mon, 18 Apr 2011 13:00:09 +0000

O viewport é a área onde seu website aparece. É a área que você se preocupa se o vai ou não caber na hora da criação. O tamanho do viewport depende muito da resolução, tamanho do monitor e dispositivo utilizado. Em máquinas desktop nós não precisamos nos preocupar muito, já estamos acostumados com um determinado tamanho de tela e resolução média utilizada pelos usuários, que hoje gira em torno de no mínimo 1024 de largura. Mas quando começamos a variar muito o tamanho das telas, a largura do viewport começa a ser uma preocupação porque afeta diretamente a forma como o usuário utiliza seu website.

Hoje existe uma gama muito grande de aparelhos com telas de tamanhos variados. Comece a pensar pelos netbooks e depois vá diminuindo até chegar em um smartphone popular como iPhone, Milestone e etc. A variação de tamanho de tela é muito grande. Lembrando que o tamanho da tela é uma coisa e a resolução de tela é outra. Nunca confunda os dois. A largura da tela do iPhone na posição retrato é de 320px. Mas sua resolução padrão é 980px. Isso quer dizer que se você fizer um HTML simples, colocar uma imagem de 980px de largura e visualizar no iPhone, não existirá barra de rolagem. Obviamente a imagem ficará miniaturizada, como mostra abaixo:

Isso é interessante porque possibilita a boa visualização de websites que não estão preparados para mobiles. Vemos o site inteiro miniaturizado, com possibilidade de fazer zoom em qualquer parte do layout.

A tag meta viewport

Mesmo assim os smartphones tem telas pequenas podem dificultar a leitura se fizermos um sistema planejado para grandes resoluções. Por isso é interessante que possamos customizar o viewport para que ele se adeque a realidade desses dispositivos. É aí que entra a metatag viewport.
Com essa metatag iremos customizar a resolução inicial que o browser deve renderizar do viewport do dispositivo. Dessa forma, podemos preparar websites com resoluções personalizadas para smartphones e outros aparelhos.

A sintaxe é muito simples e deve ser colocada, como sempre, na tag head:

1	<meta name="viewport" content="">

Os valores de content são os que seguem abaixo:

Valor	Descrição
width	Define uma largura para o viewport. Os valores podem ser em PX ou “device-width”, que determina automaticamente um valor igual a largura da tela do dispositivo.
height	Define uma altura para o viewport. Os valores podem ser em PX ou “device-height”, que determina automaticamente um valor igual a altura da tela do dispositivo.
initial-scale	Define a escala inicial do viewport.
user-scalable	Define a possibilidade de o usuário fazer “zoom” em um determinado lugar da tela. É ativado quando o usuário bate duas vezes com o dedo em um lugar da tela.

Como usar

A tela abaixo não tem nenhuma tag de viewport definida.

Veja que o texto do elemento está bem pequeno. Isso é porque estamos visualizando-o em 980px de resolução em uma tela de smartphone.
Vou acrescentar a seguinte linha:

1	<meta name="viewport" content="width=320px">

Define que a largura do viewport será 320px. O resultado está abaixo:

Se inserirmos uma imagem ou um objeto maior que a largura do viewport, uma barra de rolagem é criada. Não precisa se preocupar com o espaço da barra, já que pelo menos nos OSs de smartphones novos, como iPhone e Android, a barra fica invisível e só aparece pro cima dos elementos.

Adicionando o initial-scale com o valor de 1.5, temos um aumento na escala da visualização. Abaixo segue um exemplo comparativo. A imagem inserida tem 320px de largura, logo ela ficará bem justa na tela quando a escala é 1.0, e um pouco estourada quando a escala é 1.5 ou maior. Veja:

Agora com escala de 1.5:

Agora com escala de 2:

E agora com texto, nas mesmas proporções:

Se colocarmos o user-scalable como NO, desabilitamos a possibilidade do usuário de fazer zoom quando ele bate duas vezes com o dedo. Deixar habilitado o zoom é interessante utilizar quando o viewport não está sendo customizado. No nosso caso aqui, isso não iria adiantar muita coisa, já que todos os elementos estão com o tamanho natural, por isso vamos desabilitá-lo.

1	<meta name="viewport" content="width=320px, user-scalable=no">

Atente-se para o detalhe de colocar , (vírgula) entre um valor e outro.
Veja um exemplo aqui. Tente ver com um smartphone como o iPhone, Android, etc.

Manipular o Viewport nos dá possibilidades para personalizar o visual de qualquer site para praticamente qualquer dispositivo, não importa sua resolução ou seu tamanho de tela. Quando unimos isso às media queries, temos um outro mundo de possibilidades.

Posts Relacionados

Novo parser HTML5 – FF4

Diego Eis — Mon, 28 Mar 2011 13:00:08 +0000

O Firefox é o meu browser favorito embora não seja meu browser padrão atualmente. Durante muito tempo ele me segurava com suas extensions exclusivas. Os outros browsers demoraram para ter uma coleção aceitável de extensions que realmente competissem com as do Firefox.
Foi lançado na semana passada o Firefox 4.0 que trouxe uma série de mudanças interessantes. Uma das atualizações mais importantes foi o “redesign” do parser de HTML5.

HTML5 parser

O parser do Firefox 4 foi todo reescrito para melhorar a performance e eficiência da renderização de código client-side. O motor antigo – de 1998 – foi descontinuado e agora com esse novo parser temos a possibilidade de utilizar SVG e MathML diretamente nas páginas HTML5 sem a utilização de namespace de XML. Entre outros diversos bugs que foram arrumados.

A esse novo parser foi escrito baseando-se na especificação do HTML5, que foi a primeira especificação que explica exatamente como os fabricantes de browsers devem ler e renderização o HTML. Estes detalhes técnicos não eram ditos nas versões anteriores das especificações do HTML. Basicamente o antigo HTML era ainda definido nos termos do antigo SGML. Isso implica na relação do código HTML e DOM. Isso quer dizer que o parseador consegue ler melhor a estrutura do nosso HTML e suas hierarquias. Claro, toda a performance do paseador é somente utilizada se o código for bem escrito e não tiver erros de sintaxe. A grande maioria dos sites na web ainda utilizam códigos mal escritos em HTML4. Leia mais sobre o DOM.

Para os casos onde o HTML for mal escrito, como em sites antigos que foram criados para suprir necessidades de browsers como Netscape e IE, o parser faz uma mudança de interpretação fazendo com que o Firefox entenda esse código antigo e não quebre o site. Logo, não precisamos manter um legado com códigos antigos e abre portas para a criação de código novo, mesmo estando em ambientes onde ainda é necessário conviver com código antigo.

MathML e SVG

Uma das vantagens desse novo parser é que ele permite que você sirva MathML e SVG diretamente na sua página sem ter que declarar a página inteira como XML/XHTML. Isso quer dizer que o código abaixo pode ser inserido normalmente em uma página HTML, sem qualquer namespace declarado.

Veja um exemplo de MathML:

 $x = \frac{- b \pm \sqrt{b^{2} - 4 a c}}{2 a}$

Veja o exemplo online.
Veja o código no Github.

Com o SVG é a mesma coisa, veja o código abaixo:

Veja o código acima em ação no nosso GITHUB.

Perceba que os códigos acima se parecem muito mais com um HTML do que com um XML. Perceba que não há nenhum namespace declarado. Isso é uma maravilha porque dá flexibilidade.

Pela explicação do Mozilla Hacks, o algoritmo é dividido em duas partes principais: tokenization e tree building (mantive o termo original porque a tradução literal seria muito estranha). A tokenization (algo como tokenização. Viu, falei que seria estranho) seria o processo de ler o fluxo do código de tags, comentários e atributos de tags. A tree building seria o processo de pegar essas informações encontradas pela tokenização e construir a árvore de tags, o árvore do DOM. O fluxo de tags que você construiu.

Outras atualizações

O Firefox 4 trouxe outras atualizações que podemos falar mais pra frente aqui no Tableless. São atualizações que navegadores Webkit já tem suporte e também o Opera, como: CSS Transitions, Formulários em HTML5, Audio Data API, History API, HTML5 Video buffered property, e o tão aguardado JägerMonkey o novo engine de Javascript da Mozilla.

Posts Relacionados

Convertidos do Tableless

Diego Eis — Mon, 21 Mar 2011 04:47:10 +0000

Quem acompanha o Tableless desde o começo conhece a história de como este humilde website nasceu. Eu estudava e aprendia CSS com HTML de uma única maneira: praticando. Eu convertia para tableless a home de alguns grandes sites just for fun. Só para provar que a técnica era real, possível e muito melhor que tabelas. O Tableless nasceu quando eu decidi compartilhar este material para outros desenvolvedores.

Este material não estava publicado porque uma das empresas que eu utilizei como estudo me mandou uma simpática carta extrajudicial dizendo que eu estava fazendo cópia indevida e todo aquele blá blá blá e que eu devia tirar o materia deles imediatamente do ar… Eles com certeza não eram bem humorados. Com medo de outras empresas fazerem o mesmo, tirei logo todos os exemplos publicados.

Neste fim de semana estava jogando algumas coisas fora e encontrei um CD com alguns documentos destes websites convertidos. Você pode verificar e baixar os arquivos nesta página. Até segunda ordem.

Atenção:

Se você é um troll babaca que vai analisar o código só para criticar como foi feito, entenda que o código mais antigo é de pelo menos uns 6 ou 7 anos atrás… Eu faria tudo diferente.

Se você pertence a alguma empresa listada nos exemplos, tenha em mente que esse material é utilizado apenas para estudo.

Posts Relacionados

PDF – Browsers antigos: guerra contra o terror

Diego Eis — Wed, 09 Mar 2011 14:46:33 +0000

É muito difícil tomar a decisão de não suportar browsers antigos ao produzir um grande site. Sempre há um número que se elevado a milhões de usuários o problema pode se agravar. Para uma grande empresa que tem 8 milhões de clientes, ignorar 1% destes usuários é algo realmente fora de questão. O ponto é que você não precisa ignorar estes valiosos 1%. Mas também não precisa gastar milhões nem perder muito tempo tentando resolver os problemas que estes usuários trazem para a produção. Nossa ideia aqui é dar a melhor experiência que eles podem ter sem prejudicar os outros 99%.  

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

Um raio-x do seu website

Alysson Franklin — Thu, 03 Mar 2011 17:52:58 +0000

A criacão de aplicações web evolui ao longo dos anos. A interação front-end/aplicação também segue esta evolução e é previsivel que a complexidade e a integração de funcionalidades com a interface web deva evoluir tambem. Só que para devs front-end, essa complexidade não está em novas linguagens ou tecnologias, e sim em como embarcar todas elas em um HTML semântico, limpo e de acordo com os requisitos. Tudo isso no menor tempo possível. Tempos ágeis, esses. As necessidades do cliente sempre não são compatíveis com nossos relógios e cada segundo vale nesse cenário.

Não é dificil abracarmos ferramentas que podem otimizar o nosso tempo. Fazer um mockup ou mesmo os primeiros protótipos sem usar Zen Coding podem ser tarefas demoradas. O Diego já mencionou isso aqui no Tableless há quase um ano e não é dificil vermos o pessoal maravilhado quando clicamos no tab e de repente a “mágica” acontece, montando um HTML inteiro. Não usar boilerplates ou grids pode ser fator determinante na demora no período de homologação. Mas até aí estamos falando apenas das ferramentas, e elas não são nada sem o conhecimento do desenvolvedor, somado a suas metodologias de trabalho. Nesta fase inicial de projeto, enviar uma arte para aprovação do cliente e algumas horas depois de aprovado já apresentar um modelo funcional básico, HTML/CSS com certeza pode garantir que o relacionamento cliente/desenvolvedor possa ser mais “tranquilo”, com uma pressão bem diferente se entre aprovação e o primeiro mockup tivermos um intervalo de um dia, por exemplo.

Só que isso não é tudo, é apenas a ponta do iceberg. Montar um mockup é o início do trabalho para garantir que esse design e as funcionalidades pedidas pelo cliente funcionem da mesma maneira, na maior gama de navegadores e dispositivos possível, e mesmo com suas limitações, oferecer a mesma experiência para os usuários. E isso é doloroso e nos toma muitas noites de sono que a gente teima em descontar xingando um ou outro navegador.

O Progressive Enhancement pode nos ajudar como mostramos em outros artigos. E hoje vamos mergulhar em um tópico específico da metodologia: iremos aprender como usar a perspectiva Raio-X para desconstruir uma página, separando o conteúdo do markup, usando abordagens top-bottom e bottom-up respectivamente. Dito isso vamos em frente que atras vem gente – e prazos cada vez mais apertados!

A Perspectiva Raio-X é baseada no princípio de que mesmo o mais complexo design – mesmo que seja algo dinâmico, como aplicações com AJAX com comportamentos estilo desktop – conteúdo e funcionalidade possam ser expressados com um simples HTML semântico, oferecendo uma experiencia acessivel e com Usabilidade para toda audiência.

Essa perspectiva nada mais é do que um metodo para planejarmos o design (sim, podemos usá-la para o design também) e desenvolvimento de modo a garantir, antes mesmo de começar, premissas que vão ser MUITO mais fáceis de seguir ao longo do desenvolvimento do projeto, afinal garantir acessibilidade e usabilidade desde o inicio é muito mais facil do que lá na frente, com tudo pronto, abracar o Graceful Degradation e um bom tempo brigando com javascripts que teimam em funcionar em um navegador e outro não. Você ainda terá que fazer isso, é fato. Mas é muito melhor trabalhar em um pequeno pedaço de código lá na frente do que descobrir que alterar um método desencadeará um efeito dominó que vai fazer você perder muito tempo entendendo o comportamento do script atraves da funcionalidades de uma aplicação.

Como o foco aqui é o desenvolvimento e não o design, partimos da premissa que já temos um design com funcionalidades e uma experiência que o visitante vai ter caso use o navegador do momento. Com esse design em mãos, antes de começar a codificar, planejamos um processo de desenvolvimento dividido em 3 partes:

Definir a hierarquia do conteúdo e sua prioridade, mapeando componentes para encontrarmos elementos básicos no HTML equivalentes a esta componentização.
Criar um markup de fundação, oferecendo todo o conteúdo essencial e funcionalidade com o mínimo de CSS(garantindo que o usado sejam “atributos seguros”) e ZERO de javascript.
Escrever o markup avançado, com CSS e javascript para cuidar da camada visual e funcional de acordo com as funcionalidades que cada navegador suporta.

Vale lembrar que essa experiencia é interativa, e mudanças no markup de fundação podem acontecer a medida que limitações no código são encontradas de acordo com os navegadores ou dispositivos testados. Mas estas mudanças serão pequenas e de fácil implementação, uma vez que todo o desenvolvimento foi planejado para minimizar este tipo de impacto.

Definindo Hierarquia de Conteúdo e mapeando componentes para o HTML

Algumas perguntas podem ser feitas para ordenar o fluxo de trabalho nesta fase do processo, elas vão ajudar a estabelecer regras e normas de inteface, centralizando estilo e regras de comportamento funcional no processo de desenvolvimento. Analisando o design, vamos aprofundar a analise pelos componentes visuais no trabalho. A partir da sala, comecamos nosso top-down:

Quais são as partes mais importantes da página?
O quanto de conhecimento sobre o assunto a audiência precisa para entender a informação da página? Há informação suficiente para este entendimento?
Existe uma ordem literal ou implícita para ordenar este conteúdo?
Olhando o site como um todo, existem partes em comum, com funcionalidades ou padrões de comportamento que podem ser reutilizados com templates?
Existe alguma tarefa que precisa ser feita na página? Se sim, quais são os passos que a audiência deve seguir e quais ferramentas ou plugins ela deve usar até completar estes requisitos? Existem passos adicionais/opcionais/mandatórios?
Existe conteúdo ou fluxo de pagina/formulários que dependam de opções previamente inputadas pela audiência?

Até aí estamos olhando apenas a sala. O código também precisa de uma abordagem parecida. É hora de olharmos a cozinha da aplicação e fazermos nosso bottom-up:

Existe algo que é inserido dinamicamente via AJAX? Se sim, temos que oferecer uma opção acessível, com conteúdo similar inserido na página ou em um HTML em separado;
Existem partes na interface que dependem de um workflow de escolhas aonde uma escolha determina opções em outra, ou ainda dependa de conexões já feitas em um servidor para validar o fluxo? Se sim, temos que ter certeza que estas experiências estao devidamente segregadas na versão básica da pagina, ajudando usuários a serem mais eficientes na tarefa da cognição, minimizando erros e complicações.
Existem partes na interface que são complicadores devido a alto grau de consumo de banda ou dificuldade de uso para uma experiência básica que são construidas apenas com markup HTML? Se sim, podemos oferecer componentes simplificados no markup de fundação ou ainda encorajar usuários básicos a viver a experiência através de uma alternativa offline.

Com estas duas análises da sua aplicação, fica fácil fazer o mapeamento dos componentes na página e quais elementos básicos do HTML melhor suportam a causa-fim. Ao mesmo tempo, analisamos como implementar o CSS e o Javascript a este markup. Se é necessário algum trabalho adicional para garantir a acessibilidade, é o momento de analisar a abordagem a ser usada. Com isso temos definido a hierarquia de conteúdo e seus agrupamentos, funcionalidade de todos os elementos de página associados a elementos básicos HTML, garantindo markups e estilos mínimos para uma expêriencia básica que todos os usuários – independentes de navegador ou dispositivo possam ter. A partir daí trabalhamos estilos e scripts a serem incorporados a experiência básica, tratados como um expansão que o usuário pode viver dependendo do seu navegador.

HTML4 x HTML5 – Ganhando tempo

O W3C ainda esta incorporando funcionalidades ao HTML, mas isso não significa que você não pode usar o HTML5 dependendo dos requisitos do projeto. De fato o HTML5 melhora e muito a produtividade, incorporando melhorias na linguagem que salvam tempo na criacao de componentes (como placeholders no input, datepickers avançados, players de áudio e vídeo, para mencionar alguns), porém com o foco em Progressive Enhancements, é necessario manter o foco na usabilidade – um player de vídeo por exemplo precisa de um plano de fallback para navegadores que não suportam o HTML5, como o IE6 (na ausência do suporte, um player flash pode ser carregado).

Pesquisas com desenvolvedores indicando o que tem sido codificado e colocado em produção mostram que as implementações estão a todo vapor. Por ordem de popularidade e facilidade na implementação:

Semântica
Melhorias de formulário
Áudio / Vídeo
Canvas
Outros
Drag and Drop
Microdata
Geolocation
Offline Storage
Cross Document Messaging

O uso depende de estudo. Quanto mais direcionado for o escopo do projeto, mais você poderá tirar vantagem do HTML5. Separando o HTML5 em 3 partes distintas, teriamos:

Nível 1: elementos que ganharam nova semântica, a maior parte deles sem nenhuma mudançaa drástica – exceção ao elemento deâncora , que agora permite nao apenas links inline (no contexto linear, uma frase por exemplo), mas tambem links em bloco. Fazendo com que em determinadas situações possa ter o mesmo comportamento de um
por exemplo. Estas melhorias são amplamente suportadas pelos browsers e não tem porque não utilizarmos as mesmas. Podemos mencionar a sintaxe simplificada, redução nas chamadas de DOCTYPE, charset,