Cutting Edge

Desenvolvimento de site para celular: marcação

Dino Esposito

 

Dino EspositoÀ medida que mais e mais dispositivos são utilizados para navegar na Web, ter um site otimizado para celular está se tornando um fator crítico para as empresas. Vamos encarar os fatos: mesmo com os mais modernos smartphones, navegar em um site para celular é bastante problemático. É preciso aplicar as funções de panorâmica e zoom para compreender o conteúdo e seguir links. Factível com certeza, mas não uma experiência fantástica para o usuário.

Uso meu smartphone para navegar em sites para desktop e, com frequência, prefiro ver a versão completa em vez da versão para celular, quando disponível. Faço isso por um motivo principal: os sites para celular não são frequentemente tão bem projetados como os sites para desktop. Como usuário frequente de um site, você desenvolve certas expectativas. Você espera encontrá-las todas atendidas pelo site independentemente do meio usado para alcançá-lo. Se chegar ao site com um dispositivo móvel, idealmente você espera o mesmo nível de serviço, mas direcionado ao seu status atual, o de um usuário móvel, possivelmente em trânsito, possivelmente com pressa e usando uma conexão ruim.

Esse é precisamente o desafio que arquitetos e desenvolvedores de um site para celular enfrentam. O que é mais problemático com um site para celular não é necessariamente a implementação de funcionalidades. Geralmente, um site para celular tem menos funções e ações por página que um site para desktop, e menos linhas de código significam menos problemas. No entanto, para oferecer uma melhor experiência de usuário, as funcionalidades normalmente solicitadas são requeridas ainda com mais urgência do que em um site para desktop. Assegurar uma grande experiência de usuário em dispositivos móveis pode ser desafiador e, com frequência, uma equipe tem de recorrer a codificações e soluções de design extremamente inteligentes.

Além disso, os sites para celular podem precisar servir a uma ampla variedade de dispositivos diferentes. Se até alguns anos atrás você teve medo de lidar com diferentes navegadores de desktop, pense no universo da mobilidade, onde os diferentes perfis de dispositivos com os quais pode estar lidando estão na casa de milhares. (No entanto, isso não significa que você deva planejar milhares de versões diferentes de página. Apenas reduza esses milhares de perfis de dispositivos para algumas classes de dispositivos que você manipula de forma diferente.

Este artigo é o primeiro de uma série em que tentarei abordar o desenvolvimento de site para celular utilizando uma perspectiva que não está focalizada principalmente em tecnologia. Com muita frequência penso que o desenvolvimento de site para celular está associado a estruturas específicas e suas soluções, sem gastar muito tempo pensando em casos de uso e na reestruturação do conteúdo. Neste artigo começarei do básico: a marcação para celular.

Por padrão, a maioria dos navegadores para dispositivos móveis renderizam páginas em visores muito maiores que os tamanhos de tela de dispositivo reais. A largura do visor real varia com o navegador, mas é sempre próxima de 1.000 pixels. Por exemplo, sabemos que é 980 pixels no Safari para iPhone e Internet Explorer 9, e 800 pixels no Android WebKit. Como desenvolvedor para dispositivos móveis, sua primeira tarefa deve ser entender a função e a origem do visor. A Figura 1 mostra como navegadores para dispositivos móveis usam o visor.

How Mobile Browsers Use the Viewport
Figura 1 Como navegadores para dispositivos móveis usam o visor

O visor é uma área de largura fixa onde o navegador renderiza qualquer conteúdo. O tamanho do visor não está necessariamente relacionado com o tamanho da tela física. Isso não é muito importante em um navegador para desktop, mas torna-se um problema nas telas significativamente menores de dispositivos móveis. Os navegadores tendem a renderizar páginas em qualquer que seja seu tamanho de visor interno. No entanto, quando se trata de exibição, eles reduzem o visor para que todo o conteúdo caiba na tamanho de tela real.

O resultado é que, como usuário, você precisa rolar horizontalmente e verticalmente para chegar ao conteúdo ou precisa ampliar para tornar o conteúdo legível e, mais importante, permitir que siga links. Um excelente recurso para aprender mais sobre a implementação interna de visores em navegadores encontra-se em bit.ly/bZYlKb.

Visor e marcação

No início do desenvolvimento do site para celular, a marcação usada não era igual à dos sites para desktop. Com o passar dos anos, mudamos da linguagem WML para compact HTML (CHTML) e para extensible HTML (XHTML) para celular. Em todos esses casos, um tipo MIME distinto foi apresentado ao navegador. Baseado nisso, o navegador poderia descobrir que tipo de conteúdo iria receber e renderizá-lo de acordo. Com o advento do iPhone ficou claro que os recursos dos dispositivos móveis poderiam ser comparados aos dos laptops, pelo menos na renderização de páginas da Web. Mas apresentar a mesma marcação para navegadores de dispositivos móveis e desktops levantou o problema de tamanhos de telas diferentes e forçou os usuários de celulares a reduzir e ampliar o conteúdo conforme fosse apropriado.

Se o mesmo tipo MIME (texto/html) for usado para solicitações de desktop e celular, o navegador não pode mais usar o tipo MIME para descobrir se pretende que o conteúdo seja exibido em um desktop ou em um visor do tamanho de celular. Essa é a razão por que a Apple Inc. introduziu a marca META viewport há alguns anos. Agora a marca META viewport é um padrão de fato, e qualquer página com a intenção de ser uma página para dispositivo móvel deve tê-la definida. Aqui está como normalmente é usada a marca viewport:

    <meta name="viewport" content="width=device-width" />

O atributo content da marca META é definido como uma expressão onde algumas propriedades podem ser definidas como valores ad hoc. A mais importante dessas propriedades é width. Os navegadores usam a propriedade width para definir dinamicamente o tamanho de seus visores. É possível definir a propriedade width como um número específico de pixels ou como uma expressão especial, como no exemplo anterior. Em particular, o valor device-width indica a largura da tela em pixels. Observe que nesse contexto um pixel é usado como um pixel independente do dispositivo ou um pixel CSS. Em dispositivos com uma alta densidade de pixels o navegador é forçado a redimensionar, e poderá acontecer de uma largura de 100 pixels cobrir uns 150 ou até mesmo 200 pixels físicos. A Figura 2 relaciona as propriedades suportadas em uma expressão viewport. 

Figura 2 Propriedades em uma expressão viewport

Propriedade Descrição
width Indica a largura desejada do visor em pixels independentes do dispositivo. Pode ser um número explícito (por exemplo, 240) ou, melhor ainda, um valor relativo como device-width.
height Indica a altura do visor desejada em pixels independentes do dispositivo. Pode ser um número explícito (por exemplo, 320) ou, melhor ainda, um valor relativo como device-height.
initial-scale Indica o nível de zoom desejado quando a página é inicialmente carregada. Um valor de 1 indica que a página deve ser renderizada com seu tamanho natural, totalmente sem zoom. Um valor de 2 dobrará o tamanho da página e assim por diante. Valores decimais também podem ser usados, como “1.0.”
minimum-scale Indica o nível mínimo de zoom permitido para a página. Um valor de 1 indica que o usuário não pode aplicar o zoom para reduzir a página mais do que seu tamanho natural.
maximum-scale Indica o nível máximo de zoom permitido para a página. O valor máximo é 10.0.
user-scalable Uma propriedade yes/no que indica se o usuário tem permissão de aplicar zoom à página.

Alguns navegadores podem ter propriedades extras. Em particular, os navegadores Android também entendem a propriedade target-densitydpi por meio da qual os desenvolvedores comunicam a resolução de tela desejada para a página. Isso pode ajudar os navegadores Android a otimizar o dimensionamento de recursos baseados em pixel como imagens. A propriedade target-densitydpi pode ser definida como um número específico ou como um valor especial como device-dpi.

Aqui está uma maneira mais específica de definir a marca META viewport:

    <meta name="viewport"
      content="width=device-width, user-scalable=no, initial-scale=1"/>

A propriedade height não é usada com frequência. Normalmente, ela é usada se você tiver elementos que devem ser colocados na parte inferior da tela ou em uma posição dependente da altura do visor. Finalmente, observe que definir user-scalable como “no” desabilitará o aperto e zoom na página.

A marca META viewport é bastante comum atualmente, mas no passado outras marcas META como HandheldFriendly e MobileOptimized foram usadas por alguns navegadores com o mesmo objetivo:

    <meta name="HandheldFriendly" content="true" /> 
    <meta name="MobileOptimized" content="320" />

A World Wide Web Consortium (W3C) está elaborando um documento para padronizar o elemento viewport. É possível ler o esboço atual em bit.ly/AavTG5.

HTML e XHTML Mobile Profile

O objetivo final da viewport e de outras marcas META é indicar o tamanho do visor no qual o desenvolvedor quer o conteúdo renderizado. Marcas META são usadas se você apresenta marcação HTML simples para navegadores de dispositivos móveis. Se, por alguma razão, estiver OK para você apresentar marcação para dispositivo móvel, não serão necessárias marcações META, mas apenas um documento com um DOCTYPE XHTML Mobile Profile (MP): 

    <!DOCTYPE html PUBLIC
      "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
      "http://www.openmobilealliance.org/tech/DTD/xhtmlmobile12.dtd">

O tipo MIME para XHTML MP é “application/vnd.wap.xhtml+xml.” Comparado à expressividade do HTML simples, o XHTML MP é uma coisa do passado porque tem limitações na manipulação de DOM (Document Object Model) e em áreas importantes como suporte a CSS e JavaScript.

O padrão atual que funciona para a maioria dos dispositivos atuais é usar HTML com a marca viewport. No entanto, pode acontecer de seu site estar aberto para um conjunto de dispositivos muito grande, incluindo dispositivos antigos que não oferecem suporte a HTML ou marcação viewport. Como essa situação pode ser abordada?

Falando francamente, você precisa de ajuda de bancos de dados especiais que armazenam informações sobre os recursos dos navegadores para dispositivos móveis. Esses bancos de dados são conhecidos como DDRs (Device Description Repository). O WURFL (Wireless Universal Resource File), o DDR usado pelo Facebook, tem uma propriedade chamada preferred_markup que você pode consultar o servidor (por exemplo, de dentro de um aplicativo ASP.NET) para determinar a marcação mais apropriada para apresentar a um dispositivo solicitante. Saiba mais sobre WURFL em wurfl.sourceforge.net. Planejo abordar WURFL e outros DDRs como 51Degrees em artigos futuros.

HTML5 e navegadores para dispositivos móveis

O HTML5 é uma linguagem de marcação que os navegadores para dispositivos móveis modernos suportam bem, pelo menos no estado atual do padrão. Isso se aplica a navegadores embutidos em smartphones (isto é, Safari no iPhone e iPad, Android WebKit e Internet Explorer 9 no Windows Phone) além de navegadores externos como o Fennec (a versão móvel do Firefox) e o Opera Mobile.

Em particular, você pode consultar mobilehtml5.org para obter uma comparação completa do suporte de HTML5 em uma variedade de navegadores para dispositivos móveis. Você verá que o suporte a Canvas e SVG é praticamente onipresente, enquanto elementos de entrada, críticos em páginas de dispositivos móveis, são bem suportadas no IOS 5, mas não em versões atuais do Android WebKit. Armazenamento local, localização geográfica e multimídia estão também praticamente em todos os lugares. 

Não tão inteligente

Com muita frequência um site para celular é simplesmente visto como um filho do site para desktop existente. Assim, acontece que a maior parte do projeto é feita da perspectiva do site para desktop, ao mesmo tempo considerando que o cliente é tão “inteligente”, ou rico e poderoso, quanto um navegador para desktop. Mas smartphones não são tão “inteligentes” quanto laptops. Essa grande fragmentação é um aspecto crítico do desenvolvimento de site para celular. Por esse motivo, ao iniciar um projeto de site para celular, os primeiros aspectos a serem pensados são casos de uso a serem cobertos e dispositivos a serem considerados. Qualquer tecnologia que possa querer usar vem depois. Em artigos futuros discutirei técnicas para identificar casos de uso de dispositivos móveis ad hoc, padrões de desenvolvimento para celular e renderização sensível a dispositivo.

Dino Esposito é o autor de “Architecting Mobile Solutions for the Enterprise” (Microsoft Press, 2012) e “Programming ASP.NET MVC 3” (Microsoft Press, 2011) e coautor de “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2008). Residente na Itália, Esposito é um palestrante sempre presente em eventos do setor no mundo inteiro. Siga-o no Twitter em twitter.com/despos.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Shane Church e Steve Sanderson