Criar e desenvolver conteúdos para dispositivos móveis

Apresentação

UC02210 (25h) capacita os formandos para criar conteúdos digitais optimizados para dispositivos móveis — desde os princípios de design e escrita até à performance técnica, notificações push e processos de teste. O mobile é hoje o contexto principal de consumo de conteúdo digital em Portugal e no mundo.

1. Design para mobile

1.1 A thumb zone

O polegar é o principal ponto de contacto com um smartphone segurado com uma mão. O design mobile-first deve considerar quais as zonas do ecrã mais e menos acessíveis ao polegar.

Mapeamento de zonas:

O ecrã de um smartphone médio divide-se em três zonas de acessibilidade quando segurado com a mão direita:

• Zona verde (fácil acesso): área central-inferior, directamente acessível ao polegar sem reposicionar a mão. Aqui devem ficar as acções mais frequentes: botão de acção principal, navegação inferior (tab bar), botão de volta.

• Zona amarela (esticável): bordas laterais e área central. Acessível com algum esforço. Para acções secundárias.

• Zona vermelha (difícil): canto superior, especialmente o canto superior esquerdo. Ironicamente, é aqui que se costuma colocar o menu hamburguer — uma das piores práticas de UX mobile.

Estudos de comportamento: pesquisas da UX designer Hoober (2017) mostram que mais de 75% dos utilizadores seguram o telefone com uma mão na maioria do tempo. O design deve assumir uso a uma mão como caso base.

Implicações práticas: - Navigation bar no fundo do ecrã (iOS pattern) em vez de tab bar no topo. - CTA principal na metade inferior do ecrã. - Acções destrutivas (eliminar, sair) longe da zona de polegar natural.

1.2 Touch targets

Tamanho mínimo: os guias de estilo das duas plataformas principais definem tamanhos mínimos diferentes mas próximos: - Apple Human Interface Guidelines: 44 × 44 pt (pontos CSS). - Google Material Design: 48 × 48 dp (density-independent pixels).

Na prática: 44-48px é o mínimo absoluto para qualquer elemento interactivo (botão, link, ícone). Elementos mais pequenos causam erros de toque e frustração.

Espaçamento entre targets: pelo menos 8px entre elementos interactivos adjacentes para evitar activação acidental.

Exemplo em CSS:

.btn-mobile {
  min-height: 44px;
  min-width: 44px;
  padding: 12px 20px;
  /* Não usar padding < 8px em botões mobile */
}

1.3 Viewport e responsive

Viewport meta tag:

<meta name="viewport" content="width=device-width, initial-scale=1">

Sem esta tag, o browser mobile renderiza a página como se fosse um desktop de 980px (ou similar) e depois faz zoom out para caber no ecrã. O resultado é texto ilegível e elementos minúsculos.

Breakpoints comuns (CSS):

/* Mobile first: estilos base para mobile */
.container { width: 100%; padding: 0 16px; }

/* Tablet */
@media (min-width: 768px) {
  .container { max-width: 960px; padding: 0 24px; }
}

/* Desktop */
@media (min-width: 1024px) {
  .container { max-width: 1200px; }
}

Mobile-first approach: escrever primeiro os estilos para mobile, depois adicionar media queries para viewport maior. O inverso (desktop-first) resulta em CSS mais complexo e frequentemente em problemas de performance em mobile.

1.4 Gestos

Os gestos são o "vocabulário" da interacção mobile. Os padrões estabelecidos pelo iOS e Android criaram expectativas universais.

Gestos standard: - Tap: equivalente ao clique. Activar um elemento. - Double tap: zoom in (Safari, Maps) ou like (Instagram). - Long press: revelar menu de contexto ou acções adicionais. - Swipe horizontal: navegar entre ecrãs/tabs, dismissar notificações, carousel. - Swipe vertical: scroll de página ou lista; puxar para refrescar (pull to refresh). - Pinch: zoom in/out em mapas e imagens. - Swipe up from bottom: home gesture em iOS (substitui o botão home).

Affordances: o utilizador deve ter pistas visuais de que um elemento é deslizável ou tem gesto associado. Indicators de swipe (dots de paginação, bordas visíveis de conteúdo fora do ecrã).

2. Apps vs PWA vs responsive web

2.1 Responsive Web

O website responsivo adapta-se a todos os tamanhos de ecrã usando CSS flexível e media queries.

Quando é suficiente: a maioria dos projectos. Conteúdo informativo, portfolios, blogs, lojas online simples, websites corporativos.

Vantagens: - URL único, partilhável. - SEO completo — indexável pelos motores de busca. - Actualizações imediatas (não precisa de aprovação de app store). - Um único código para todos os dispositivos. - Custo de desenvolvimento mais baixo.

Limitações: - Sem acesso a câmara (limitado), GPS (API disponível mas limitada), sensores. - Sem push notifications (sem PWA ou serviço externo). - Sem funcionamento offline. - Não aparece na App Store/Play Store por defeito.

2.2 PWA (Progressive Web App)

Uma PWA é um website que usa um conjunto de tecnologias web modernas para se comportar como uma app nativa.

Tecnologias-chave: - Service Worker: script JavaScript que corre em background, gere cache e permite funcionamento offline. - Web App Manifest: ficheiro JSON que define ícone, nome, cor de tema e modo de exibição da app quando instalada. - HTTPS: obrigatório para Service Workers.

Capacidades de uma PWA: - Instalável no ecrã inicial (Add to Home Screen). - Cache de recursos para funcionamento offline ou em rede fraca. - Push notifications (suporte completo desde iOS 16.4 Safari, 2023). - Acesso a câmara, microfone, GPS, acelerómetro via APIs web. - Background sync (sincroniza dados quando a rede volta).

Exemplo de Web App Manifest (manifest.json):

{
  "name": "Sabores da Terra",
  "short_name": "SaboresTerra",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#2d7a2d",
  "icons": [
    { "src": "icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

2.3 App nativa

Desenvolvida especificamente para uma plataforma: Swift/SwiftUI para iOS, Kotlin/Jetpack Compose para Android. Ou cross-platform com React Native ou Flutter.

Quando é necessária: - Acesso profundo ao hardware (Bluetooth LE, NFC, sensores específicos). - Performance muito alta (jogos, realidade aumentada, processamento intensivo). - Presença na App Store/Google Play como canal de descoberta. - Experiências offline complexas.

Custo: muito mais alto que web. Requer programadores especializados em cada plataforma (ou em React Native/Flutter para cross-platform).

3. Conteúdo mobile-first

3.1 Padrões de leitura

Padrão F (Nielsen Norman Group, 2006): em conteúdo textual denso, o utilizador lê completamente as primeiras linhas, depois começa a fazer scans horizontais progressivamente mais curtos. O resultado é uma forma de F — o conteúdo mais à esquerda e no topo é mais lido.

Implicação: as primeiras palavras de cada parágrafo são as mais importantes. Colocar informação-chave no início de cada frase e parágrafo.

Padrão Z (Gutenberg Diagram): em páginas com menor densidade de texto e mais elementos visuais, o olho percorre um Z: canto superior esquerdo → direito → diagonal para inferior esquerdo → direito. Usado em landing pages e anúncios.

F pattern em mobile: em ecrãs estreitos, o padrão F torna-se quase um padrão I (leitura vertical do lado esquerdo). Cada linha é tão curta que o utilizador lê apenas o início antes de avançar.

3.2 Princípios de escrita mobile

Brevidade: o utilizador mobile está em movimento, com atenção dividida. Sem parágrafos longos. Cada parágrafo = uma ideia.

Hierarquia visual: usar headings, listas e bullets. O utilizador deve conseguir captar a essência do conteúdo em 5 segundos de scan.

Acção primeiro: colocar o mais importante (a acção, a conclusão, o benefício) no início, não no fim. Estilo jornalístico invertido — pirâmide ao contrário.

Linguagem activa e directa: verbos no início, frases curtas, sem jargão desnecessário.

Labels de botões e CTAs: específicos e accionáveis. Descrição da acção que vai acontecer, não uma instrução genérica.

Exemplos comparativos:

3.3 Formulários mobile

Os formulários são a maior fonte de fricção em mobile. Cada campo extra reduz as conversões.

Boas práticas: - Usar o tipo correcto de input para abrir o teclado certo: type="email" abre teclado com @; type="tel" abre teclado numérico; type="number" para valores numéricos. - autocomplete attributes para o sistema preencher automaticamente dados guardados. - Validação em tempo real (não só no submit). - Campos obrigatórios marcados claramente (ou melhor: só pedir o estritamente necessário). - Labels acima do campo (não dentro como placeholder — disappear ao escrever, confunde).

4. Performance mobile

4.1 Por que a performance é crítica

Dados de impacto: - 53% dos utilizadores abandona um site mobile que demora mais de 3 segundos a carregar (Google, 2018). - Cada segundo adicional de carregamento reduz as conversões em ~7% (Akamai). - O Google usa Core Web Vitals como sinal de ranking de SEO desde 2021 (mobile-first indexing).

Contexto mobile vs desktop: - Rede: 4G (50-100 Mbps teórico, 10-30 Mbps real) vs fibra doméstica (100-1000 Mbps). - CPU/RAM: muito mais limitados que desktop. - Bateria: JavaScript pesado drain rápido. - Contexto: o utilizador usa o telemóvel em contextos de atenção curta e pode estar em movimento.

4.2 Core Web Vitals

LCP (Largest Contentful Paint): mede o tempo até o maior elemento visível no viewport ser renderizado. Frequentemente uma imagem de hero ou um heading grande. - Bom: < 2.5s. - Precisa de melhorar: 2.5-4s. - Mau: > 4s.

INP (Interaction to Next Paint): substituiu o FID em 2024. Mede o tempo entre uma interacção do utilizador (click, tap, teclado) e o próximo frame visual de resposta. - Bom: < 200ms. - Precisa de melhorar: 200-500ms. - Mau: > 500ms.

CLS (Cumulative Layout Shift): acumulação de deslocamentos de layout inesperados durante o carregamento. - Bom: < 0.1. - Precisa de melhorar: 0.1-0.25. - Mau: > 0.25.

4.3 Optimizações de performance para mobile

Imagens: - Formato WebP (25-34% mais pequeno que JPEG). - srcset para servir tamanhos adequados ao viewport. - loading="lazy" para imagens abaixo da dobra. - width e height definidos para prevenir CLS. - Preload da imagem LCP.

JavaScript: - Minificação e tree-shaking. - Code splitting — carregar apenas o JS necessário para a página actual. - Diferir scripts não críticos: <script defer> ou <script async>.

CSS: - Critical CSS inline no <head> para renderização inicial. - CSS não crítico carregado depois.

Cache: - Service Worker para caching de assets estáticos (PWA). - HTTP cache headers correctos. - CDN para assets estáticos.

5. Push notifications e engagement

5.1 O poder e o risco das notificações

Push notifications têm o CTR (Click-Through Rate) mais alto de qualquer canal digital — em média 7-10%, comparado com 1-3% do email. Mas são profundamente intrusivas.

O problema: as apps que abusam de notificações são desinstaladas ou têm as notificações desactivadas. Uma vez que o utilizador desactiva, raramente reactiva.

Permissão: o utilizador deve dar permissão explícita para receber notificações. Pedir permissão imediatamente ao abrir a app (sem contexto) resulta em 90%+ de rejeição. Pedir após o utilizador ter visto valor da app resulta em 50%+ de aceitação.

5.2 Quando usar notificações

Uso justificado: - Evento urgente ou com prazo: "A tua promoção expira em 2 horas". - Evento personalizado que o utilizador esperava: "A tua encomenda foi enviada". - Acção de outro utilizador que requer atenção: "João comentou no teu post". - Alerta de segurança: "Login de novo dispositivo detectado". - Conteúdo de alta relevância pessoal: "Saiu novo episódio de [série seguida]".

Uso não justificado: - Marketing genérico sem personalização. - "Estás com saudades de nós!" (apps de jogos/social que perderam utilizadores). - Múltiplas notificações por dia sem razão clara. - Replicar email marketing em notificações.

5.3 Copywriting de notificações

Estrutura: - Título (50 chars max): o quê/quem. Específico e relevante. - Corpo (100 chars max): contexto e motivo para clicar. Inclui o benefício ou a urgência. - CTA implícito: o utilizador deve saber o que vai acontecer ao clicar.

Deep linking: a notificação deve abrir directamente no contexto relevante da app, não na homepage. Uma notificação sobre uma encomenda deve abrir no estado dessa encomenda, não no menu principal.

5.4 A/B testing de notificações

O A/B testing em notificações testa variantes para maximizar o CTR e a conversão.

O que testar: - Copy do título. - Timing (hora do dia, dia da semana). - Personalização vs genérico. - Emojis vs sem emojis. - Urgência vs benefício.

Processo: 1. Definir a métrica de sucesso (CTR? conversão após abrir?). 2. Criar duas versões (A e B) com uma variável diferente. 3. Enviar a cada metade da audiência aleatoriamente. 4. Aguardar volume suficiente (mínimo 1000 envios por variante para significância estatística). 5. Implementar o vencedor.

6. Testes em dispositivos

6.1 Chrome DevTools Device Mode

O DevTools do Chrome inclui um modo de emulação de dispositivos (F12 → ícone de telemóvel).

Capacidades: - Simular viewport de qualquer dimensão. - Simular densidades de ecrã (1x, 2x, 3x para Retina). - Throttling de rede (Fast 4G, Slow 3G, Offline) — simula performance em redes móveis. - Throttling de CPU (4×, 6× lento) — simula performance de hardware móvel. - Simular touch events.

Limitações: - Não simula a performance real de hardware móvel. - Não simula comportamentos específicos de browsers mobile (Safari iOS tem muitas particularidades). - Não testa gestos multi-toque.

6.2 Dispositivos reais

Para testes de qualidade antes de lançamento, testar em pelo menos: - iPhone com versão de iOS mais recente (Safari). - iPhone com versão de iOS popular mais antiga (Safari iOS tem bugs específicos por versão). - Android com Chrome. - Android de gama média (não apenas flagship — a maioria dos utilizadores tem hardware mais lento).

6.3 BrowserStack e ferramentas de cloud testing

BrowserStack: plataforma de nuvem com acesso a centenas de dispositivos reais. Permite testar em qualquer combinação de dispositivo + SO + browser sem possuir o hardware.

Plano gratuito: limitado em tempo e dispositivos. Suficiente para testes ocasionais.

Outros: LambdaTest, Sauce Labs, Perfecto.

6.4 Remote Debugging

Chrome Remote Debugging (Android): 1. Android: Definições → Sobre o telefone → tocar 7× em "Número de compilação" para activar Opções de Programador. 2. Opções de Programador → USB Debugging → activar. 3. Ligar com cabo USB ao computador. 4. Chrome desktop: chrome://inspect → aguardar o dispositivo aparecer. 5. Clicar "inspect" em qualquer tab aberto no Chrome mobile. 6. DevTools completo abre, com acesso à consola, DOM inspector, Network, e performance do dispositivo real.

Safari Web Inspector (iOS): 1. iPhone/iPad: Definições → Safari → Avançado → Web Inspector → activar. 2. Ligar com cabo USB ao Mac. 3. Safari no Mac: menu Develop → [nome do dispositivo] → [tab ou app aberta]. 4. Web Inspector abre para o contexto do dispositivo iOS.

Glossário

Breakpoint: ponto de mudança no CSS onde o layout se adapta a um novo tamanho de ecrã.

CLS: Cumulative Layout Shift — estabilidade visual durante o carregamento.

CTR: Click-Through Rate — taxa de cliques sobre impressões.

Deep linking: link que abre uma localização específica dentro de uma app.

INP: Interaction to Next Paint — tempo de resposta a interacções do utilizador.

LCP: Largest Contentful Paint — tempo de carregamento do maior elemento visível.

Mobile-first: abordagem de design que começa pelo ecrã móvel e expande para maior.

PWA: Progressive Web App — website com capacidades de app nativa.

Service Worker: script JavaScript em background que gere cache e notificações.

Thumb zone: área de ecrã acessível confortavelmente ao polegar em uso a uma mão.

Touch target: área interactiva mínima de 44-48px para interacção táctil.

Viewport: área visível do browser — varia conforme o dispositivo e orientação.

Web App Manifest: ficheiro JSON que define como uma PWA se comporta quando instalada.