A evolução dos usos orienta-se cada vez mais para os dispositivos móveis e os tabletes. A web é (e será) cada vez mais móvel e acessível de qualquer lugar, sob condições heterogéneas. Agora não podemos nos basear nas estatísticas de visitas dos sites para saber para qual configuração hardware e software particular um site deve ser concebido, uma vez que não existe mais um modelo ideal de usuário (que nem nunca existiu na verdade).
Se a tendência de marketing é orientar-se para sites especificamente dedicados ao iPhone ou ao iPad com as suas taxas de penetração, é inconcebível fechar-se a todos os outros dispositivos atuais e futuros cujas características diferem e diferirão cada vez mais.
Agora temos de nos adaptar a um panorama tecnológico em mudança, tanto em termos dos dispositivos utilizados (refiro-me especificamente aos tabletes já bem estabelecidos) do que em termos de uso (couch surfing a frente da televisão para os tabletes, em qualquer lugar com os telemóveis, e cada vez menos computadores desktop em partes relativas).
Para acompanhar esta evolução, é hora de repensar a do conteúdo e da sua arquitetura para publicar o mesmo conteúdo em todos os dispositivos. E em primeiro lugar, quebrar as idéias falsas: a web móvel não existe, há só conteúdo que se mostra de forma diferente de acordo com os dispositivos utilizados (e ja o sabemos por algum tempo).
Do mesmo modo, é difícil prever o contexto de uso dos celulares. O usuário móvel não é, como o imaginávamos há pouco, uma pessoa que viaja e que busca informações específicas com alguma emergência, mesmo o contrário.
O web design responsivo (ou responsive web design) permite ao seu conteúdo ficar disponível independentemente da situação de utilização. À medida que se implementa na sua organização, da simples adaptação do design do seu site à refundação em profundidade da sua gestão de conteúdo, você vai ver o valor central do seu site chegar à tona da água: o conteúdo e o serviço.
Em primeiro lugar, vejamos rapidamente duas definições.
Com o advento do HTML5 e do CSS3, e a adaptação lenta dos navegadores do mercado (e da sua atualização pelos usuários), duas palavras apareceram em nosso vocabulário: os shims e os polyfills. Um shim é uma solução de compatibilidade de aplicativos para a retrocompatibilidade deles (como simular o DOS em Windows).
Um polyfill é um shim que imita uma API futura proporcionando uma funcionalidade não suportada pelos navegadores mais antigos (definição de Paul Irish).
Geralmente, um polyfill é um plugin javascript que permite a um navegador antigo ou que ainda não suporta um padrão atual ou futuro de suportá-lo (porque não existia no seu tempo). Esto inclui, por exemplo, o suporte dos cantos arredondados (border-radius) sob IE6-9 (CSS3 Pie).
Eis uma lista de polyfills HTML5 e CSS3/4.
Media queries CSS3 permitem a adaptação do conteúdo mostrado dependendo do tamanho dos ecrãs (e da orientação deles). Colocam diretamente a questão da arquitetura do conteúdo (o que mostrar em quais ecrãs para se concentrar na informação a mais útil quando o espaço não é suficiente e, assim, remover o supérfluo ou rejeitá-lo mais baixo), mas também a da ergonomia.
Por exemplo, o tipo de menu pode variar de acordo com o dispositivo: tabs ou links de texto nos ecrãs grandes, substituídos por uma caixa de seleção nos ecrãs menores (ver a solução de CSS Tricks). Também, dados tabulares podem ser empurrados num ecrã secundário disponível mediante pedido (como neste exemplo).
Respond.js é um polyfill para media queries min/max-width (IE6-8 e outros).
No exemplo seguinte, o espaço do conteúdo reduz-se no mesmo tempo do que a largura da janela: a imagem, depois o menu e, finalmente, a superfície útil, até a minimização do desenho para concentrar-se no próprio conteúdo. O supérfluo desaparece e dá lugar para o conteúdo.
Uma solução ideal de web design responsivo deveria adaptar-se a qualquer tamanho de ecrã, sendo completamente fluido (pensem porcentagens em todos os pisos). Porém, é comum suportar os telefones pequenos (240x320), o iPhone (320x480), os tabletes pequenos (480x600), o iPad (768x1024) e os ecrãs de computador (ou de televisão) maiores, seja em modo retrato ou paisagem.
Obtemos a série seguinte de media queries, que poderiamos continuar para suportar ecrãs maiores:
O enfoque RESS, para Responsive Web Design with Server Side Components, vai mais longe trabalhando também no lado do servidor. Trata-se de ajustar a exibição de acordo com os dispositivos utilizados, mas também com o seu desempenho (velocidade de download, tamanho das imagens, suporte para vídeo) e a experiência do usuário, dependente em parte do modelo de interação (ecrã táctil, mouse, clickwheel). A detecção do dispositivo faz-se através de um banco de dados (por exemplo wurfl), e as diferentes variáveis do dispositivo são armazenadas num cookie. Apenas os conteúdos suportados e adaptados são enviados para o cliente. Esta apresentação de Anders Andersen é um bom resumo disso.
No enfoque do lado do cliente, todo o conteúdo é enviado, e o javascript (penso aqui em Modernizr) administra a parte da interação e do display.
Se o redimensionamento em CSS pode ser uma solução viável, vai como o redimensionamento em HTML através dos atributos width e height da marca img: a imagem enviada ainda é tão pesada. O enfoque é, por conseguinte, enviar imagens de tamanhos diferentes de acordo com o dispositivo utilizado (a sua área de display útil, ou viewport), mas também a velocidade da rede, a orientação do ecrã, a densidade de pixels (dpi)…
O WhatWG (Web Hypertext Application Technology Working Group) trabalha atualmente no atributo srcset que lista uma série de imagens dependendo do tamanho do ecrã.
Em paralelo, o RICG (Responsive Images Community Group) do W3C trabalha sobre outras propostas possíveis, incluindo a marca <picture> para a qual uns polyfills já foram desenvolvidos (ver o artigo Responsive Images and Web Standards at the Turning Point do Mat Marquis em A list apart).
Embora seja demasiado cedo para poder dizer qual implementação será proposta como padrão e suportada pelos navegadores, a marca <picture> já é viável para a comunidade.
Nota-se também que o HTML evolui em todos os lados ao mesmo tempo: o W3C para os padrões (e a sua tendência para o XHTML), o WhatWG (Apple, Mozilla, Opera, ou os «fabricantes») com a sua própria visão do HTML, e a comunidade que já não parece querer ser ditada as suas ferramentas (daí os polyfills construídos sobre jQuery).
Aqui estão algumas ferramentas de teste on-line:
Se a tendência de marketing é orientar-se para sites especificamente dedicados ao iPhone ou ao iPad com as suas taxas de penetração, é inconcebível fechar-se a todos os outros dispositivos atuais e futuros cujas características diferem e diferirão cada vez mais.
Agora temos de nos adaptar a um panorama tecnológico em mudança, tanto em termos dos dispositivos utilizados (refiro-me especificamente aos tabletes já bem estabelecidos) do que em termos de uso (couch surfing a frente da televisão para os tabletes, em qualquer lugar com os telemóveis, e cada vez menos computadores desktop em partes relativas).
Para acompanhar esta evolução, é hora de repensar a do conteúdo e da sua arquitetura para publicar o mesmo conteúdo em todos os dispositivos. E em primeiro lugar, quebrar as idéias falsas: a web móvel não existe, há só conteúdo que se mostra de forma diferente de acordo com os dispositivos utilizados (e ja o sabemos por algum tempo).
Do mesmo modo, é difícil prever o contexto de uso dos celulares. O usuário móvel não é, como o imaginávamos há pouco, uma pessoa que viaja e que busca informações específicas com alguma emergência, mesmo o contrário.
O que pode ser feito para se adaptar a esta mudança de cenário?
O web design responsivo (ou responsive web design) permite ao seu conteúdo ficar disponível independentemente da situação de utilização. À medida que se implementa na sua organização, da simples adaptação do design do seu site à refundação em profundidade da sua gestão de conteúdo, você vai ver o valor central do seu site chegar à tona da água: o conteúdo e o serviço.
Definições
Em primeiro lugar, vejamos rapidamente duas definições.
Com o advento do HTML5 e do CSS3, e a adaptação lenta dos navegadores do mercado (e da sua atualização pelos usuários), duas palavras apareceram em nosso vocabulário: os shims e os polyfills. Um shim é uma solução de compatibilidade de aplicativos para a retrocompatibilidade deles (como simular o DOS em Windows).
Um polyfill é um shim que imita uma API futura proporcionando uma funcionalidade não suportada pelos navegadores mais antigos (definição de Paul Irish).
Geralmente, um polyfill é um plugin javascript que permite a um navegador antigo ou que ainda não suporta um padrão atual ou futuro de suportá-lo (porque não existia no seu tempo). Esto inclui, por exemplo, o suporte dos cantos arredondados (border-radius) sob IE6-9 (CSS3 Pie).
Eis uma lista de polyfills HTML5 e CSS3/4.
CSS e media query
Media queries CSS3 permitem a adaptação do conteúdo mostrado dependendo do tamanho dos ecrãs (e da orientação deles). Colocam diretamente a questão da arquitetura do conteúdo (o que mostrar em quais ecrãs para se concentrar na informação a mais útil quando o espaço não é suficiente e, assim, remover o supérfluo ou rejeitá-lo mais baixo), mas também a da ergonomia.
Por exemplo, o tipo de menu pode variar de acordo com o dispositivo: tabs ou links de texto nos ecrãs grandes, substituídos por uma caixa de seleção nos ecrãs menores (ver a solução de CSS Tricks). Também, dados tabulares podem ser empurrados num ecrã secundário disponível mediante pedido (como neste exemplo).
Respond.js é um polyfill para media queries min/max-width (IE6-8 e outros).
Um exemplo em imagem
No exemplo seguinte, o espaço do conteúdo reduz-se no mesmo tempo do que a largura da janela: a imagem, depois o menu e, finalmente, a superfície útil, até a minimização do desenho para concentrar-se no próprio conteúdo. O supérfluo desaparece e dá lugar para o conteúdo.
Quais larguras de ecrãs suportar?
Uma solução ideal de web design responsivo deveria adaptar-se a qualquer tamanho de ecrã, sendo completamente fluido (pensem porcentagens em todos os pisos). Porém, é comum suportar os telefones pequenos (240x320), o iPhone (320x480), os tabletes pequenos (480x600), o iPad (768x1024) e os ecrãs de computador (ou de televisão) maiores, seja em modo retrato ou paisagem.
Obtemos a série seguinte de media queries, que poderiamos continuar para suportar ecrãs maiores:
@media only screen and (min-width: 240px) and (max-width: 319px) {}
@media only screen and (min-width: 320px) and (max-width: 479px) {}
@media only screen and (min-width: 480px) and (max-width: 599px) {}
@media only screen and (min-width: 600px) and (max-width: 767px) {}
@media only screen and (min-width: 768px) and (max-width: 799px) {}
@media only screen and (min-width: 800px) and (max-width: 1023px) {}
@media only screen and (min-width: 1024px) {}
Ir mais longe
RESS
O enfoque RESS, para Responsive Web Design with Server Side Components, vai mais longe trabalhando também no lado do servidor. Trata-se de ajustar a exibição de acordo com os dispositivos utilizados, mas também com o seu desempenho (velocidade de download, tamanho das imagens, suporte para vídeo) e a experiência do usuário, dependente em parte do modelo de interação (ecrã táctil, mouse, clickwheel). A detecção do dispositivo faz-se através de um banco de dados (por exemplo wurfl), e as diferentes variáveis do dispositivo são armazenadas num cookie. Apenas os conteúdos suportados e adaptados são enviados para o cliente. Esta apresentação de Anders Andersen é um bom resumo disso.
No enfoque do lado do cliente, todo o conteúdo é enviado, e o javascript (penso aqui em Modernizr) administra a parte da interação e do display.
O desafio das imagens adaptativas
Se o redimensionamento em CSS pode ser uma solução viável, vai como o redimensionamento em HTML através dos atributos width e height da marca img: a imagem enviada ainda é tão pesada. O enfoque é, por conseguinte, enviar imagens de tamanhos diferentes de acordo com o dispositivo utilizado (a sua área de display útil, ou viewport), mas também a velocidade da rede, a orientação do ecrã, a densidade de pixels (dpi)…
O WhatWG (Web Hypertext Application Technology Working Group) trabalha atualmente no atributo srcset que lista uma série de imagens dependendo do tamanho do ecrã.
Em paralelo, o RICG (Responsive Images Community Group) do W3C trabalha sobre outras propostas possíveis, incluindo a marca <picture> para a qual uns polyfills já foram desenvolvidos (ver o artigo Responsive Images and Web Standards at the Turning Point do Mat Marquis em A list apart).
Embora seja demasiado cedo para poder dizer qual implementação será proposta como padrão e suportada pelos navegadores, a marca <picture> já é viável para a comunidade.
Nota-se também que o HTML evolui em todos os lados ao mesmo tempo: o W3C para os padrões (e a sua tendência para o XHTML), o WhatWG (Apple, Mozilla, Opera, ou os «fabricantes») com a sua própria visão do HTML, e a comunidade que já não parece querer ser ditada as suas ferramentas (daí os polyfills construídos sobre jQuery).
Algumas leituras
- Responsive Web Design (em inglês), por Ethan Marcotte, publicado por A Book Apart, é um livro que todos deveriam ler.
- Mobile First (em inglês), por Luke Wroblewski, na mesma coleção, completa-lo bastante bem.
Bookmarks
Aqui estão algumas ferramentas de teste on-line:
Conception web adaptative (em francês)
Responsive web design (em inglês)
El diseño web adaptativo (em espanhol)
his week I was designing the website for the company I am currently working, Web Design Chennai
ResponderEliminar