Agora, a bola da vez é criar designs responsivos como se não houvesse o amanhã. É aí que entra a pergunta: você precisa de um design responsivo?

A maioria dos browsers para dispositivos móveis fazem um bom trabalho em websites que não tem versão específica para mobiles. Desde a vinda do iPhone, todos os browsers para mobiles se adequaram de uma forma que antes apenas o Opera abordava. Hoje, quando navegamos em qualquer website, tendo ou não versão para mobile, temos uma boa experiência. Aí vem o ponto: será que criar um site responsivo é o mais importante para o negócio do seu cliente? Produzir um website mobile friendly não é apenas modificar sua carinha, colocar ícones bonitinhos e pronto. Há outros pontos a serem abordados que são tão ou mais importantes que este.

Veja um comentário do Brad Frost em seu artigo:

Your visitors don’t give a shit if your site is responsive. They don’t care if it’s a separate mobile site. They don’t care if it’s just a plain ol’ desktop site. They do give a shit if they can’t get done what they need to get done. They do give a shit when your site takes 20 seconds to load. They do care when interactions are awkward and broken.

Entende o que eu quero dizer? Um dispositivo móvel já é mais dinâmico por natureza que os desktops. Os aparelhos móveis de hoje em dia nos fazem querer os resultados mais rapidamente. Se você tiver um website desenhado apenas para desktops, mas mesmo assim ele é rápido, os usuários de mobile vão agradecer. Já vi muitos websites mobiles que foram apenas adequados… Isso não é produzir um site mobile. Se seu site é bem desenhado e sua usabilidade impecável, ter um design responsivo passa a ser secundário e você passa a dar atenção coisas mais importantes, por que mesmo sendo uma versão desktop, o usuário conseguirá navegar sem muitos problemas.

Mas você quer dizer que sites mobile não importam?

Não, não quero dizer isso. Pelo contrário, eles importam e muito. A experiência do usuário é muito melhor se houver uma versão mobile, sem sombra de dúvida. Mas do que adianta ter uma versão mobile se o site demora 20 segundos para carregar? O dev cria a versão mobile, mas ele não faz adaptação nenhuma nas imagens (e não estou falando apenas de mudar a dimensão dela), não usa com inteligência o font-face, que embora seja maravilhoso, come muita banda… Acontece que ter carinha bonita não quer dizer que é fácil de usar.

Experiência de usuário é o foco

O foco é buscar a melhor experiência possível que o usuário pode ter em seu dispositivo. Nós usamos responsive web design para levar a experiência do usuário para outro nível. Não apenas por que está todo mundo fazendo. Você não precisa fazer seu site se adequar ao redimensionar a janela. É bonito? Sim, claro, mas só pra impressionar, porque não é muito útil se você parar para pensar.

No front-end, a experiência do usuário vai muito além do design. Responsive web design não é uma modinha é mais uma ferramenta para usarmos em pról da boa experiência do usuário. É por isso que na construção dos nossos projetos, podemos iniciar o trabalho pensando primeiramente nos mobiles e depois nos desktops. Isso nos faz mirar em objetivos mais importantes, não apenas para mobiles, mas para os desktops também, bem como tablets, tvs e todo o resto que vem por aí.

Alguns artigos para você dar uma olhada:

• Why is Responsive Web Design Such A Big Deal? Seriously…You Tell Me
• responsive web design: missing the point
• Which One: Responsive Design, Device Experiences, or RESS?
• Mobile First – A arte de pensar com foco
• A usabilidade deve ser pensada por todos

Posts Relacionados

• Qualidade de Imagens e densidade de pixels
• Utilizando APPs em vez de browsers
• Mobile First – A arte de pensar com foco
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão

Os dispositivos móveis se tornaram uma febre e vieram para ficar. É a melhor forma de fazer a inclusão digital para aqueles que não tem uma forma de ter um notebook ou um desktop em casa. Não estou falando daqueles smartphones de R$1500, mas dos muitos smartphones, com teclados qwerty, prontos para internet e que custam R$200. Isso sim é inclusão digital para as massas de verdade.

Alguns números

As vendas de smartphones já passaram as de PCs. A utilização de emails pelos dispositivos móveis aumentou em 36%. Sem contar que o tráfego de visitação de websites utilizando smartphones cresceu 600% em 2010!

O Paypal tempos atrás recebia algo em torno de $10 Milhões de dólares em pagamentos via mobiles. Por dia! Eles tem uma predição de movimentar algo em torno de 6 Bilhões só este ano! E em 2016 serão $31 Bilhões!

As perspectivas globais são enormes. Abaixo, veja um inforgráfico que o blog The Meta Cloud preparou. Cuidado para não se assustar.

O conceito

Você consegue entender estes números? Se sim, você vai entender que o conceito do Mobile First faz muito sentido, mas vai contra toda uma tradição de desenvolvimento de sites que você está acostumado. A ideia do Mobiles First é que comecemos a desenvolver e planejar projetos web, desde um pequeno site até um grande sistema, primeiramente para dispositivos móveis e somente depois para desktops/notebooks.

Algumas vantagens

Se o mundo inteiro está passando mais tempo acessando a internet com dispositivos móveis, não é muito sensato pensarmos primeiramente em fazermos sites para desktops/notebooks, não é? O fato é que ao colocar os mobiles primeiro lugar, desfrutamos de uma série de vantagens:

• As capacidades técnicas são mais interessantes. Com o mobiles você pode brincar com o acelerometro, GPS, multitouch, giroscópio e etc. Isso amplia a experiência do usuário para um patamar que o desktop nunca terá.
• Foco. Quem já teve que adaptar um site para mobiles entende que informação demais prejudica. Se focar nas ações essenciais que o usuário executará ao acessar seu site com um dispositivo móvel é o básico.
• A atenção em áreas como Arquitetura de Informação, Usabilidade e Acessibilidade é aumentada. Em mobiles, decidir onde cada botão vai ser posicionado é tão essencial quanto a programação server-side ou um HTML bem feito.
• Te prepara para outros cenários. Fazer sites mobile é só o primeiro passo. Mas e os grandes formatos como SmartTVs ou outros dispositivos? Não vai demorar muito para acessarmos a internet de qualquer dispositivo sem bloqueios ou restrições.

O design

O design também precisa ser revisto. Na verdade, o design mais do que nunca conta com as respostas e os conceitos de AI, Acessibilidade e Usabilidade. Se antes fazíamos festa porque a resolução dos desktops aumentaram e agora temos mais espaço para trabalharmos, nos mobiles o cenário é completamente o contrário.

Arquitetura de Informação

As informações que você previa no desktop precisam ser remanejadas, diminuidas e retrabalhadas para que se adaptem nas telas menores. A maioria dos celulares tem algo em torno de 320×480 pixels. Se não tomarmos cuidado, toda a informação pode se perder em uma tela tão pequena. No mundo mobile o simples é a palavra que manda.

Você pode perceber que alguns websites conseguiram resolver bem seus problemas de excesso de informação promovendo em seus websites mobiles apenas as ações realmente importantes e dando foco ao conteúdo que provavelmente o usuário irá consumir quando estiver utilizando um pequeno dispositivo.

Se você é usuário do Flickr, conhece aquele bando de opções que ele guarda em seu menu principal. São centenas de opções e ações que certamente não cabem em uma tela tão pequena.

Um estudo profundo certamente deve ser feito para que você saiba exatamente quais informações e ações serão mais úteis na versão mobile.

Mantendo informações importantes

Existem também outras formas de acomodar um grande número de informações sem que isso atrapalhe o usuário. Uma delas é criando menus dropdown ou separando uma tela que guarda as informações que serão menos utilizadas mas que são igualmente importantes para a utilização do site/sistema. Veja abaixo dois bons exemplos vindo dos sites Gmail e ESPN.

Onde os usuários utilizam seus mobiles e visitam seu site? Bem, de todo lugar. Algumas pessoas acham que usuários utilizam apenas quando estão em filas, ônibus, parados no trânsito etc. Mas algumas pesquisas mostram que 84% dos usuários usam seus dispositivos em casa. Isso mesmo… em casa. Veja bem: quando as pessoas estão em casa, elas preferem utilizar seus smartphones em vez do notebook/desktop!
62% utilizam enquanto assistem a TV. Até a TV perde atenção quando briga com os mobiles.

Não existem mais desculpas. Os browsers para mobiles estão tão modernos quanto os dos desktops. O hardware está muito mais poderoso, mais do que poderíamos imaginar a dois anos atrás. Existe um número gigante de usuários utilizando estes dispositivos, isso os torna potenciais visitantes e claro, compradores. Porque desperdiçar esta oportunidade?

Você pode ler mais sobre este assunto neste livro esperto escrito por LUKE WROBLEWSKI. Aproveite!

Posts Relacionados

• Sobre Internet Explorer para Mobile – Breve impressão
• Mobilidade na cabeça
• Sites para Dispositivos Móveis – Breve introdução
• Browsers dos Dispositivos Móveis
• Responsive Web Design – focando a coisa certa

Quando não restringimos os cenários a aparelhos temos um horizonte muito maior e mais frutífero. Entenda que a informação publicada na web pode e é totalmente reutilizada a qualquer momento. O Google faz isso com seu robô todos os dias, a todo momento. O robô do Google ou o de qualquer outro sistema de busca é um meio de acesso. O leitor de tela do usuário deficiente visual também é um meio de acesso. O leitor de RSS utilizado pelo seu celular, por mais simples que seja, é um meio de acesso. Podemos dizer então que qualquer dispositivo que o usuário utilize para consumir informação na web é um meio de acesso. Esse “qualquer coisa” pode ser um robô ou um sistema manipulado pelos visitantes de seu site.

O que é Responsive Web Design

Responsive Web Design é acima de tudo um conceito. Nós nos responsabilizamos a apresentar a informação de forma acessível e confortável para diversos meios de acesso. Muitos websites restringem o conceito a aparelhos com telas de diversos tamanhos, mas o conceito é muito mais abrangente.

Mesmo assim irei restringir os primeiros exemplos a dispositivos que tenham telas e que estão mais presentes atualmente. Não irei me estender muito a meios de acesso como leitores de tela, robôs de busca ou outros dispositivos.

O problema de entregar conteúdo em diversos formatos

Para fazer um website que seja acessível por qualquer dispositivo você geralmente tenta detectar o aparelho que o usuário está utilizando. Se for um desktop ou um notebook, você redireciona o acesso para um código CSS que formata seu site para o design mais confortável em grandes monitores. Se você detectar que o usuário está utilizando um dispositivo móvel, você o redireciona para uma versão que formatará o site para um formato compatível para este dispositivo.
Essa ideia é simples e foi efetiva por algum tempo quando utilizávamos Media Types do CSS.
Com o advento dos novos aparelhos como tablets, smartphones e até mesmo as televisões LED e LCD, essa técnica se tornou muito obsoleta.
Entenda porque: os media types detectavam algumas características dos meios de acesso, por exemplo o valor handheld filtrava aparelhos com telas de tamanho pequeno e conexão com a internet limitada. O valor screen, filtrava aparelhos com telas coloridas, normalmente terminais com monitores.
Entende porque estas características estão obsoletas ou se confundem com a quantidade de aparelhos existentes? Hoje 100% dos smartphones suportam resoluções de tela maiores e com acesso a um número ilimitado de cores que os monitores antigos. Quase nenhum celular tem telas pequenas e conexão limitada com a internet. Logo, estes parâmetros ficaram totalmente inúteis.

Para termos uma ideia melhor, a tela do iPhone e do iPad suportam resoluções muito maiores do que os monitores antigos. Lembro que utilizava em meu antigo monitor de 13” resolução de 800×600. A resolução do iPad é de 1024×768 com 132ppp. Meu monitor de 13” até chegava nessa resolução, mas daquele jeito porco. Até o iPhone tem uma resolução melhor: 960×640.

Agora entenda a regra primordial, que deve guiar todo o planejamento de design para diversos dispositivos: O que importa é a resolução e não o tamanho da tela.

Sabendo dessa regra, entenda que você não faz um layout para um determinado tipo de dispositivo, mas para aparelhos que tem uma determinada resolução. Um exemplo clássico é o site do Itaú. Eles tem uma equipe sensacional e muito pioneira. Eu consigo acessar perfeitamente o bankline por disversos dispositivos. Mas há um problema. Troquei meu smartphone Android recentemente por um Windows Phone. Eles tem as mesmas características. Mas quando entrei no bankline do Itaú, curiosamente fui redirecionado para a versão WAP do bankline. Com um bom desenvolvedor que sou, não me conformei e peguei emprestado o iPhone da minha mulher, copiei o endereço que o site redireciona os usuários do iPhone e o utilizei no meu Windows Phone. Voilá! Mesma interface, mesma usabilidade, mesmo design.
Eles detectaram o tipo de aparelho e não as características do aparelho.

Para nos ajudar a detectar as características dos aparelhos, bem como a resolução, utilizamos as Media Queries em detrimento aos Media Types.

Media Queries

Media Queries é a utilização de Media Types com uma ou mais expressões envolvendo características de uma media para definir formatações para diversos dispositivos.

Em Media Types há um valor chamado SCREEN, como já vimos anteriormente. Este valor é utilizado quando queremos direcionar uma determinada formatação para aparelhos que tem telas coloridas. Bom, telas coloridas é algo muito genérico, qualquer coisa hoje em dia tem telas coloridas. É aí que as Media Queries nos ajudam: além de identificar aparelhos com telas coloridas, você consegue definir um range de tamanho de tela para que aquele CSS possa ser ativado.
Veja um código de exemplo abaixo:

Você já deve ter percebido o porque do QUERIES no nome. Você cria queries no valor do atributo media o elemento LINK.
Neste exemplo, estamos capturando terminais com montiores e coloridos. Você pode capturar outros terminais com alguma saída visual, mas pode ser que o usuário esteja utilizando algum aparelho com saída de monitor monocromático, por isso temos que especificar o COLOR no valor.

Outro exemplo, onde restringimos a largura máxima da tela:

Aqui estamos direcionando o código CSS para aparelhos que tenham uma largura máxima de tela de 480px. Ou seja, qualquer aparelho que tenha essa largura de tela, deverá utilizar o código CSS que está no arquivo especificado.

É aqui que a diversão começa: com essas queries você define uma série de ranges de larguras de tela, separando uma versão de CSS para cada grupo de aparelhos que se enquadradam nestas descrições. Você faz um formato para grandes telas, outro para telas de tablets e outro para telas de smartphones.

E lá vem uma pergunta para você: as telas dos Tablets hoje em dia utilizando uma resolução de 1024×768. Muitos usuários utilizam esta mesma resolução de tela em seus computadores, com monitores maiores que as tablets. Como faz?

Entenda: se você criou uma versão adaptável, confortável para resoluções de 1024×768, pensando em tablets, será que essa mesma versão não seria confortável para monitores com essa resolução? E vice-versa. Se você definiu que a versão desktop será carregada a partir de uma largura de tela de 1000px. As tablets também verão essa versão. Lembre-se o que realmente importa é o tamanho da tela dos aparelhos, não o aparelho em si. Quando você especifica o aparelho, você limita os usuários, quando você específica a resolução, você amplia o número possíveis de visitantes.

Além do mais, vendo estatísticas por aí, a resolução de 1024×768 está decaindo muito rápido. Com as novas TVs e novos monitores, as resoluções de tela tem aumentado bastante, levando todos a um novo patamar.
O que nos leva ao próximo assunto.

Outras decisões de interface

O primeiro passo foi identificar os aparelhos e usuários que utilizam determinadas resoluções para conseguirmos entregar um CSS específico.
O segundo passo é fazer com que o layout seja amigável. Para isso você precisa entender os dilemas dos seus layouts e resolvê-los sem que o design mude da água para o vinho, mantendo as mesmas características e histórias de uso. Para tanto você precisa estudar e aplicar algumas premissas em seu website. Vou mostrar alguns pontos aqui, mas cada projeto terá uma abordagem diferente.

Layout fluido

Layouts fluidos estão sendo utilizados desde os primórdios, mesmo assim de uma forma muito restrita porque dependendo do tamanho do site são bem difíceis de planejar. Veja o site da Amazon, ele ocupa todo o espaço do navegador e seu tamanho é adequado até uma determinada largura de tela.

O A List a Part tem um exemplo ótimo, por isso não vou fazê-lo perder tempo vendo outro exemplo. Veja este layout com a tela maximizada e vá diminuindo a janela do seu browser e veja os efeitos.

Perceba ele se encaixa em qualquer tipo de tela. Dessa forma você entregou uma boa experiência de design para todos os públicos. Este é um ótimo exemplo para entender exatamente o que é Responsive Web Design.
Quer outro ótimo exemplo? Neste caso o designer mostra uma mensagem para o usuário, o alertando de que o site é melhor visualizado em grandes resoluções.

Adaptando menus

Menus de websites são indispensáveis. É por lá que o usuário descobre todos os segredos do seu website, por onde ele se apaixona ou se perde. O menu é um dos principais elementos do seu website. É muito comum que usemos menus na horizontal. E como você sabe, menus na horizontal não são quase impossíveis em telas pequenas como as dos smarphones. Ainda mais se você tiver uma grande quantidade de opções. Logo, você precisa adaptar se menu para que ele continue usável e ao mesmo tempo não ocupe tanto espaço na tela.

Há diversos caminhos que você pode tomar: você pode transformar o menu em um selectbox (ou combobox, como preferir), sumir com alguns ítens que podem não ser interessantes para usuários de mobiles ou reformatar seu design para que ele caixa de forma funcional em telas pequenas.

Veja alguns exemplos abaixo. Entre no site e diminua a janela do browser para ver os efeitos. Se preferir ver na vida real, visite o site pelo seu smartphone:

• http://www.highwayhurricanes.com/
• http://www.citychoir.org.uk/
• http://leica-explorer.com/

Diminuindo ou trocando imagens

Não se preocupe se seu website trabalha utilizando grandes imagens, você trocar ou diminuir as imagens para que caibam em telas menores. Veja os exemplos abaixo:

• http://www.ciscolondon2012.com/
• http://www.cujo.jp/
• http://spartanrobotics.org/
• http://1pictureaday.com/

Media Queries – A Collection of sites using media queries

Todos os exemplos de website que mostrei acima, retirei deste website. A ideia é genial!
O http://mediaqueri.es/ tem uma coleção impressionante de websites que utilizam de forma responsável as Media Queries. Veja os exemplos e entenda como você pode fazer um website adaptável para diversos cenários de uso.

Cada meio de acesso tem sua característica

Conversamos bastante sobre o problema das resoluções e larguras de tela. Mas no começo deste post eu disse que o Responsive Web Design pode ir muito além das telas e Media Queries. Há usuários podem visitar seu site e não utilizar uma tela, tablet ou smartphone. Em vez de ler as informações ele pode ouvi-las, como é o caso dos usuários de leitores de tela.

CSS Aural

Quero que você abra sua mente e entenda que mesmo você não tenho deficiencia visual, você pode ser um grande candidato a utilizar leitores de tela. Enganam-se aqueles que acham que programas que leem a tela só podem ser usados por pessoas com problemas de visão. E se você estiver dirigindo ou em qualquer outra situação em que não pode ficar o tempo inteiro com o celular na mão, mas mesmo assim quer ler um determinado artigo, site etc, como você faz? Nunca pensou em ouvir o artigo? Pois é.

Eu sei que os sistemas de leitura de tela hoje em dia precisam de uma repaginada total. Mas empresas como Apple e Microsoft já estão fazendo isso para que seus sistemas mobiles e para desktops tenham a habilidade de ler bem as telas dos dispositivos. Isso é impressionante.

Se a informação vai ser consumida dessa forma ela precisa ser formatada também. Isso mesmo, formataremos o áudio! Como? Com CSS Aural.

O CSS Aural praticamente controla como o audio do leitor de tela irá se comportar. Você pode controlar volume, tipo da voz, qual caixa a voz sairá etc.
Imagine que você tenha um artigo sobre uma entrevista, onde há o entrevistador e o entrevistado. Você pode: especificar que a voz do entrevistador sairá na caixa da esquerda e a do entrevistado na caixa de som da direita. Que a voz do entrevistador será masculina e que voz do entrevistador será feminina.
Sensacional, não é?

Especificação Touchscreen

Já falei sobre a Específicação Touchscreen, abaixo segue um resumo, mas sugiro que você leia o artigo completo.

Estamos acostumados com a experiência de interação com a ajuda do mouse. Isso foi desde os primórdios e provavelmente ainda será por bastante tempo. Nós desenhamos interfaces para ações baseadas no mouse ou qualquer aparelho que controle a setinha da sua tela. Criar interfaces touch é algo relativamente novo. Nós trouxemos ideias da interação com mouse para os dispositivos touch, mas grande parte das interações precisaram ser reinventadas porque o modo, o ato, a forma de interagir com a informação é diferente. Na interface touch você não “coloca o mouse” em cima do elemento. Você não utiliza teclas de atalho para executar ações. Normalmente as ações importantes estão expostas na interface, facilitando o acesso rápido. Isso é muito importante porque nos ensina criar interfaces mais intuitivas, com a curva de aprendizado menor.

Há também o outro lado da moeda, onde detalhes das interfaces touch não podem ser portadas para interfaces baseadas em mouse. Lembre agora na forma de como você gira uma imagem em um dispositivo touch e como você gira essa mesma imagem utilizando um mouse. A interface muda, o seu comportamento muda.

Sabendo dessas limitações você deve entender que não podemos simplesmente portar o visual de um determinado site para um dispositivo touch. Você pode dizer que “hoje fazemos isso e até agora está funcionando muito bem”. Mas pense melhor… a grande maioria dos sites que você visita hoje no iPad ou qualquer outro tablet, por exemplo, são sites onde a sua interação é limitada. O que você faz em um site hoje em dia? Clica nos links e lê. Salvo às vezes quando você visita um site mais “animadinho” com mais ações para entreter o usuário. Mas e se você faz um site onde é preciso rotacionar uma imagem ou fazer um ZOOM? Você precisará manter as mesmas ações nos dois cenários. E como antigamente, para manter o cenário das interfaces touch você precisa da ajuda de muito script.

Concluindo

Responsive Web Design é um assunto muito extenso mas muito interessante. Nos faz pensar no futuro de forma diferente. Até 5 anos atrás não tínhamos preocupações com outro dispositivo a não ser um ou outro smartphone e os desktops. Hoje temos diversos aparelhos, com diversas limitações de tela, tamanhos, comportamentos… E isso não vai parar por aí. Todos os dias aparecerão mais e mais aparelhos e dispositivos que ajudarão os usuários a terem acesso a qualquer informação. É importante que nós possibilitemos que essas informações sejam entregues da melhor maneira possível.

Algumas referências que você pode querer dar uma olhada:

• Responsive Web Design
• Guidelines for Responsive Web Design
• Designing for a Responsive Web with Heuristic Methods
• The Big Web Show sobre Responsive Web Design

Posts Relacionados

• Mobile First – A arte de pensar com foco
• Especificação para touch screens
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão
• Responsive Web Design – focando a coisa certa

Hoje, as interfaces touch estão maduras e estáveis, que chegam a inspirar as interfaces dos sistemas desktops. Vide o que aconteceu com o OS X Lion e com o Windows 8. As principais ideias foram retiradas de suas respectivas interfaces mobiles: o Windows do Windows Phone e o Lion do OS X para iPad.
As interfaces mobiles e as interfaces desktop ficarão mais homogêneas com o passar do tempo, se assemelhando cada vez mais, contudo, as interações são totalmente diferentes. As interfaces criadas para cada dispositivo nos ajudam a distinguir os ambientes e também a forma com que o usuário interage.

Estamos acostumados com a experiência de interação com a ajuda do mouse. Isso foi desde os primórdios e provavelmente ainda será por bastante tempo. Nós desenhamos interfaces para ações baseadas no mouse ou qualquer aparelho que controle a setinha da sua tela. Criar interfaces touch é algo relativamente novo. Nós trouxemos ideias da interação com mouse para os dispositivos touch, mas grande parte das interações precisaram ser reinventadas porque o modo, o ato, a forma de interagir com a informação é diferente. Na interface touch você não “coloca o mouse” em cima do elemento. Você não utiliza teclas de atalho para executar ações. Normalmente as ações importantes estão expostas na interface, facilitando o acesso rápido. Isso é muito importante porque nos ensina criar interfaces mais intuitivas, com a curva de aprendizado menor.
Há também o outro lado da moeda, onde detalhes das interfaces touch não podem ser portadas para interfaces baseadas em mouse. Lembre agora na forma de como você gira uma imagem em um dispositivo touch e como você gira essa mesma imagem utilizando um mouse. A interface muda, o seu comportamento muda.

Sabendo dessas limitações você deve entender que não podemos simplesmente portar o visual de um determinado site para um dispositivo touch. Você pode dizer que “hoje fazemos isso e até agora está funcionando muito bem”. Mas pense melhor… a grande maioria dos sites que você visita hoje no iPad ou qualquer outro tablet, por exemplo, são sites onde a sua interação é limitada. O que você faz em um site hoje em dia? Clica nos links e lê. Salvo às vezes quando você visita um site mais “animadinho” com mais ações para entreter o usuário. Mas e se você faz um site onde é preciso rotacionar uma imagem ou fazer um ZOOM? Você precisará manter as mesmas ações nos dois cenários. E como antigamente, para manter o cenário das interfaces touch você precisa da ajuda de muito script.

Ambas as versões tem suas limitações e um legado de compatibilidade com seu sistema base que precisam manter.

A ideia de criar uma especificação destinada para as interfaces touch é que tenhamos controle sobre as ações do usuário, da mesma forma que temos nos desktops. Para isso eles estão mapeando uma série de eventos que específicos das interfaces touch. Assim podemos definir ações baseadas nessas interfaces. Estão participando da escrita desta especificação Doug Schepers do W3C, Sangwhan Moon da Opera Software ASA e Matt Brubeck da Mozilla.

Se você parar para ler a específicação, vai entender que poderemos controlar quando o usuário interage encostando o dedo na tela, movendo o dedo e também ao retirá-lo. Você poderá controlar a área de toque. Se o elemento for pequeno, por exemplo, você poderá aumentar essa área de toque para que o usuário não tenha dificuldades. Poderá acionar eventos no momento que o usuário rotacionar os elementos. Se você está fazendo um WebApp poderá acionar um menu contextual personalizado quando o usuário fizer um “tap” com dois dedos. O usuário vira basicamente um proctologista.

A especificação ainda é um rascunho mas já está mostrando que as possibilidades são imensas. Eu vivo me perguntando até onde irá o HTML, CSS e Javascript com essas novas mudanças. Será que vão continuar fáceis como são hoje ou tudo vai ficar complicado? Será que serão eles que farão todo o trabalho ou novas linguagens serão criadas para lidar com essas novidades? Who knows? Eu tenho um palpite, mas é assunto para outra hora.

Posts Relacionados

• Mobile First – A arte de pensar com foco
• Introdução ao Responsive Web Design
• Porque é a web que comanda
• Experiência cross-device
• Command & Conquer: Tiberium Alliances

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:

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

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:

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.

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

• Quem precisa de versão mobile?
• Experiência deve ter começo, meio e fim
• PDF – Browsers antigos: guerra contra o terror
• Seu lugar ao sol
• Command & Conquer: Tiberium Alliances

Hoje, temos os seguintes browsers e motores de renderização para se preocupar:

Webkit

Devices com Android instalado ou iPhones e iPod Touch (com Mobile Safari).

Opera Mobile e Opera Mini

O Opera é um dos browsers mais “perfeitos” que existem para mobiles. Ele tem um bom suporte aos Padrões e é quase tão atualizado como Mobile Safari.

Blackberry

O browser utilizado nos Blackberrys são muito bons. Bem melhores que o Internet Explorer, mas piores que o Opera ou Mobile Safari. Digo que eles estão no meio do caminho. Falta ainda suporte a metatags inteligentes, mas já conhecem um bocado de CSS.

Browsers S60 da Nokia

São baseados em Webkit também, como o browser do iPhone e do Android, mas geralmente a versão do webkit é antiga, o que atrapalha um pouco se você quiser fazer algumas coisas mais elaboradas, por exemplo, utilizar media queries ou metatags que nos ajudam a controlar o visual nos aparelhos, como a de Metatag de Viewport.

Internet Explorer Mobile

Esse sim é uma dor de cabeça. Ele não tem bom suporte a CSS e tem bus quando usamos media types. Sem contar que é bastante lerdo e não tem uma séries features que os outros browsers tem, como o Opera. Mesmo assim, há um grupo enorme de aparelhos que vem com Windows Mobile e consequentemente, os usuários mais desavisados utilizam o Internet Explorer Mobile como browser. Felizmente, há uma parte desse grupo que conhece o Opera.
Contudo, com o lançamento do Windows Phone 7 isso tende a mudar um pouco. O Windows Phone 7 utiliza um browser com características e suporte aos padrões referentes a alguma versão do Internet Explorer 7 e 8.

Para facilitar o desenvolvimento para mobiles, eu nivelo a produção desta forma. Por ordem de prioridade:

• Webkit
• Opera Mobile e Opera Mini
• Outros browsers comò do Blackberry, S60 e etc.

De longe o Webkit é hoje o melhor engine para browsers mobiles. Ele é rápido e suporta grande parte das especificações de HTML, CSS e Javascript. Além de estar presente em dispositivos como iPhone, Android e alguns smartphones da Nokia.

Mesmo assim, é preciso testar os sistemas nestes browsers. Você faz isso de duas formas: compra uma dezena de celulares diferentes uns dos outros e testa o produto em cada um deles. Ou por meio de emuladores. O problema de testar com emuladores é que nem todos tem versões para vários sistemas operacionais. O simulador de iPhone só tem para Mac. O de Android tem para Mac e para Windows. O de Blackberry e os da Nokia só tem para Windows. Dificulta bastante a produtividade, mesmo assim, é melhor que ter todos os aparelhos.

Para obter os simuladores, veja abaixo:

iPhone/iPod Touch

O mais fiel de todos os emuladores de mobiles que já vi. Tudo o que você vê na tela, é exatamente o que verá no aparelho. O problema é que só funciona no Mac. Os emuladores alternativos para windows ou outros sistemas não são fiéis. iPhone SDK.

Opera Mobile e Opera Mini

Fizeram uma atualização geral estes últimos tempos. A vantagem é que ele funciona on-line. Nada de fazer download. Emulador Opera.

Blackberry

Só funciona em Windows. A vantagem é que dá para escolher versões anteriores. Mesmo assim, sugiro que sempre nivele pela última versão. Emulador de Blackberry.

Browsers da Nokia

Também só para Windows. Mas costumam ser fiéis com o que vemos nos aparelhos. Nokia Browser Emulator.

Android

Funciona em Macs e Windows. Mas são complicados de usar. Nada que alguns minutos lendo tutoriais e artigos pela internet não resolvam. A grande vantagem é que você consegue customizar o aparelho onde você vai testar o website. Emulador Android.

Se você tem um aparelho com Android, Windows Mobile ou NokiaS60, aconselho também baixar o Skyfire. Um browser muito bom que apareceu para tentar dominar parte do mercado de browsers para mobiles. Ele ataca o mesmo mercado que o Opera está atuando. Tem um bom suporte a Padrões. Vale a pena conferir.

A grande graça de fazer sites para mobiles, é que a grande maioria dos dispositivos realmente confortáveis para acessar a web, e que são os dispositivos que a maioria dos usuários compram porque querem navegar, tem um bom suporte a Padrões Web. Ter conforto para navegar nestes aparelhos é ponto crucial, por isso os fabricantes de sistemas e browsers tentam sempre manter os browsers atualizados com os Padrões.

Posts Relacionados

• Especificação para touch screens
• Manipulando a metatag Viewport
• Bem vindo a Xangri-lá – Parte 2
• Bem vindo a Xangri-lá – Parte 1
• Sections: seções do HTML5 – Parte 1

Hoje, aparelhos como o iPhone, que tem um browser com um bom suporte a HTML 5 e CSS 3, possibilitam criar sistemas e aplicativos baseados em web, com características, designs e comportamentos idênticos aos de aplicações instaláveis nos aparelhos. E o melhor, podem ser utilizados de qualquer lugar, pela web. Outro ponto negativo é que desenvolver para iPhone/iPod Touch é um bocado burocrático. Você precisa ter o SDK que só funciona no OS X, e você precisa aprender Objective C para programar os Apps para Apple. Em contrapartida, para fazer um App baseado em Web, onde seus clientes acessarão o sistema diretamente pelo browser do aparelho, é preciso saber Javascript, HTML 5 e CSS 3. Se você já é desenvolvedor Web, você já sabe desenvolver para iPhone, iPod Touch, Android e qualquer outro dispositivo similar.

Se você gosta dos efeitos de transição dos aparelhos, você pode fazê-los sem problemas utilizando JQuery ou CSS 3. Há até um plugin de JQuery chamado JQTouch, que permite fazer efeitos idênticos ao do iPhone. Esse plugin foi pensado exatamente para funcionar em Mobile Safari e outros aparelhos com browsers avançados, como no Android.

Um caso sobre o que estamos falando é a aplicação do Itaú. Se você tem um iPhone, baixe o aplicativo pela AppStore. Ao abrir o aplicativo, perceba que o sistema não faz nada além de mostrar o site do Itaú. É muito mais interessante e barato ensinar o usuário a visitar o site em vez de procurar um aplicativo e instalar. Não é necessário nem divulgar um endereço mobile do site – esse aliás é outra discussão.

Obviamente, há exceções. A maioria dos jogos, se não todos, e alguns sistemas disponíveis funcionam melhor (ainda) se forem instalados no aparelho. Mas a grande maioria dos sistemas, principalmente aqueles que o usuário simplesmente insere ou verifca informações e dados, podem ser servidos diretamente pela web.

No caso do iPhone, os sistemas que utilizam recursos do aparelho, como por exemplo fazer o aparelho vibrar, bluetooth, bateria, GPS e etc, precisam ser instalados. Isso não se aplica a alguns mobiles da Nokia que são baseados na plataforma WRT.
A plataforma WRT permite que você desenvolva aplicativos utilizando Javascript, HTML e CSS. E por meio de Javascript, você pode ativar os recursos que ter utilizar no aparelho. Nesse caso, há uma vantagem em cima do iPhone: você não precisa aprender Objective C. Basta saber Javascript, CSS e HTML.

O cenário de hoje é interessante. Tudo o que o desenvolvedor sempre sonhou em utilizar de HTML 5 e CSS 3 pode ser aplicado no desenvolvimento para web mobile. Os browsers estão mais espertos e a cada dia trazem novidades interessantes para melhorar o desenvolvimento dos padrões e da web. Realmente, daqui pra frente, é um novo mundo que se forma. Um mundo tão ou mais complexo que o desenvolvimento web para desktops como conhecemos hoje. Pra mim, é mais apaixonante.

• Guidelines de User Experience da Apple.
• Forum Nokia – Web Runtime

Posts Relacionados

• Ah, o maravilhoso mundo real
• O que é Tableless?
• Entendendo quais APIs (realmente) fazem parte do HTML5
• Especificação para touch screens
• Bem vindo a Xangri-lá – Parte 2

Para fazer sites para os iPhones e Androids da vida, não há segredo, já que eles aceitam tudo e mais um pouco de CSS e HTML. Você consegue ter homogeneidade ao desenvolver. Mesmo assim, para ter certeza, seria interessante você testar o site em um aparelho. Por isso, há simuladores que emulam o ambiente dos aparelhos. É o caso do iPhone e do Android.

Para aprender mais sobre o simulador do Android, visite a página oficial sobre o emulador deles. Assim você aprende como ele funciona, as funções, instalação e etc. O simulador pode ser instalado em Windows, Mac ou Linux.

O simulador para iPhone é só para quem tem Mac. Infelizmente a Apple ainda não liberou o SDK para outros sistemas. Uma pena, porque não só de mac vive o homem, e a maioria dos devs utilizam Windows ou Linux. Mesmo assim, você pode baixá-lo e utilizá-lo para testar qualquer site ou arquivos locais.

O pessoal da Nokia também disponibiliza vários emuladores. Contudo, aconselho que você utilize apenas o browser de S60, que é o melhor deles hoje em dia. Os browsers dos S60 suportam Webkit, mesmo não sendo a versão mais atualizada, é possível fazer muita coisa interessante, entretanto, há haver alguns erros de compatibilidade por conta do engine desatualizado.

• Simulador de Android
• Simulador de iPhone
• Simulador para Nokia

Posts Relacionados

• Sobre Internet Explorer para Mobile – Breve impressão
• Mobilidade na cabeça
• Sites para Dispositivos Móveis – Breve introdução
• Browsers dos Dispositivos Móveis
• Sites para Dispositivos Móveis – MediaType

Um pouco de História

Por volta de 1997, os computadores da Apple traziam por padrão o Netscape. Naquele tempo o mercado de browsers não era tão acirrado como hoje e os concorrentes eram poucos. O Internet Explorer estava em sua versão 2/3. Mesmo assim, o Internet Explorer para Mac era também distribuído com o MacOS durante os 5 anos de acordo entre Apple e Microsoft. A Microsoft laçou 3 versões principais do seu navegador para o Mac, parando na versão 5 em março de 2000.

Em 2003, a Apple anunciou que eles estavam desenvolvendo seu próprio browser baseado no motor de renderização KHTML. A versão 1.0 foi lançado como browser padrão do MacOS por volta de Junho de 2003. O Internet Explorer ainda era distribuido no sistema, mas agora como um navegador alternativo, até Abril de 2005.

Motor de Renderização WebKit

O Safari utiliza um motor de renderização chamado WebKit. O WebKit tem dois motores de renderização: o WebCore, que é o motor de renderização baseado no KTHML do Konqueror. E o JavaScriptCore, baseado no motor de javascript KDE chamado KJS. Esses motores estão sob Licensa GNU.

A Apple, ao fazer o Safari fez muitas atualizações e modificações no motor KHTML, deixando-o mais maduro e robusto. Essas modificações foram devolvidas para a comunidade e incorporadas no Konqueror.

MobileSafari e Safari para Desktop

A idéia é que o usuário tenha uma experiência muito próxima a experiência que ele tem no desktop. Por isso o Safari para iPhone (MobileSafari) foi feito sob o mesmo motor de renderização WebKit do Safari para Windows e Mac. Diferenças: 1) Se o site não foi feito para iPhone, ele renderiza a página da mesma forma como renderiza em um Safari para desktop, mas miniaturizada. 2) A interação do usuário.

Padrões Suportados

Para que a renderização do MobileSafari seja fiel ao Safari para desktop, ele tem grande suporte aos Padrões Web.

• HMTML 4.01
• HTML 5
• XHTML 1.0
• CSS 2.1
• Parte do CSS 3
• Javascript 1.4
• Ajax
• DOM

É interessante notar que temos uma certa liberdade de desenvolvimento web no iPhone. Há facilidades como cantos arredondados que não podemos contar no desenvolvimento focado para desktops. Isso tráz vantagens pra você, desenvolvedor, porque facilitará seu trabalho, e para o usuário porque ele terá uma experiência mais rica.

Limites dos recursos

Embora o iPhone suporte as tecnologias mais atuais de desenvolvimento web, não podemos esquecer de que ele é um dispositivo móvel, com capacidade de processamento muito menor que a de um desktop. Por isso, há algumas limitações de recursos que devemos nos atentar.

Para códigos:

• 10Mb para arquivos Javascripts e XML
• O tempo de execução de um Javascript é limitado a 10 segundos. Se passar de 10 segundos, o Safari pára a execução em algum lugar aleatório do seu código.
• Javascripts alocados limitados a 10Mb
• Máximo de 8 documentos abertos de uma vez

Para imagens:

• Limite máximo do tamanho de GIF, PNG e TIFF são 2 Megapixels
• A decodificação máxima dos tamanhos de JPGs são 32 Megapixels. Utilizando SubSampling
• O tamanho máximo de GIFs animados deve ser menor que 2MB. Para arquivos animados maiores, só é mostrado o primeiro frame.

Verifique sempre o tamanho final de sua página. Normalmente o sites com 30Mb para menos funcionam muito bem no iPhone.

Posts Relacionados

• Sobre Internet Explorer para Mobile – Breve impressão
• Sites para Dispositivos Móveis – MediaType
• Navegação em mobiles
• Mobilidade na cabeça
• Breve introdução: XHTML Mobile Profile

O ano era 1997. Eu e e todo mundo que eu conhecia usávamos Netscape Navigator. Foi o ano em que, pela primeira vez, fiz um site sozinho. Tudo, atendi o cliente, preparei textos, fotos, fiz o layout, se é que se pode chamar aquilo de layout, criei uma conta no Geocities e publiquei. Em seguida entrei no Yahoo! e cadastrei o site, para que aparecesse nas buscas.

Depois de alguns dias recebi um e-mail do Yahoo! dizendo que o site não poderia ser publicado no diretório porque não funcionava no Internet Explorer. Sim, cavalheiros, era política do Yahoo! só publicar em seu diretório sites que funcionassem bem nos dois navegadores. Como eu resolvi? Criei duas versões do site, uma para cada navegador, e um Javascript que selecionava a versão de acordo com o navegador do usuário.

Mas eu não fiquei satisfeito. Fazer duas versões do site dava um bocado de trabalho. Manter as duas versões dava mais trabalho ainda. E se houvesse mais um navegador relevante? Eu não queria ter três ou quatro versões de cada site que desenvolvesse. Parece que muito mais gente tinha o mesmo sentimento que eu. Gente muito mais talentosa e importante do que eu. Gente como o pessoal que criou o projeto Web Standards.

Você não imagina como eu fiquei feliz quando, no final do século passado, ao estudar os Padrões Web, percebi que não precisava de duas versões de cada site. Eu hoje uso Opera, Firefox e Konqueror. E esporadicamente, Flock, Safari, Epiphany e Galeon. E ainda preciso testar meus sites no Internet Explorer. Esta é uma das grandes vantagens dos padrões, seu site, uma única versão, funcionando em todo lugar.

Bom, talvez eu me preocupe com navegadores demais. Quem sabe é alguma paranóia minha. Talvez para você seja importante apenas que o site funcione no IE e no Firefox. Mas geralmente não dá nenhum trabalho fazê-lo funcionar nesses navegadores todos. Agora, dê uma olhada no mundo da mobilidade. Você vai construir uma versão para cada navegador? Que tal se simplesmente não construísse versão nenhuma?

Ora, os padrões web surgiram justamente para isso, para que seu site, a única versão, funcione em qualquer lugar. Naturalmente, há sites e aplicações online, por exemplo aquelas cuja experiência de uso depende fortemente de Ajax, que realmente merecem uma versão em HTML simples, acessível via dispositivos móveis e outros dispositivos e cenários de uso. Mas a maioria, a esmagadora maioria dos sites não precisa de uma versão mobile. Basta que o site seja bem feito, vai funcionar no mobile.

Existe porém um mito sendo difundido por aí de que as pessoas precisam de uma versão mobile de seus sites. Há uma febre de versão mobile por aí! Então, vamos deixar claro quais são as opções que temos em relação à acessibilidade de um site em dispositivos móveis:

1. Ter um site que simplesmente funcione: um site bem feito, nos padrões web, vai funcionar bem no celular. É a estratégia mais simples, mais barata, e os resultados são fantásticos!
2. Ter um CSS para dispositivos móveis: essa é a melhor estratégia. Você continua tendo uma única versão do site para manter. Mas oferece um layout trabalhado especialmente para dispositivos móveis que suportem bem CSS. Ou seja, dá só um pouquinho de trabalho em relação à primeira estratégia, oferece os mesmos resultados para navegadores sem CSS, e dão um conforto a mais para usuários de bons navegadores mobile.
3. Ter uma versão do site específica para mobile: vai te dar um trabalho desgraçado. Mas, ás vezes, simplesmente não tem jeito. É o caso de aplicações como o Twitter e o Google Reader. Aplicações Ajax, sites que dependem de um plugin específico ou aqueles cuja quantidade de conteúdo torna o uso muito desconfortável no mobile são potenciais candidatos a uma segunda versão. Uma abordagem semelhante é aquela que oferece uma versão “HTML simples”, que vai funcionar no mobile, no leitor de telas e etc.
4. Não se importar: é a estratégia de boa parte dos sites hoje. Não é irônico perceber que sites de operadoras de telefonia móvel não funcionam em seus próprios celulares?

Se você não tiver nenhum motivo muito bom para fazer diferente, fique num dos dois primeiros níveis. Você vai ter muito menos trabalho, e todo mundo vai poder acessar seu site. Da próxima vez que pensar em acessibilidade para dispositivos móveis, lembre-se: muito provavelmente você não precisa de uma versão mobile.

Os mesmos quatro níveis podem ser aplicados a praticamente qualquer cenário de uso. Por exemplo, impressão ou leitores de tela. Você pode fazer um site nos padrões e isso vai funcionar de maneira razoável. Pode escrever CSS ou pequenas adições em seu HTML para melhorar a experiência nesses cenários de uso. Pode, se não tiver outro jeito mesmo, fazer a indesejável segunda versão. Ou pode ignorar seus usuários.

Posts Relacionados

• Manipulando a metatag Viewport
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão
• Mobilidade na cabeça
• Breve introdução: XHTML Mobile Profile