Planear o layout antecipadamente

O planeamento do layout das páginas e da interação deve ser planeado antecipadamente.

Quando se estiverem a desenhar os esboços e maquetas do website, devem ser desenhadas as respetivas derivações para todos os ecrãs. Se este planeamento for feito logo nas fases iniciais, evita-se ter de refazer layouts e código HTML para depois adaptar os conteúdos e, principalmente, a navegação aos vários tamanhos de ecrãs.

Esboço de uma página em vários tamanhos de ecrã

Esconder conteúdos?

Por vezes, há situações que nos fazem equacionar esconder alguns conteúdos dos ecrãs mais pequenos. Apesar de ser uma opção válida, é preciso salientar que pelo facto de um utilizador estar a usar um ecrã mais pequeno isso não significa que o possamos discriminar mostrando-lhe menos informação do que um utilizador com um ecrã maior.

É preciso pesar os prós e contras desta decisão, sendo que, os conteúdos principais devem poder ser acedidos em qualquer dispositivo, independentemente do seu tamanho ou forma de interação. Isto significa que podemos esconder alguns conteúdos acessórios da página desde que não tenham relevância para o conteúdo que queremos mostrar ao utilizador ou desde que permitam uma forma alternativa de navegar até eles.

Escolher uma Framework (opcional)

Apesar de ser possível desenvolver um website responsive "à mão", recomendamos o uso de uma framework que torne este trabalho o mais simples possível.

As frameworks permitem desenhar os layouts das páginas com base em grelhas que depois são facilmente transformadas de modo a adaptarem-se aos vários tamanhos de ecrãs.

As frameworks têm ainda a facilidade de incluirem alguns elementos interativos que permitem melhorar a experiência de utilização em vários contextos, como por exemplo menus de navegação, janelas modais, validação de formulários, etc.

InK - Interface Toolkit
SAPO

A framework do SAPO para a criação de websites responsive com base numa grelha fluída. Está a ser usada neste site (SAPO UX) e na maioria dos websites responsive do SAPO.

Bootstrap
Twitter

A framework mais popular para a criação de websites responsive e mobile first, desenvolvida originalmente pelo Twitter.

Nota: Os exemplos que iremos dar a seguir serão sempre relativos à framework InK.

Fornecer elementos otimizados para mobile

O principal problema dos websites responsive não é apenas o pouco espaço disponível no ecrã. Quando estamos a falar destes dispositivos, normalmente estamos a falar da sua utilização em redes móveis que podem ser lentas e/ou planos de dados que não são ilimitados.

Assim, é importante garantir que os conteúdos que um website responsive carrega estão otimizados para serem consumidos nestas circunstâncias. Isto inclui servir imagens mais leves, substituir elementos Flash (caso existam) por equivalentes em HTML5 (ex: players de vídeo) e reduzir os elementos decorativos ao menor número de itens e ficheiros possível (ex: usar CSS Sprites para as imagens).

Image Queries

No caso das imagens, podem ser usadas image-queries para identificar a largura do ecrã e assim servir uma imagem mais pequena quando o utilizador está a usar um ecrã mais pequeno. Isto funciona para as imagens incluídas usando a tag <img>.

Exemplo do uso de image-queries na framework InK

No futuro poderá usar-se o novo elemento <picture> que permitirá um melhor controlo das imagens para os vários dispositivos, sem depender do uso de JavaScript.

<picture>
	<source media="(min-width: 40em)" srcset="big.jpg 1x, big-hd.jpg 2x">
	<source srcset="small.jpg 1x, small-hd.jpg 2x">
	<img src="fallback.jpg" alt="">
</picture>

No SAPO UX temos uma secção dedicada exclusivamente ao uso do elemento <picture> com vários exemplos práticos e dicas de utilização.

Aviso importante: O elemento <picture> ainda não é suportado por todos os browsers, mesmo os mais recentes. Mais informações.

Media Queries

Se estivermos a usar imagens como background-image em CSS, então temos de usar media-queries para detectar a largura do ecrã e assim servir uma imagem de fundo diferente.

/* Carregamos primeiro a imagem para ecrãs pequenos (ex: <400px) */
@media only screen and (max-width: 400px) {
	.hero {
		background-image: url(../img/hero-small.jpg);
	}
}

/* E depois a imagem para ecrãs maiores (>401px) */
@media only screen and (min-width: 401px) {
	.hero {
		background-image: url(../img/hero-large.jpg);
	}
}

No código acima, poderiamos carregar por omissão a imagem mais pequena (removendo a media-query) e depois se o ecrã fosse maior, carregar a imagem maior, mas isso implicaria o carregamento das duas imagens quando apenas uma delas iria ser necessária. Em termos de performance, devemos tentar carregar o menor número de itens possível, e assim apenas carregamos a imagem de que necessitamos.

Desta forma, se quisermos que a imagem carregue em browsers mais antigos que não interpretam media-queries (ex: Internet Explorer 8 e inferiores), temos de adicionar a regra de CSS ao ficheiro com os estilos específicos para IE (carregado via conditional comments).

/* CSS fallback para browsers antigos */
/* A incluir num ficheiro externo carregado com conditional comments */
.hero {
	background-image: url(../img/hero-large.jpg);
}

Retina

Para ecrãs retina, existe uma media-query específica para carregar conteúdos com uma melhor resolução.

/* Imagem normal e dimensões do container */
.hero {
	background-image: url(../img/hero.jpg);
	width:200px;
	height:100px;
}

/* Imagem retina, com as mesmas dimensões definidas no background-size */
@media 
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and (   min--moz-device-pixel-ratio: 2),
only screen and (     -o-min-device-pixel-ratio: 2/1),
only screen and (        min-device-pixel-ratio: 2),
only screen and (                min-resolution: 192dpi),
only screen and (                min-resolution: 2dppx) { 
    .hero {
		background-image: url(../img/hero-retina.jpg);
		background-size: 200px 100px;
	}
}

Nota: Para qualquer um dos casos (image ou media queries), é necessário ter as imagens nas várias resoluções guardadas no servidor.

Fornecer opções de navegação simples

À medida que o espaço vai reduzindo, é preciso ir simplificando as opções de navegação. No entanto, se o menu já for simples à partida, não serão necessários muitos ajustes para o adaptar a um ecrã mais pequeno.

Por outro lado, um menu de navegação horizontal com vários itens e sub-níveis vai ser impossível de usar num ecrã de um telemóvel. A melhor forma de permitir a escalabilidade dos menus de navegação num ecrã pequeno, é colocá-los na vertical.

Identificar claramente o acesso à navegação

Com o aumento da popularidade das aplicações móveis, começou a aparecer o padrão do uso de um botão ou ícone num dos cantos superiores do ecrã para aceder à navegação. Devido ao tipo de ícone usado ( ) ser parecido com um hambúrguer (uma fatia de carne entre duas fatias de pão), este passou a chamar-se de "hambúrguer de navegação" ou "ícone do hambúrguer".

O uso uma legenda permite ter melhores
resultados na identificação do menu de navegação

Em testes realizados com utilizadores, verificámos que, apesar da popularidade e utilização do ícone ser bastante elevada no contexto das aplicações móveis, em websites isso não se verificou. A maior parte das pessoas ignorou ou não viu o ícone de menu quando este era apresentado sozinho no topo da página.

A solução passa por acompanhar o ícone sempre de uma legenda em texto que o identifique como o acesso à navegação. O uso da palavra "MENU" juntamente com o ícone permitiu melhorar bastante os resultados obtidos em testes com utilizadores.

Esta regra aplica-se à utilização de ícones ao longo de todo o website, pois o seu reconhecimento é bastante maior se os mesmos forem acompanhados de uma legenda que identifique a sua ação principal. Mais informação sobre a necessidade de adicionar legendas aos ícones neste artigo de Jakob Nielsen: Icon Usability

Navegação "off-canvas" ou "slide down"

Exemplo de menu "off-canvas" com scroll vertical

Existem várias maneiras de abrir o menu de navegação, sendo que as mais comuns são o "off-canvas" (empurra o site para o lado e mostra o menu na lateral) e o "slide down" (abre o menu em cima dos conteúdos ou empurra o site para baixo).

A escolha entre a forma como o menu vai abrir depende muito da quantidade de itens que o menu tem. Um menu mais simples e com poucos itens pode abrir no topo da página e ficar totalmente visível no ecrã. Um menu com muitos itens beneficia mais de abrir lateralmente, pois permite fazer scroll pelos itens de navegação caso estes não caibam todos dentro do ecrã.

No exemplo mostrado na imagem, a navegação "off-canvas" inclui também o formulário de pesquisa e tem uma arrumação simples dos conteúdos em pequenos grupos, devidamente separados e titulados. Ou seja, não basta apenas colocar toda a navegação na barra lateral, é preciso organizá-la de modo a que seja simples de usar.

Usando uma framework como o InK, é possível criar este tipo de navegação de forma bastante simples e rápida. Em baixo, temos um exemplo de como se pode criar uma página com um menu de navegação à esquerda (left-drawer) e outro à direita (right-drawer).

Na zona de conteúdo (#main-content) temos os links/botões que despoletam a abertura de cada um dos menus.

<body class="ink-drawer">
    <div class="left-drawer">
        Gaveta de menu à esquerda
    </div>
    <div class="right-drawer">
        Gaveta de menu à direita
    </div>
    <div id="main-content" class="content-drawer ink-grid">
        <a class="left-drawer-trigger" href="">Abre menu à esquerda</a>
        <a class="right-drawer-trigger" href="">Abre menu à direita</a>
        Conteúdos da página...
    </div>
</body>

<script>
    Ink.requireModules(['Ink.UI.Drawer_1'], function (Drawer) {
        new Drawer();
    });
</script>

Mais detalhes sobre como criar um menu "off-canvas" com InK

Aumentar o tamanho das áreas clicáveis

Quando estamos a usar um computador, normalmente usamos um dispositivo apontador como o rato para clicar nos links e botões existentes na página.

Porém, quando usamos um smartphone ou tablet, o dispositivo apontador passa a ser o nosso dedo. Ao contrário do rato, cujo clique é feito num único pixel no ecrã (permitindo uma precisão muito grande), o dedo humano cobre uma área bastante maior do ecrã e torna-se difícil acertar em elementos mais pequenos sem carregar por engano nos elementos que estão próximos.

Desta forma, foram definidas regras por cada plataforma para o tamanho mínimo dos elementos clicáveis em aplicações móveis. Por exemplo, em iOS o tamanho mínimo era inicialmente de 44px de altura e 44px de largura, mas com o aparecimento de ecrãs retina, o uso de unidades em pixels foi substituído por pontos. As regras da Microsoft para o Windows Phone 8 sugerem ainda que exista um espaçamento mínimo de 8px entre cada item clicável.

Exemplo de paginação sem espaçamento e
paginação com espaçamento extra em cada link

Existem vários estudos que tentaram identificar o tamanho médio da ponta do dedo humano, ex:

• Estudo do MIT
• Estudo do uso do polegar em interfaces táteis

Com base nestes estudos, identificou-se que a extremidade do dedo humano mede entre 8mm e 10mm, o que, transferindo para medidas que se podem usar na web, equivale a mais ou menos entre 30px e 40px de tamanho mínimo para os elementos clicáveis.

Na prática, isso significa que os links mais pequenos devem ser aumentados ou devem ter um espaçamento extra (padding) para ficarem maiores. O ideal seria que esta regra se aplicasse a qualquer tamanho de ecrã por motivos de acessibilidade, mas é especialmente crítica em interfaces que vão ser navegados com o dedo.

Permitir instalar o site no telemóvel

A maioria dos smartphones permite a instalação de websites no ecrã inicial do dispositivo como se fossem aplicações nativas. Para tal, basta selecionar a opção "adicionar ao ecrã inicial/add to homescreen" em qualquer website.

Ou seja, à partida, não é preciso fazer nada, mas podemos melhorar essa experiência de várias maneiras, nomeadamente adicionando um ícone ao website e definindo algumas opções como por exemplo se queremos que o site abra em ecrã inteiro em vez de abrir no browser.

A versão mais recente do Chrome recomenda o uso de um ficheiro manifest.json que contém os meta-dados necessários para configurar o nome do website, a imagem que servirá de ícone e qual o URL principal. No entanto, para manter a compatibilidade com outros browsers e sistemas operativos, recomendamos para já o uso das seguintes opções:

Adicionar um ícone ao website

Para adicionar um ícone ao website basta adicionar as tags correspondentes dentro da <head> das páginas. Uma vez que cada sistema operativo tem regras diferentes, é necessário incluir a imagem em vários formatos de modo a ser reconhecida corretamente. As regras do Android e iOS recomendam o seguinte:

<!-- Ícones para Android -->
<link rel="icon" sizes="192x192" href="icon-highres.png">
<link rel="icon" sizes="128x128" href="icon.png">

<!-- Ícones para iOS -->
<link rel="apple-touch-icon" href="touch-icon.png">
<link rel="apple-touch-icon" sizes="76x76" href="touch-icon-ipad.png">
<link rel="apple-touch-icon" sizes="120x120" href="touch-icon-iphone-retina.png">
<link rel="apple-touch-icon" sizes="152x152" href="touch-icon-ipad-retina.png">

Abrir em ecrã inteiro

Para simular melhor o comportamento de uma app nativa, podemos permitir que o website abra em ecrã inteiro no dispositivo do utilizador. Para tal, basta também adicionar as seguintes meta-tags para Android e iOS:

<!-- Android -->
<meta name="mobile-web-app-capable" content="yes">

<!-- iOS (usar com cuidado, ver aviso importante em baixo) -->
<meta name="apple-mobile-web-app-capable" content="yes">

AVISO IMPORTANTE: Em iOS, ao clicar num link de um site que abra em ecrã inteiro, o utilizador irá ser redirecionado para o browser Safari, criando assim uma má experiência de utilização. O uso de websites em ecrã inteiro em iOS deve restringir-se apenas a websites que usem uma navegação totalmente feita com AJAX, ou seja, que não implique o carregamento de páginas novas ao clicar num link.

Indicar que o site pode ser instalado no telemóvel

Não é muito comum os utilizadores instalarem websites nos seus dispositivos. Apesar de poder ser uma forma mais rápida para aceder a um website que costumam visitar recorrentemente, a maior parte dos utilizadores não sabe sequer que existe essa possibilidade.

Como tal, podemos dar uma pequena ajuda e indicar aos utilizadores que podem instalar o website, seguindo umas instruções simples (normalmente implicam 2 passos).

Exemplo de balão para adicionar o site ao ecrã inicial

A forma mais comum de dar esta indicação é através de um pequeno balão com o ícone do website, o nome e uma pequena instrução de como fazer.

Este balão tem de poder ser fechado pelo utilizador e não deve ser demasiado intrusivo. Ou seja, não deve aparecer sempre que o utilizador visita o website. O ideal seria que o balão apenas aparecesse após algumas visitas do mesmo utilizador num dispositivo móvel ao website. Isso significa que é um utilizador regular do website num dispositivo móvel e nessa altura podemos indicar-lhe que pode ter uma forma mais rápida de aceder a esse website, adicionando-o ao seu ecrã inicial.

Aqui o importante é dar algo útil aos utilizadores (aqueles que visitam o website regularmente num dispositivo móvel) em vez de perder essa oportunidade ao mostrar o balão a um utilizador que entra pela primeira vez no website e fecha o balão porque ainda não acha que o website é útil o suficiente para o instalar no telemóvel.

Testar o website em dispositivos com vários tamanhos de ecrã

Sempre que possível, os sites responsive devem ser testados em vários dispositivos com tamanhos de ecrã diferentes.

Por exemplo, um iPhone (até à versão 5S) renderiza os websites com 320px de largura enquanto que a maioria dos Android renderiza com 360px de largura. E depois há uma série de tablets e phablets com ecrãs entre os 380px e os 800px de largura até se chegar à resolução "normal" de 1024. A partir daqui também se pode testar nas resoluções mais comuns de desktops e laptops como 1280px ou 1366px de largura.

O "Inspector" do Chrome permite emular uma série de dispositivos com tamanhos diferentes sem haver a necessidade de ter os dispositivos físicos para testar.

Inspector do Chrome a simular um smartphone Nexus 5