Estados de carregamento e vazio: onde a interface mente

Estado de carregamento e estado vazio são o que a pessoa vê enquanto o dado não chegou ou não existe. Eles não são enfeite. É ali que a interface mais engana, porque o marcador pode prometer uma forma que nunca chega e o giro pode sugerir um progresso que ninguém mediu.

Por que a espera precisa de sinal, e quando o sinal atrapalha

O Carbon Design System (em inglês), da IBM, afirma que as estratégias de carregamento avisam a pessoa de que a requisição está em andamento. Segundo ele, esqueletos e outros indicadores podem criar a ilusão de tempo menor. O mesmo padrão de carregamento (em inglês) limita o esqueleto a poucos segundos na tela.

O sinal se justifica quando a espera é longa o bastante para ser notada. Os limites de tempo de resposta do Nielsen Norman Group (em inglês) situam esse ponto em um décimo de segundo, abaixo do qual nenhum retorno especial é necessário. Abaixo disso, o indicador aparece e desaparece dentro de alguns quadros, e o movimento vira piscada em vez de informação. O Nielsen Norman Group registra no texto Skeleton Screens 101 (em inglês) que esqueleto animado pode distrair ou incomodar, e criar problema de acessibilidade para parte das pessoas.

O padrão de carregamento do Carbon (em inglês) separa os casos pelo que dá para saber. O indicador de carregamento sinaliza que algo está carregando e, ao contrário da barra de progresso, não informa quanto falta. A barra de progresso é o controle certo quando o sistema consegue medir o trabalho restante.

Então a espera curta não recebe sinal, a espera desconhecida recebe indicador, e a espera mensurável recebe barra. Espera medida em minutos também pede uma estimativa de quando termina, segundo a orientação do Nielsen Norman Group sobre indicadores de progresso (em inglês).

Esqueleto contra indicador: o que cada um promete

O esqueleto é uma versão simplificada do componente que vai substituí-lo. O Nielsen Norman Group (em inglês) descreve um wireframe que imita o layout da página e ajuda a pessoa a montar um modelo mental do que vem. O mesmo texto limita o esqueleto a carregamento de página inteira, enquanto o padrão do Carbon (em inglês) o limita ao componente.

O indicador promete só que algo acontece. O esqueleto promete forma, hierarquia e ordem. Quando o conteúdo real chega em outra forma, a troca move elementos que a pessoa já havia localizado, e esse movimento é lido como defeito.

O padrão de carregamento do Carbon (em inglês) restringe o lugar do esqueleto. Ele cabe em componente de container, como bloco e lista estruturada, e em componente de dado, como tabela e cartão. Componente de ação, como botão, campo, caixa de seleção e alternador, não precisa de esqueleto. Toast, menu de overflow, item de lista suspensa, modal e loader não devem ser representados por esqueleto.

O que o esqueleto faz com o deslocamento de layout

O Google define Cumulative Layout Shift como a maior rajada de pontuações de deslocamento durante a vida da página, medida no percentil 75 e separada entre celular e desktop. Pontuação boa é 0,1 ou menos, e ruim passa de 0,25.

A rajada, chamada janela de sessão, agrupa deslocamentos que ocorrem com menos de um segundo de intervalo, com janela máxima de cinco segundos. O Google lista como causas comuns imagem ou vídeo sem dimensão declarada, fonte que renderiza em tamanho diferente do fallback e widget de terceiro que se redimensiona sozinho.

O esqueleto acrescenta um deslocamento quando a caixa dele não bate com a caixa do elemento que o substitui. A correção é de conta, não de estética. Marcador e elemento final compartilham largura, altura e posição, então a troca substitui pixels em vez de mover pixels.

O mesmo artigo do Google sobre deslocamento avisa que o problema se esconde no desenvolvimento. Ali a imagem de teste já está no cache do navegador, e a chamada local responde mais rápido que a de produção. Deslocamento que nunca aparece na máquina do dev é normal no celular.

A consequência é concreta. O artigo do Google registra que um deslocamento súbito pode fazer a pessoa clicar no link ou botão errado, e levar alguém a confirmar um pedido que pretendia cancelar.

Os quatro estados, e os dois que ficam de fora

Carregando, vazio, erro e sucesso são quatro estados com quatro funções. A maioria dos times desenha o sucesso e o giro de carregamento, e deixa vazio e erro com o que o framework renderiza por padrão. O Nielsen Norman Group (em inglês) registra que o padrão de um espaço vazio é simplesmente continuar vazio.

Vazio não é erro, e essa é a confusão mais comum. Vazio significa que a requisição deu certo e voltou sem nada. Erro significa que a requisição não deu certo. O tratamento muda no texto e na ação oferecida.

O padrão de estado vazio do Carbon (em inglês) nomeia três famílias de estado vazio. Sem dado cobre o primeiro uso. Ação da pessoa cobre busca sem resultado e confirmação de processo concluído. Gestão de erro cobre permissão, falha de sistema e configuração faltando.

Sucesso também é estado. Depois que a ação termina, a interface confirma, ou a pessoa repete a ação para checar se funcionou.

O que o leitor de tela anuncia em cada estado

A especificação WAI-ARIA 1.2 (em inglês), do W3C, define aria-busy como o sinal de que um elemento está sendo modificado. As tecnologias assistivas podem esperar o fim da mudança antes de expor o conteúdo. Esse é o mecanismo para o container que vai ser substituído pelo dado.

Para texto que aparece sem recarregar a página, a especificação define aria-live como a indicação de que um elemento será atualizado. O valor descreve quais atualizações os agentes de usuário e as tecnologias assistivas podem esperar.

Com o valor polite, a especificação (em inglês) diz que as tecnologias assistivas devem anunciar na próxima oportunidade tranquila, como o fim da frase atual ou uma pausa na digitação. Com o valor assertive, devem avisar na hora.

A especificação acrescenta que a interrupção pode desorientar a pessoa, então assertive pertence ao erro que trava a tarefa e não à atualização de rotina.

O papel alert carrega valor live assertive implícito e valor atomic implícito igual a true, segundo a especificação. O atomic decide se a região inteira é lida ou só o nó que mudou. O W3C publica as WAI-ARIA Authoring Practices (em inglês) como os padrões construídos sobre essa especificação.

O padrão de carregamento do Carbon (em inglês) resume o requisito de acessibilidade em uma linha. O leitor de tela deve avisar a pessoa quando a aplicação está carregando, ocupada, travada ou falhou.

Anunciar demais é a outra falha. Região polite que re-renderiza dez vezes enfileira dez mensagens que a pessoa não consegue parar. Rajada assertive perde as mensagens anteriores, porque a especificação (em inglês) permite ao agente limpar a fila quando chega uma mudança assertive.

Estado vazio é texto estático e é anunciado quando o leitor chega nele. Se ele aparece depois de uma busca, precisa de região viva ou de movimento de foco, senão a pessoa não ouve nada e espera um resultado que não vem.

Como construir o estado vazio com ação

A anatomia do Carbon (em inglês) para estado vazio lista imagem opcional não interativa, título curto, corpo que explica a próxima ação, ação primária e link secundário opcional.

O mesmo padrão de estado vazio (em inglês) recomenda escrever o título como afirmação positiva. O exemplo dado é que “Comece adicionando ativos de dados” soa melhor que “Você não tem nenhum ativo de dados”. O padrão avisa ainda que estado vazio costuma ser tratado como detalhe final e que conteúdo extra tem custo cognitivo.

No primeiro uso, a ação cria o primeiro registro. Na busca sem resultado, a ação afrouxa o filtro, e o texto nomeia qual filtro mudar. No erro, a ação primária tenta de novo e a secundária reporta.

Mensagem sem ação deixa a pessoa num beco sem saída. O estado está pronto quando a pessoa sabe o que aconteceu e tem um controle que muda a situação.

Como verificar antes de publicar

• Limite a conexão e observe o estado de carregamento aparecer. Se durar menos de um quadro, remova.
• Abra uma conta nova para o estado vazio, e rode uma busca que não retorna nada para o estado sem resultado.
• Bloqueie a requisição ou devolva um 500 para forçar o erro, e confirme que a nova tentativa funciona.
• Compare a caixa do esqueleto com a caixa do elemento final. Dimensão diferente significa deslocamento já agendado.
• Meça o CLS em campo, no percentil 75, porque o Google documenta que dado de laboratório e de campo divergem.
• Rode um leitor de tela em cada estado e conte as mensagens. Mais de uma mensagem por ação significa região faladeira demais.
• Alcance cada ação só com o teclado, e confirme que o foco para em lugar útil depois da mudança de estado.
• Confirme que o erro aparece depois de um tempo limite que a pessoa tolera, e não de um que parece travamento.

Um estado que só avisa que não tem dado deixa a pessoa parada, sem saber o que fazer. Nomeie os quatro estados, dê a cada um uma mensagem e uma ação, e verifique os dois com a rede limitada e o leitor ligado.