Um guia para projetar experiências da Web para redes lentas e off-line.
Neste artigo, apresentamos 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.
- Quedas 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 negado em horários ou dias específicos
Seu objetivo é oferecer uma boa experiência que diminua o impacto das mudanças na conectividade.
Decida o que mostrar aos seus 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 seu app. No entanto, a falha de uma conexão pode ser o estado off-line do app e o comportamento dele quando há uma rede lenta.
Ao pensar sobre o sucesso ou a falha de uma conexão de rede, você precisa se fazer estas perguntas importantes de UX:
- Quanto tempo você espera para determinar o sucesso ou a falha de uma conexão?
- O que você pode fazer enquanto o sucesso ou o fracasso está sendo determinado?
- O que você deve fazer em caso de falha?
- Como você informa o usuário sobre essas questões?
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 se houver uma falha de rede e sobre o estado atual do aplicativo. Por exemplo, uma notificação pode 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 melhorar ou for restaurada
A forma como você informa ao usuário que a conexão de rede melhorou depende do 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 seu 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 detectar a presença de um service worker e uma atualização do conteúdo gerenciado. Veja um exemplo de código dessa função em ação (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 sempre em um espaço de destaque a última vez que o app foi atualizado. 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 de tocar para atualizar informando ao usuário sobre novos conteúdos. A atualização automática faria com que os usuários se perdessem.
Atualizar a interface para refletir o estado contextual atual
Cada parte da interface pode ter o próprio contexto e funcionalidade, que mudam dependendo se a conexão é estabelecida. Um exemplo seria um site de comércio eletrônico que pode ser navegado 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 notificar quando o mercado estiver aberto. Toda a interface fica branca e depois esmaece quando o mercado fecha. Quando o valor da ação aumenta ou diminui, cada widget de ações individual fica verde ou vermelho, dependendo do estado.
Ensinar o usuário a entender qual é 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 configurações para alterar o comportamento padrão. Use vários componentes de design da interface, 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, para contar toda a história.
Oferecer uma experiência off-line por padrão
Se o app não exigir muitos dados, armazene-os em cache por padrão. Os usuários podem ficar cada vez mais frustrados se só puderem 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 pareça não confiável, em que 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 do download automático e do salvamento automático das notícias mais recentes para que o usuário possa 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 exibida normalmente, defina esse download como prioritário.
Informar o usuário quando o app está pronto para consumo off-line
Quando um app da Web é carregado pela primeira vez, é preciso indicar ao usuário se ele está pronto para uso off-line. Faça isso com um widget que fornece feedback rápido sobre uma operação com uma mensagem na parte de baixo da tela, como 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 ao seu público. Verifique se a mensagem é a mesma em todas as instâncias em que é usada. O termo off-line geralmente é mal interpretado por um público não técnico, portanto, use uma linguagem baseada em ações com que seu público se identifique.
Use "Salvar para off-line" em uma parte óbvia da interface para apps com uso intenso de dados
Se um app usar grandes quantidades de dados, verifique se há uma chave ou um 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 interface de fixação ou de download não é obscurecida por outros elementos da interface e se o recurso é óbvio para o usuário.
Um exemplo seria um reprodutor de música que exige 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 deixe claro onde os dados serão armazenados e quem tem acesso a eles.
Mostrar o custo real de uma ação
Muitos usuários equilibram a capacidade off-line com o "download". Os usuários em países em que as conexões de rede falham regularmente ou não estão disponíveis geralmente 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 receio do custo. Por isso, você também pode exibir um custo associado para que os usuários possam fazer uma comparação ativa de um arquivo ou tarefa específica. 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 conferir o custo de um arquivo.
Evitar experiências invadidas
Muitas vezes, os usuários invadem uma experiência sem perceber. Por exemplo, antes dos apps da Web de compartilhamento de arquivos baseados na nuvem, era comum que os usuários salvassem arquivos grandes e os anexassem a e-mails para continuar a edição em um dispositivo diferente. É importante não se envolver com a experiência de invasão, mas observar o que o usuário está tentando conseguir. Em outras palavras, em vez de pensar em como você pode anexar um arquivo grande para facilitar o uso, resolva o problema de compartilhar arquivos grandes em vários dispositivos.
Torne as experiências transferíveis de um dispositivo para outro
Ao criar para 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 uma conexão de rede no meio de uma reserva. Quando a conexão é restabelecida, o app é sincronizado com a conta do usuário, permitindo que ele continue a reserva no dispositivo desktop. Não ser capaz de transferir experiências pode ser incrivelmente perturbador para os usuários.
Informe o usuário sobre o estado atual dos dados. Por exemplo, você pode mostrar se o app foi sincronizado. Ensine-os sempre que possível, mas tente não sobrecarregá-los com mensagens.
Criar experiências de design inclusivas
O design precisa ser inclusivo, oferecendo 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.
Use uma linguagem simples e concisa
Uma boa UX não se resume a uma interface bem projetada. Isso inclui o caminho que um usuário segue, bem como as palavras usadas no app. Evite jargões tecnológicos ao explicar o estado do app ou os componentes individuais da interface. 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 de usuário acessíveis
Use linguagem, cores e componentes visuais para demonstrar uma mudança de estado ou de status atual. O uso exclusivo de cores para demonstrar o estado pode não ser percebido pelo usuário e pode não ser acessível para usuários com deficiência visual. Além disso, o instinto para os designers é usar a IU esmaecida para representar off-line, mas isso pode ter um significado maior na Web. A interface esmaecida, como elementos de entrada em um formulário, também significa que um elemento está desativado. Isso pode causar confusão se você usar apenas a cor para representar 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 interface.
Usar ícones que transmitem significados
Certifique-se de que as informações sejam transmitidas corretamente com marcadores de texto significativos e ícones. Só os ícones podem ser problemáticos, já que o conceito de off-line na Web é relativamente novo. Os usuários podem entender 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 se confundir com a metáfora. Da mesma forma, o ícone de menu de hambúrguer pode 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, 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, os dados de salvamento ou download seriam baseados em ações.
O 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.
Usar layouts de esqueleto com outros mecanismos de feedback
Um layout esqueleto é essencialmente uma versão em wireframe do app que é exibida enquanto o conteúdo está sendo carregado. Isso ajuda a demonstrar ao usuário que o conteúdo está prestes a ser carregado. Considere também usar uma interface 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 a sensação de que o app está vivo 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 iniciar uma ação, como a criação de um novo documento. Alguns apps vão tentar 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 se o usuário tiver uma conexão de rede estável. No entanto, se a rede for instável, ele não conseguirá escapar dessa ação e a interface o bloqueará efetivamente de fazer qualquer outra coisa. As solicitações de rede que bloqueiam conteúdo precisam ser evitadas. Permita que o usuário continue navegando no app e enfileire tarefas que serão realizadas e sincronizadas quando a conexão melhorar.
Para demonstrar o estado de uma ação, forneça 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 mostre 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 garante que a tarefa ou ação foi armazenada. Outro benefício é que o usuário ficará mais confiante para usar o aplicativo.
Design voltado ao próximo bilhão
Em muitas regiões, dispositivos simples são comuns, a conectividade não é confiável e, para muitos usuários, os dados são inacessíveis. Você precisará conquistar a confiança dos usuários sendo transparente e frugal com os 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. Se a conexão de rede for 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 experiência do usuário 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 salvar dados off-line.
Ao projetar para conexões de rede instáveis, siga estas diretrizes:
- Projeto para o sucesso, falha e instabilidade de uma conexão de rede.
- Os dados podem ser caros, por isso, considere o usuário.
- Para a maioria dos usuários do 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 inferior de tela touchscreen. Garanta que o desempenho faça parte do seu processo de design.
- Permita que os usuários naveguem pelo seu aplicativo quando estiverem off-line.
- Informe os usuários sobre o estado atual e as mudanças de estado.
- Tente oferecer o acesso off-line por padrão se o aplicativo não precisar de 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.
- Use linguagem, ícones, imagens, tipografia e cores para expressar ideias para o usuário.
- Forneça tranquilidade e feedback para ajudar o usuário.