Um guia para projetar experiências da Web para redes lentas e off-line.
Este artigo apresenta diretrizes de design sobre como criar uma ótima experiência em redes lentas e off-line.
A qualidade de uma conexão de rede pode ser afetada por vários fatores, como:
- Cobertura ruim de um provedor.
- Condições climáticas extremas.
- Falta de energia.
- entrar em "zonas mortas" permanentes, como em edifícios com paredes que bloqueiam conexões de rede;
- Entrar em "zonas mortas" temporárias, como ao viajar de trem ou passar por um túnel.
- Conexões de Internet com marcação de tempo, como em aeroportos ou hotéis.
- Práticas culturais que exigem acesso limitado ou sem acesso à Internet em horários ou dias específicos
Sua meta é oferecer uma boa experiência que diminua o impacto das mudanças de conectividade.
Decida o que mostrar aos usuários quando eles tiverem uma conexão de rede ruim
A primeira pergunta a ser feita é como é o sucesso e a falha de uma conexão de rede? Uma conexão bem-sucedida é a experiência on-line normal do app. No entanto, a falha de uma conexão pode ser o estado off-line do app e a forma como ele se comporta quando há uma rede atrasada.
Ao pensar sobre o sucesso ou falha de uma conexão de rede, você precisa se fazer estas perguntas importantes sobre a experiência do usuário:
- Quanto tempo você espera para determinar o sucesso ou falha de uma conexão?
- O que você pode fazer enquanto o sucesso ou o fracasso está sendo determinado?
- O que você precisa fazer em caso de falha?
- Como você informa o usuário sobre as informações acima?
Informar os usuários sobre o estado atual e a mudança de estado
Informe o usuário sobre as ações que ele ainda pode realizar em caso de falha na rede e sobre o estado atual do aplicativo. Por exemplo, uma notificação poderia dizer:
Parece que você tem uma conexão de rede ruim. Não se preocupe. As mensagens serão enviadas quando a rede for restaurada.
Informar os usuários quando a conexão de rede melhora ou é restaurada
A maneira como você informa ao usuário que a conexão de rede melhorou depende do seu aplicativo. Apps como os da bolsa de valores, que priorizam informações atuais, precisam ser atualizados automaticamente e notificar o usuário assim que possível.
É recomendável informar ao usuário que o app da Web foi atualizado "em segundo plano" usando uma indicação visual, como, por exemplo, um elemento de aviso do Material Design. Isso envolve a detecção da presença de um service worker e uma atualização do conteúdo gerenciado. Confira um exemplo de código dessa função em ação aqui (link em inglês).
Um exemplo disso é o Status da plataforma do Chrome, que posta uma observação para o usuário quando o app é atualizado.
Também é possível mostrar a última vez que o app foi atualizado em um espaço de destaque. Isso seria útil para um app de conversão de moedas, por exemplo.
Aplicativos como apps de notícias podem mostrar uma notificação simples do toque para atualizar informando ao usuário sobre novos conteúdos. A atualização automática faria com que os usuários perdessem o lugar.
Atualizar a IU para refletir o estado contextual atual
Cada parte da IU pode ter o próprio contexto e funcionalidade, que mudam dependendo da exigência de uma conexão. Um exemplo seria um site de comércio eletrônico em que seja possível navegar off-line. O botão "Comprar" e o preço serão desativados até que a conexão seja restabelecida.
Outras formas de estados contextuais podem incluir dados. Por exemplo, o aplicativo financeiro Robinhood permite que os usuários comprem ações e usa cores e gráficos para notificá-lo quando o mercado estiver aberto. Toda a interface fica branca e esmaece quando o mercado fecha. Quando o valor das ações aumenta ou diminui, cada widget individual fica verde ou vermelho, dependendo do estado.
Ensinar o usuário a entender o modelo off-line
O off-line é um novo modelo mental para todos. Você precisa informar seus usuários sobre quais mudanças ocorrerão quando eles não tiverem uma conexão. Informe onde grandes dados são salvos e ofereça a eles configurações para mudar o comportamento padrão. Use vários componentes de design da IU, como linguagem informativa, ícones, notificações, cores e imagens para transmitir essas ideias coletivamente, em vez de depender de uma única escolha de design, como um ícone só, para contar a história.
Oferecer uma experiência off-line por padrão
Se o app não precisa de muitos dados, armazene esses dados em cache por padrão. Os usuários podem ficar cada vez mais frustrados se só conseguirem acessar os dados com uma conexão de rede. Tente tornar a experiência o mais estável possível. Uma conexão instável fará com que seu app não seja confiável, porque um app que diminui o impacto de uma falha de rede parecerá mágico para o usuário.
Sites de notícias podem se beneficiar com o download e o salvamento automático das últimas notícias. Assim, o usuário pode ler as notícias de hoje sem uma conexão, talvez fazendo o download do texto sem as imagens do artigo. Além disso, adapte-se ao comportamento do usuário. Por exemplo, se a seção de esportes for o que eles costumam acessar, defina esse download como prioritário.
Informar ao usuário quando o app está pronto para consumo off-line
Quando um app da Web é carregado pela primeira vez, é necessário indicar ao usuário se ele está pronto para uso off-line. Faça isso com um widget que fornece feedback breve sobre uma operação usando uma mensagem na parte de baixo da tela. Por exemplo, quando uma seção foi sincronizada ou um arquivo de dados foi transferido por download.
Mais uma vez, pense na linguagem que você está usando para ter certeza de que ela é adequada para seu público-alvo. Verifique se a mensagem é a mesma em todas as instâncias em que é usada. O termo off-line geralmente é mal entendido por um público não técnico, então use uma linguagem baseada em ação com que seu público possa se identificar.
Tornar a opção "salvar para off-line" uma parte óbvia da interface para apps com uso intenso de dados
Se um aplicativo usar grandes quantidades de dados, verifique se há uma chave ou alfinete para adicionar um item para uso off-line em vez de download automático, a menos que um usuário tenha solicitado especificamente esse comportamento em um menu de configurações. Verifique se a IU de fixação ou download não é obscurecida por outros elementos e se o recurso está óbvio para o usuário.
Um exemplo seria um reprodutor de música que requer grandes arquivos de dados. O usuário está ciente do custo de dados associado, mas também pode querer usar o player off-line. O download de músicas para uso posterior exige que o usuário planeje com antecedência. Portanto, pode ser necessário informar sobre isso durante a integração.
Esclareça o que está disponível off-line
Seja claro sobre a opção oferecida. Pode ser necessário mostrar uma guia ou configuração que mostre uma "biblioteca off-line" ou um índice de conteúdo para que o usuário possa conferir facilmente o que está armazenado no smartphone e o que precisa ser salvo. Verifique se as configurações são concisas e esclareça onde os dados serão armazenados e quem terá acesso a eles.
Mostrar o custo real de uma ação
Muitos usuários consideram a capacidade off-line de "download". Os usuários em países em que as conexões de rede falham ou não estão disponíveis com frequência compartilham conteúdo com outros usuários ou salvam conteúdo para uso off-line quando têm conectividade.
Os usuários de planos de dados podem evitar o download de arquivos grandes por medo de gerar custos. Portanto, também é possível mostrar um custo associado para que os usuários possam fazer uma comparação ativa de um arquivo ou tarefa específico. Por exemplo, se o app de música acima puder detectar se o usuário está em um plano de dados e mostrar o tamanho do arquivo para que os usuários possam ver o custo de um arquivo.
Evitar experiências de invasão
Muitas vezes, os usuários invadem uma experiência sem perceber. Por exemplo, antes de apps da Web de compartilhamento de arquivos baseados na nuvem, era comum que os usuários salvassem arquivos grandes e os anexassem aos e-mails para continuar a edição em um dispositivo diferente. É importante não se envolver nessa experiência invadida, mas observar o que o usuário está tentando alcançar. Em outras palavras, em vez de pensar em como tornar a anexação de um arquivo grande mais fácil de usar, resolva o problema de compartilhamento de arquivos grandes entre vários dispositivos.
Torne as experiências transferíveis de um dispositivo para outro
Ao criar redes instáveis, tente sincronizar assim que a conexão melhorar para que a experiência seja transferível. Por exemplo, imagine um app de viagens que perde a conexão de rede no meio do processo de reserva. Quando a conexão é restabelecida, o app é sincronizado com a conta do usuário, e ele pode continuar a reserva no dispositivo desktop. A impossibilidade de transferir experiências pode ser incrivelmente desagradável para os usuários.
Informar o usuário sobre o estado atual dos dados. Por exemplo, você pode mostrar se o app foi sincronizado. Sempre que possível, explique o motivo, mas tente não sobrecarregar os usuários com mensagens.
Criar experiências de design inclusivas
Ao projetar, procure ser inclusivo, fornecendo dispositivos de design significativos, linguagem simples, iconografia padrão e imagens significativas que orientem o usuário a concluir a ação ou tarefa, em vez de atrapalhar o progresso.
Usar uma linguagem simples e concisa
Uma boa experiência do usuário não se resume a uma interface bem projetada. Ele inclui o caminho que um usuário percorre, além das palavras usadas no app. Evite jargões técnicos ao explicar o estado do app ou os componentes de IU individuais. Considere que a frase "app off-line" pode não transmitir ao usuário o estado atual do app.
Usar vários dispositivos de design para criar experiências do usuário acessíveis
Use linguagem, cores e componentes visuais para demonstrar uma mudança de estado ou status atual. O uso exclusivo de cores para demonstrar o estado pode não ser notado pelo usuário e pode ficar inacessível para usuários com deficiência visual. Além disso, o instinto para os designers é usar uma IU esmaecida para representar off-line, mas isso pode ter um significado carregado na Web. A IU esmaecida, como elementos de entrada em um formulário, também significa que um elemento está desativado. Isso poderá causar confusão se você usar apenas a cor para retratar o estado.
Para evitar mal-entendidos, expresse estados diferentes para o usuário de várias maneiras, por exemplo, com cores, rótulos e componentes de IU.
Usar ícones que transmitem significado
Verifique se as informações são transmitidas corretamente com rótulos de texto significativos e ícones. Os ícones podem ser problemáticos, já que o conceito de off-line na Web é relativamente novo. Os usuários podem entender mal os ícones usados por conta própria. Por exemplo, usar um disquete para salvar faz sentido para uma geração mais velha, mas os usuários jovens que nunca viram um disquete podem ficar confusos com a metáfora. Da mesma forma, o ícone de menu de hambúrguer é conhecido por confundir os usuários quando apresentado sem um rótulo.
Ao apresentar um ícone off-line, tente manter a consistência com os recursos visuais padrão do setor (quando existem), além de fornecer um rótulo de texto e uma descrição. Por exemplo, salvar para off-line pode ser um ícone de download típico ou talvez, se a ação envolver uma sincronização, pode ser um ícone de sincronização. Algumas ações podem ser interpretadas como salvar para off-line em vez de demonstrar o status de uma rede. Pense na ação que você está tentando transmitir em vez de apresentar ao usuário um conceito abstrato. Por exemplo, salvar ou fazer o download de dados se baseia em ações.
O modo off-line pode significar várias coisas, dependendo do contexto, como download, exportação, fixação etc. Para mais inspiração, confira o conjunto de ícones do Material Design (em inglês).
Usar layouts básicos com outros mecanismos de feedback
Um layout esqueleto é essencialmente uma versão em wireframe do app exibida durante o carregamento do conteúdo. Isso ajuda a demonstrar ao usuário que o conteúdo está prestes a ser carregado. Considere também usar uma IU de pré-carregador, com um rótulo de texto informando ao usuário que o app está sendo carregado. Um exemplo seria pulsar o conteúdo do wireframe, transmitindo ao app a sensação de que ele está ativo e carregando. Isso garante ao usuário que algo está acontecendo e ajuda a evitar reenvios ou atualizações do app.
Não bloquear conteúdo
Em alguns aplicativos, um usuário pode acionar uma ação, como a criação de um novo documento. Alguns apps tentam se conectar a um servidor para sincronizar o novo documento. Para demonstrar isso, eles mostram uma caixa de diálogo modal intrusiva que cobre toda a tela. Isso pode funcionar bem se o usuário tiver uma conexão de rede estável, mas se a rede estiver instável, ele não conseguirá escapar dessa ação e a IU o bloqueará efetivamente de fazer qualquer outra coisa. Evite solicitações de rede que bloqueiam conteúdo. Permita que o usuário continue navegando pelo app e enfileire tarefas que serão executadas e sincronizadas quando a conexão melhorar.
Demonstram o estado de uma ação fornecendo feedback aos usuários. Por exemplo, se um usuário estiver editando um documento, considere mudar o design do feedback para que ele seja visivelmente diferente de quando ele está on-line, mas ainda mostrar que o arquivo foi "salvo" e será sincronizado quando houver uma conexão de rede. Isso informa o usuário sobre os diferentes estados disponíveis e mostra que a tarefa ou ação foi armazenada. Outro benefício é que o usuário fica mais confiante usando o aplicativo.
Design para o próximo bilhão
Em muitas regiões, dispositivos mais simples são comuns, a conectividade não é confiável e, para muitos usuários, os dados são inacessíveis. Você precisará ganhar a confiança do usuário sendo transparente e frugal com dados. Pense em maneiras de ajudar usuários com conexões ruins e simplifique a interface para ajudar a acelerar as tarefas. Sempre tente perguntar aos usuários antes de fazer o download de conteúdo com muitos dados.
Ofereça opções de baixa largura de banda para usuários com conexões lentas. Portanto, se a conexão de rede estiver lenta, forneça recursos pequenos. Ofereça uma opção para escolher recursos de alta ou baixa qualidade.
Conclusão
A educação é fundamental para a UX off-line, porque os usuários não estão familiarizados com esses conceitos. Tente criar associações com coisas familiares, por exemplo, fazer o download para uso posterior é o mesmo que off-line dados.
Ao projetar para conexões de rede instáveis, lembre-se destas diretrizes:
- Projetar pensando no sucesso, na falha e na instabilidade de uma conexão de rede.
- Os dados podem ser caros, por isso seja atencioso com o usuário.
- Para a maioria dos usuários em todo o mundo, o ambiente tecnológico é quase que exclusivamente móvel.
- Dispositivos mais simples são comuns, com armazenamento, memória e capacidade de processamento limitados, além de telas pequenas e qualidade de tela touchscreen menor. Garantir que a performance faça parte do seu processo de design.
- Permita que os usuários naveguem no seu aplicativo quando estiverem off-line.
- Informe os usuários sobre o estado atual e as mudanças de estado.
- Tente fornecer off-line por padrão se o aplicativo não exigir muitos dados.
- Se o app tiver muitos dados, explique aos usuários como fazer o download para uso off-line.
- Torne as experiências transferíveis entre dispositivos.
- Usar linguagem, ícones, imagens, tipografia e cores juntas para expressar ideias ao usuário.
- Fornecer segurança e feedback para ajudar o usuário.