Animação na interface: quando ajuda e como reduzir movimento

Anime um elemento quando o movimento explica algo: que a ação foi recebida, que a tela mudou de estado ou para onde a pessoa foi. A maior parte das transições cabe entre 100 e 400 milissegundos (NN/g, Executing UX Animations (em inglês)). Quem ativou a opção de reduzir movimento no sistema deve ver a página sem deslizes, e o CSS detecta esse pedido com prefers-reduced-motion.

Para que a animação serve

O olho humano é muito sensível a movimento, principalmente no canto da visão. Isso é a força e o risco da animação. Um artigo do NN/g de 2020 separa os usos em que essa atenção roubada vale a pena (NN/g, The Role of Animation and Motion in UX (em inglês)):

Retorno da ação. Um menu que desliza depois do toque confirma que o toque funcionou.
Mudança de estado. Um lápis que se transforma num disquete mostra a passagem de editar para salvar.
Noção de lugar. Aproximar e afastar ajuda a entender se você desceu ou subiu num nível de conteúdo.
Pista de uso. Um painel que sobe de baixo sugere que ele fecha puxando para baixo.

O mesmo artigo traz um caso de loja em que faltou animação. O número do carrinho muda sozinho, pequeno e longe do botão de comprar. A pessoa não vê a mudança e pode acabar pondo o mesmo produto duas vezes.

O retorno precisa chegar rápido para parecer consequência do clique. Um texto do NN/g de 2014 coloca esse limite em 0,1 segundo entre a ação e o começo do efeito (NN/g, Animation for Attention and Comprehension (em inglês)).

Quando ela atrapalha

Movimento sem função vira distração. O artigo de 2020 dá o exemplo de um rabisco que se mexe ao lado do texto sem acrescentar nada, e de um relógio piscando que anuncia o fim de uma promoção falsa. O segundo caso já é manipulação, porque usa o medo de perder para empurrar a compra (NN/g (em inglês)).

A repetição também cobra. Nos testes do NN/g, uma queixa comum é que a animação foi bonita na primeira vez e irritante a partir da segunda (NN/g (em inglês)). O exemplo do texto é um menu escondido que só aparece no fim de uma sequência longa, tocada de novo a cada uso, sem jeito de pular.

O tipo de movimento muda o quanto ele chama atenção. Um elemento que entra deslizando puxa o olho mais rápido do que um que só aparece aos poucos, sem trocar de lugar (NN/g (em inglês)). Para algo que a pessoa precisa notar já, o deslize serve. Para um recurso de apoio, o aparecer suave incomoda menos.

Quanto tempo ela deve durar

O artigo do NN/g sobre execução dá as faixas de referência (NN/g, Executing UX Animations (em inglês)):

Cerca de 100 ms para um retorno simples, como marcar uma caixa ou virar um interruptor.
De 200 a 300 ms para uma mudança grande na tela, como uma janela que entra.
400 ms já é lento, aceitável só para movimentos longos em telas grandes.
A partir de 500 ms, a animação passa a parecer espera.

Duas regras completam a tabela no mesmo texto. Sair pode ser um pouco mais rápido do que entrar, e quanto mais vezes a animação aparece, mais curta ela deve ser. A curva mais usada é a que começa rápida e freia no fim, chamada de ease-out, porque o olho consegue prever onde o elemento vai parar.

Para o arrastar e soltar, o mesmo princípio aparece numa animação curta que mostra onde o item vai cair, como conto no texto sobre arrastar e soltar.

Quem pede menos movimento

Para algumas pessoas, movimento na tela não é questão de gosto. Quem tem distúrbio vestibular, ligado ao equilíbrio e ao ouvido interno, pode sentir tontura, enjoo e enxaqueca. Às vezes precisa até deitar para se recuperar (W3C, Understanding 2.3.3 (em inglês)). Efeitos de paralaxe, em que o fundo corre numa velocidade diferente da frente, estão entre os gatilhos citados.

Os sistemas operacionais têm uma opção para isso, que no iPhone, no Android, no Windows e no macOS fica nos ajustes de acessibilidade. O navegador repassa essa escolha ao site pela consulta de mídia prefers-reduced-motion, que funciona em todos os navegadores principais desde janeiro de 2020 (MDN, prefers-reduced-motion (em inglês)).

O valor reduce diz que a pessoa quer menos movimento, de preferência sem nenhum que não seja necessário (web.dev, prefers-reduced-motion). O guia mostra dois cuidados que costumam passar batido:

Animação feita em JavaScript precisa ouvir a mudança. O CSS reage sozinho quando a pessoa troca a opção, mas o script tem de conferir de novo ou escutar o evento de mudança.
Imagem animada também conta. Com <picture> e o atributo media, o navegador mostra a versão parada para quem pediu menos movimento.

As diretrizes de acessibilidade do W3C tratam o tema no critério 2.3.3, de nível AAA, o mais exigente. Animação de movimento disparada por interação precisa poder ser desligada, a não ser que seja essencial (W3C, WCAG 2.2, tradução autorizada). Movimento que começa sozinho e dura mais de cinco segundos cai em outro critério, o 2.2.2, que expliquei no texto sobre carrossel no e-commerce.

O que o navegador anima sem esforço

Nem toda propriedade custa o mesmo para animar. O guia do web.dev pede que a animação fique, sempre que der, em transform e opacity (web.dev, animações CSS de alto desempenho). Mover com top e left, ou mudar largura e altura, obriga o navegador a recalcular o layout e redesenhar a página a cada quadro.

O mesmo guia trata o will-change como último recurso. Ele força o elemento para uma camada própria, o que pode criar outros problemas, então só entra quando um travamento real aparece.

Como fiz no kahue.net

Nas páginas do site, os blocos abaixo da dobra entram com um deslize de 14 pixels e um esmaecer, em 420 ms. A curva é do tipo que freia no fim, e só transform e opacity mudam. O topo da página fica parado de propósito. Ele é a primeira coisa que aparece, e animar o que já estava na tela só atrasaria a leitura.

Quando vários itens entram juntos, cada um começa 70 ms depois do anterior, mas o atraso para no terceiro. Daí em diante, esperar não acrescenta nada para quem já decidiu ler.

A animação é uma camada por cima, e não uma condição. Sem JavaScript, nenhuma regra de movimento vale, e o conteúdo aparece inteiro e no lugar. Quem pula blocos com um link de âncora ou com a tecla End também não encontra espaço vazio, porque todo bloco que ficou para trás é revelado.

O pedido de menos movimento é resolvido no CSS, e não no script, para valer mesmo se o script falhar. Com ele ligado, os blocos já aparecem no lugar, a rolagem suave vira rolagem direta e nenhuma transição roda. Na galeria de telas dos cases, a troca de imagem desliza em 180 ms, e o código confere a preferência a cada troca. Se a pessoa liga a opção com a galeria aberta, a próxima imagem já aparece sem deslize.

Onde as fontes divergem

O primeiro ponto é a duração para movimento que a pessoa não disparou. O texto do NN/g de 2020 trata 400 ms como muito lento (NN/g (em inglês)). O de 2014 aceita transições mais lentas, com pouco deslocamento, quando a animação vem da rolagem ou do carregamento (NN/g (em inglês)). Os 420 ms do kahue.net passam do teto de 2020 e cabem na regra de 2014.

O segundo é o que fazer com o pedido de menos movimento. O artigo do NN/g de 2020 fala em remover as animações (NN/g (em inglês)). A definição do W3C, porém, não conta mudança de cor nem de opacidade como animação de movimento (W3C, definição de animação de movimento). O MDN fala em remover, reduzir ou trocar o movimento (MDN (em inglês)). Pela régua do W3C, um esmaecer sem deslize continuaria permitido.

O kahue.net escolheu o lado mais restritivo. A regra geral desliga toda transição, inclusive as de cor, o que vai além do que o critério pede.

O erro comum: esconder o conteúdo até a animação rodar

Muito site começa com os blocos invisíveis no CSS e confia que um script vai mostrá-los na hora certa. Se o script atrasa, falha ou é bloqueado, o texto nunca aparece. A animação, que deveria ser enfeite, passa a decidir se a pessoa lê ou não.

A saída é inverter a ordem. A página nasce completa, e o estado escondido só entra depois que o script confirma que está rodando. Quem pediu menos movimento, quem navega sem script e o robô de busca recebem o mesmo conteúdo.