Truques de Web mobile

Palestra interativa com slides, anotações e testes pra rodar no celular/tablet.

(acesse agora no celular, tablet ou desktop pra acompanhar a palestra)

Sérgio Lopes

Sincronize seu dispositivo!

Acesse o endereço acima no seu smartphone ou tablet.
É necessário um navegador com suporte a WebSockets.

Sincronizando seu dispositivo, você acompanha exemplos em tempo real dos assuntos tratados aqui nos slides. Único requisito é usar um navegador moderno com suporte a WebSockets.

No iOS, tudo funciona bem da versão 4.2 pra cima.

No Android, recomendo fortemente o Chrome Mobile ou o Firefox. O Chrome só tá disponível pra Android 4+, mas o Firefox dá pra instalar em versões anteriores. O browser padrão do Android 4+ também funciona bem. Pra versões anteriores, recomendo usar o Firefox Mobile. (Opera não serve)

Dá pra acompanhar no computador também. Nesse caso, use um Chrome ou Firefox recente, ou IE 10.

A sincronização estará ativa entre esse navegador e seu dispositivo se a bolinha no título da palestra estiver verde.

PS. Se você quiser saber mais sobre como funciona essa sincronização, leia meu artigo sobre WebSockets no blog da Caelum.

Mobile tá bombando

Design Responsivo

Relembrando
media

queries

@media (min-width: 400px) {
   body {
      font-size: 125%;
   }
}

@media (min-width: 400px) { }
@media (min-width: 600px) and (max-width: 790px){}
@media (max-width: 600px) and (orientation: landscape){}

Site mobile

m.site.com

Site mobile direito

Redirects:
exemplo.com/sobre <> m.exemplo.com/sobre
Link pra trocar de versão
Metadados corretos pra SEO

<!-- na página Desktop coloque: -->
<link rel="alternate" href="http://m.site.com/sobre"
    media="only screen and (max-width: 700px)">

<!-- na página Mobile coloque: -->
<link rel="canonical" href="http://site.com/sobre">

Aqui vai a primeira dica, pro pessoal que vai fazer site mobile exclusivo: faça os redirects corretamente. Se recebo um link pra página de contato e abro no celular, quero cair na página de contato do celular e não na home page. E não esqueça de colocar um link pro usuário trocar de versão quando quiser, e salve isso num cookie.

E há um problema de duplicação de conteúdo que pode te encrencar no Google e SEO. Pra evitar isso, siga as recomendações deles de meta tags que se referenciam da maneira correta.

Mas tirando essas práticas, construir site mobile, seja específico ou único responsivo, há zilhões de macetes importantes. O mundo mobile é diferente do Desktop e é importante entender as diferenças, limitações e capacidades na hora de criar uma solução Web que suporte mobile.

Todas as próximas práticas da palestra são universais, pra todo tipo de projeto Web que envolva Web - responsivo ou site exclusivo.

Telas são pequenas

Sempre habilite o zoom

<!-- como irritar seu usuário -->
<meta name="viewport" 
   content="width=device-width,user-scalable=no">

<!-- ou -->
<meta name="viewport" 
   content="width=device-width, 
            minimum-scale=1,maximum-scale=1">

Sempre habilite o zoom

<!-- como deixar todo mundo feliz -->
<meta name="viewport" 
   content="width=device-width, initial-scale=1">

Novo @viewport

@viewport {
    width: device-width;
}

/* e os prefixos */
@-ms-viewport { width: device-width; }
@-o-viewport  { width: device-width; }

Elimine a barra de endereços

window.scrollTo(0,1);

Fizemos o window.scrollTo(0,1) nesse slide.

No celular, você deve ver a barra de endereços sumir. E isso libera espaço pra mais um monte de conteúdo.

(Nem todos os navegadores escondem a barra de endereços, como o Chrome Mobile que tem a barra fixa sempre. Nesses, o scrollTo não terá efeito algum.)

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

UX Hot Zones

@media (orientation: portrait) { 
    /* otimiza pra retrato */
}

@media (orientation: landscape) { 
    /* otimiza pra paisagem */
}

window.onorientationchange = function() {
   switch (window.orientation) {
      case 0: 
      case 180:
         // ... paisagem ...
         break;

      case 90: 
      case -90:
         // ... retrato ...
         break;

      default:
         // mostra um unicórnio
   }
}

Mobilize, don’t miniaturize

Barbara Ballard

Don’t shrink, rethink

Nokia

Dedo é diferente de mouse

Esqueça :hover

No celular, não existe o estado hover, tão comum no Desktop. Você não tem como passar o dedo em cima de algo sem causar um clique. Alguns navegadores tentam emular esses eventos de hover com interações pouco intuitivas que causam estranheza no usuário. Na prática, esqueça hover.

Pode usar hover puramente como decoração, adicional no Desktop, totalmente progressive enhancement. Mas não dependa dele pra mostrar conteúdo ou fazer alguma interação.

Há alguns poucos aparelhos com implementações de hover decentes. O Samsung Galaxy Note II, com sua caneta S Pen inteligente e a tela wacom, reconhece a proximidade da caneta mesmo sem tocá-la, e dispara um evento de hover na página corretamente. O Galaxy S4 consegue fazer isso mesmo com o uso do dedo, através da câmera frontal. Mas são raros os aparelhos e situações bem específicas.

Outras coisas pra esquecer

position: fixed
Lightbox
Flash, Java, Silverlight, etc

E falando em outras coisas para esquecer, temos mais alguns.

A famosa barra fixa no topo com position: fixed fica péssima no mobile. A maioria dos navegadores não suporta fixed e, os poucos que suportam, o fazem de maneira bem esquisita. Na verdade, a grande questão é como essas barras fixas devem se comportar quando temos zoom. No Android antes do 4, por exemplo, o fixed só funciona se você desabilita o zoom, algo que vimos que é bem ruim.

Aqueles irritantes lightboxes que abrem uma espécie de popup JavaScript na página mostrando fotos e outros conteúdos estão presentes em toda a Web. Mas no celular costumam ser uma péssima ideia. Costumam depender de position fixed e de ocupar o viewport como um todo, duas coisas dificeis de se fazer no mobile. Evite.

E, obviamente, evite todo tipo de plugin proprietário.

Gestos na Web

Dedos são diferentes de mouse por serem capazes de executar gestos para interações mais intuitivas e expressivas. Celulares touch têm diversos gestos diferentes, vários envolvendo diversos dedos, com significados diferentes.

Na Web, é recomendado que nos limitemos a um conjunto pequeno de gestoes que têm comportamento mais previsível nos diversos aparelhos e que todos os usuários conhecem. Importante observar que alguns smartphones low-end não possuem tela multitoque, suportando então apenas gestos de um dedo. E vários com multitoque na verdade só suportam dois pontos de toque, eliminando a utilidade de gestos com 3, 4 ou 5 dedos (como os presentes no iOS).

Na web, restrinja-se aos gestos mostrados aqui, e prefira os de 1 dedo apenas. (imagens da Open Source Gesture Library)

Gestos na Web

/* Gestos com Zepto.js */

$('div').doubleTap(function() {
    // faz algo ao tocar 2x
});

$('li').swipeRight(function() {
    // faz algo ao deslizar para direita
});

$('.foto').longTap(function() {
    // faz algo quando segurar toque
});

Input de dados é difícil

* mas não impossível

Diferentes teclados com input types HTML5

<input type="text">

<input type="url">

Diferentes teclados com input types HTML5

<input type="email">

Diferentes teclados com input types HTML5

<input type="tel">

Diferentes teclados com input types HTML5

<input type="date">

Diferentes teclados com input types HTML5

<input type="time">

<input type="text" 
    pattern="[0-9]*">

Mais ajustes no teclado

<input type="text" name="username" 
       autocorrect="none" autocapitalization="on">

* só no iOS

Form Mobile

Labels no topo ou dentro
Opção mostrar password
Touch targets grandes
Menos campos, óbvio

Usuário Senha mostrar senha

Mais algumas práticas de UX interessantes e simples de se fazer.

Vários browsers, mais notoriamente o iOS, dão zoom automaticamente num campo de formulário quando o usuário começa a preenchê-lo. Excelente para ajudar o usuário, mas isso pode criar problemas se seu formulário tem labels alinhados a esquerda do campo. Ao dar zoom, os labels serão escondidos, atrapalhando o usuário. Faça os labels então sempre acima do campo, assim ficarão visíveis. Outra opção é colocar dentro do campo em si, mas isso pode confundir o usuário por desaparecer quando ele começa a digitar a informação.

Outra opção importante é deixar o usuário visualizar a senha digitada como texto, não apenas como password com asteriscos. Acho essa uma boa prática até para o Desktop, mas no mobile é mais importante ainda porque senhas costumam ser difíceis de digitar e errá-las é muito fácil.

Libs JavaScript pra ajudar

textareas expansíveis

Mensagem:

correção de email

Email:

Você quis dizer sergio@gmail.com?

APIs avançadas pra simplificar

geolocation

navigator.geolocation
  .getCurrentPosition(function(p){

    var lat = p.coords.latitude;
    var lon = p.coords.longitude;

    // descobre a cidade
});

Nome Cidade Cor do cabelo

APIs avançadas pra simplificar

Media Capture

<input type="file" accept="audio/*;capture=microphone">
<input type="file" accept="image/*;capture=camera">
<input type="file" accept="video/*;capture=camcorder">

<!-- último draft -->
<input type="file" accept="image/*" capture>

* getUserMedia em breve

Uma ideia maluca: você tem um form de contato no site que o usuário põe o email e manda uma mensagem. Digitar uma mensagem grande no celular é um saco. O usuário pode tentar usar o reconhecimento de voz do aparelho (Siri, Android), mas é bem chatinho ainda e dá vários erros. E se você permitisse que ele te enviasse uma mensagem gravada? Não reconhecer voz, mas literalmente gravar um áudio e enviar pra você. Nunca vi um site fazendo isso, mas a ideia que quero dar é de pensar fora da caixa e usar as novidades do HTML5 pra ajudar os usuários nos problemas mais simples, como preencher um formulário.

A Media Capture API é a forma mais simples de obter um áudio/vídeo/foto do usuário. Basta um atributo especial no `input type=file`. Em compensação, não traz muito controle, só permite o upload de um arquivo gravado para o servidor.

A API getUserMedia já traz uma solução multimedia completa e permite a manipulação do vídeo/foto/som direto no browser com Canvas por exemplo. É mais complexa de usar porém traz mais opções.

O suporte a essas APIs ainda não é universal. Em Abril de 2013, temos a Media Capture API apenas no Chrome, Firefox, Android 3+, Blackberry 10 e iOS 6. A getUserMedia, apenas no Opera do Android, Blackberry 10 e Chrome Mobile beta; e no Chrome, Firefox e Opera do Desktop.

Rede e dispositivos limitados

Latência de rede absurda

* então, diminua o número de requests.

Inline com cache no localStorage

// primeiro acesso
localStorage.setItem('estilo.css', '... css ...')
document.cookie = 'arquivos=estilo.css'

// depois...
var css = document.createElement('style')
css.textContent = localStorage.getItem('estilo.css')
document.head.appendChild(css)

Uma ideia recorrente é fazer inline de várias coisas direto no HTML inicial. Fazemos inline de CSS e JS, e data-uris com imagens. O ponto ruim é que perdemos o cache desses recursos e precisaríamos baixar tudo de novo a cada request.

É possível então, via JS, salvar esses componentes no `localStorage` e indicar ao servidor, via um cookie, que não precisamos mais daquilo num próximo request. Há o overhead do processamento JS mas economizamos muitos bytes. E há a dificuldade de ter que se implementar algo no servidor.

Outro recurso que podemos usar é a HTML5 offline API. Embora um pouco complicada de usar direito, ainda mais pra controlar futuras invalidações e updates, é uma solução bacana e bem suportada em smartphones.

Aliás, essas soluções de inline, localStorage e offline resolvem outros problemas que veremos a seguir.

Browser mais limitado

connections
cache
memória
cpu
...

Os navegadores mobile têm mais restrições importantes.

Primeiro, o número de requisições simultâneas é menor que nos browsers Desktop (2 ou 4 vs 6 ou 8). Como se já não bastasse a latência ruim, temos menos conexões disponíveis. Então diminuir requisições e fazer mais inline é uma boa ideia.

E os caches dos navegadores mobile são bem limitados. O tamanho total, compartilhado por todos os sites que você abre, é bem pequeno, às vezes poucas dezenas de megabytes, incapazer de guardar no cache mais que algumas páginas, mesmo a gente colocando todos os headers corretos de expiração.

Fora isso, há muitas vezes limites no tamanho máximo de um componente cacheado. Um iPhone, por exemplo, não salva nada no cache que tenha mais de 25 KB. Quer dizer: use jQuery, por exemplo, e você perde o cache, não interessa o header.

Com um cache no controle da aplicação com localStorage ou offline API, não temos tantas limitações e podemos controlar na aplicação a forma de cache.

Evite os frameworks de sempre

jQuery
jQuery UI, jQuery mobile, YUI etc
Widgets: Facebook, Twitter etc

Aliás, é uma boa ideia evitar o jQuery como um todo no mobile. Ele tem 96KB de tamanho, o que o tira dos caches do iOS e ainda traz uma imensa lerdeza de parse - um iPhone 4 demora 10x mais que o Desktop só na execução do arquivo, depois do download. Imagine outros smartphones mais simples?

Alternativas ao jQuery com foco no mundo móvel existem aos montes. O ZeptoJS é um famoso. Cuidado apenas para não usar frameworks de apps móveis JS em sites móveis - como Sencha Touch, jQuery Mobile, jqTouch etc. Pra sites, inclusive, prefiro hoje JavaScript puro com algumas funções auxiliares do que frameworks gigantes como jQuery.

Os widgets de redes sociais como Facebook, Twitter e Google+ então são atrocidades mobile. Já são lentos no Desktop e trazem problemas sérios de indisponibilidade se não carregados assincronamente. No celular? São suicídio. Mas o legal é que a maioria da plataformas móveis já vem com recurso de Compartilhar embutido. Tanto no iOS quanto no Android você pode compartilhar uma página no Facebook ou Twitter direto do navegador sem nenhum widget.

`display: none` nunca

Fast Buttons

$('a').tap(function(event){
    location.href = this.href;
    event.preventDefault();
});

Há questões de performance que dizem respeito também a UI. Por exemplo, o tratamento de eventos.

Navegadores Desktop estão acostumados a lidar com o onclick, disparado pelo mouse. No mobile, os cliques também são suportados (automaticamente) mas são disparados pelos toque. O problema é que os dedos num mundo multitouch não servem apenas para cliques, mas para um monte de gestos como vimos.

O que acaba acontecendo então é que quando você põe o dedo na tela, o navegador precisa adivinhar que gesto você está fazendo. Será um clique? Será que você vai arrastar o dedo? Será um scroll? Assim, quando damos um toque indicando clique, o navegador ainda espera uns 300ms antes de disparar o clique pra tentar adivinhar se na verdade você não queria fazer outro toque.

O problema? Cliques com onclick são lentos no touch. O usuário aperta um botão ou link e há uma demora na execução do callback. Por isso, o pessoal do Google inventou uma técnica chamada de Fast Button que usa gestures e taps pra acionar o evento bem antes do onclick normal.

CSS3

transform 2D e 3D
transition
animation

@keyframes gira {
  0% { transform: rotate(0deg) }
  100% { transform: rotate(360deg) }
}
h1 { animation: gira 4s linear infinite; }

Truque sujo: Aceleração de hardware

transform: translateZ(0);

Resoluções incríveis

Media queries pra salvar o dia

#banner { background: url(foto_normal.png); }

@media (-webkit-min-device-pixel-ratio: 2),
       (min-resolution: 192dpi) {
  
    #banner {
       background-image: url(foto_retina.png);
       background-size: 50%;
    }
}

Telas comuns, como na maioria dos Desktops, têm pixels físicos numa razão de 1:1 com os pixels que usamos no nosso código (CSS, HTML etc). Mas telas retina aumentam essa razão e passamos a trabalhar com pixels virtuais. Um iPhone 4 têm 640 pixels físicos de largura mas representados como 320 pixels virtuais. É uma razão 2:1.

Com media queries podemos lidar com essa situação carregando imagens diferentes de acordo com a razão de pixels virtuais sobre os físicos. As telas da Apple costuma usar a razão 2, assim como celulares mais highend como Samsung Galaxy S III (chamado de xhdpi).

Mas vários celulares Android famosos (como o Galaxy S II) usam razão 1.5 (ou 3:2), a chamada hdpi. É comum também celulares medianos usarem a razão normal 1:1 (mdpi) e celulares mais simples (como o Galaxy 5) usarem resolução mais baixa de 0.75 (3:4, ldpi). Há ainda razões mais estranhas, como a tvdpi do tablet Nexus 7 e sua razão de 1.33.

Você pode lidar com diferentes densidades de pixel usando media queries. Cuidado apenas com a questão de performance. Mesmo tendo uma tela retina, às vezes pode não ser interessante dar um arquivo em alta resolução para o dispositivo, já que ele demorará para carregar.

Tenho dois artigos no blog sobre o assunto: Media queries para telas retina e Tudo que você precisa saber sobre resoluções, telas retina, devicePixelRatio, DPI, CSS pixels e etc. O meu livro de Web mobile trata ainda mais a fundo de questões relacionadas a telas de alta resolução.

srcset e image-set pro futuro

<img src="foto_normal.jpg"
    srcset="foto_retina.jpg 2x, foto_mobile.jpg 400w">

#banner {
    background: image-set(
        url(foto_normal.jpg) 1x, 
        url(foto_retina.jpg) 2x
    );
}

Para imagens com a tag img, a solução é uma nova especificação no W3C que cria o atributo srcset. Com ele, é possível indicar uma série de URLs de imagens e uma espécia de media querie para indicar densidade de pixels ou tamanho do viewport. Não são media queries de verdade pois o objetivo é não depender do parser CSS nesse ponto, fazendo o browser baixar a imagem o mais rápido possível. Ainda não há suporte em nenhum navegador.

Similar ao srcset, foi criado no rascunho do CSS4 uma proposta pra função image-set() no background. Ela recebe uma lista de imagens e configurações de densidade de pixels ou tamanho do viewport. O image-set já funciona a partir do Chrome 21 e do Safari 6 com o prefixo -webkit-.

Além dessas duas especificações, há uma proposta para se criar um novo elemento <picture> que suportaria várias imagens usando media queries completas, além do srcset.

Gráficos estão bem servidos

Mais integrado com o aparelho do que nunca

URLs mágicas

<!-- envie um email -->
<a href="mailto:contato@caelum.com.br">email</a>

<!-- disque esse número -->
<a href="tel:+551155712751">ligue já</a>

<!-- abra o app de Maps -->
<a href="http://maps.google.com/?q=Caelum">mapa</a>

<!-- instale uma app -->
<a href="https://play.google.com/store/apps/details?id=br.com.caelum.ondeestaobusao.activity">busão sp</a>

Webapps iOS

<!-- webapp 'instalável' -->
<meta name="apple-mobile-web-app-capable" content="yes">

<!-- estilo da barra do topo -->
<meta name="apple-mobile-web-app-status-bar-style" 
   content="black">

<!-- ícone do atalho  -->
<link rel="apple-touch-icon" href="icone.png">

<!-- imagem de startup -->
<link rel="apple-touch-startup-image" href="start.png">

O iOS sempre esteve a frente da concorrência na ideia de transformar a experiência de webapps em algo quase nativo. Com uma simples meta tag, você indica que é uma webapp e deve ser lançada pelo ícone da home, num browser embutido sem barra de endereços ou ferramentas. O usuário precisa "instalar" na home a webapp, mas a projetos pra ajudá-lo com o processo.

Você pode ainda configurar várias coisas, como o estilo da barra do topo, ícone do atalho da home e até uma imagem de startup. Você também pode passar várias imagens pra resoluções diferentes, usando media queries. Veja a documentação dessas opções.

Use ainda HTML5 offline API, navegação via Ajax, e transições bonitinhas na App e você tem uma app mobile com muito cara de nativa. Infelizmente, ainda não há nada parecido no Android e outros browsers. Há muito trabalho sendo feito pela Mozilla principalmente por causa do Firefox OS, mas ainda é algo proprietário. O Google tem iniciativa própria semelhante mas ainda só para o Desktop.

Webapps Windows 8

<!-- imagem pra startup screen -->
<meta name="msapplication-TileImage" content="tile.png">

<!-- cor de fundo -->
<meta name="msapplication-TileColor" content="#ef0303">

<!-- live tile -->
<meta name="msapplication-badge" content="frequency=1440; polling-uri=http://exemple.com/badge.xml">

APIs fantásticas

geolocation
orientationchange
devicemotion
getUserMedia
navigator.onLine
fullscreen API
telephone, sms
battery api
WebGL

Truques de Web mobile

Sérgio Lopes

Sincronize seu dispositivo!

Mobile tá bombando

Design Responsivo

Relembrando media queries

Site mobile

m.site.com

Site mobile direito

Telas são pequenas

Sempre habilite o zoom

Sempre habilite o zoom

Novo @viewport

Elimine a barra de endereços

UX Hot Zones

Dedo é diferente de mouse

Esqueça :hover

Outras coisas pra esquecer

Gestos na Web

Gestos na Web

Input de dados é difícil

* mas não impossível

Diferentes teclados com input types HTML5

Diferentes teclados com input types HTML5

Diferentes teclados com input types HTML5

Diferentes teclados com input types HTML5

Diferentes teclados com input types HTML5

Mais ajustes no teclado

* só no iOS

Form Mobile

Libs JavaScript pra ajudar

textareas expansíveis

correção de email

APIs avançadas pra simplificar

geolocation

APIs avançadas pra simplificar

Media Capture

* getUserMedia em breve

Rede e dispositivos limitados

Latência de rede absurda

* então, diminua o número de requests.

Inline com cache no localStorage

Browser mais limitado

Evite os frameworks de sempre

display: none nunca

Fast Buttons

CSS3

Truque sujo: Aceleração de hardware

Resoluções incríveis

Media queries pra salvar o dia

srcset e image-set pro futuro

Gráficos estão bem servidos

Mais integrado com o aparelho do que nunca

URLs mágicas

Webapps iOS

Webapps Windows 8

APIs fantásticas

Performance é a funcionalidade mobile mais importante.

Otimize para tela pequena e dedos.

Facilite a entrada de dados.

Prefira gráficos vetoriais.

Use recursos do aparelho e integrações.

Obrigado

Relembrando
media

queries

`display: none` nunca