Estados de animação do mascote: carregamento, sucesso, erro

Quais estados de mascote cobrem a maioria dos momentos do app?

Comece pelos eventos do seu app, não por uma lista de animações fofas. Esta tabela cobre o que a maioria dos apps precisa:

Duas regras deixam isso fácil de gerenciar. Só um loop fica ativo por vez. Reações únicas tocam sobre o loop atual e devolvem o controle a ele quando terminam. É exatamente assim que uma state machine do Rive costuma ser configurada: um número ou enum escolhe o loop, e triggers disparam as reações.

Antes de adicionar um estado, pergunte onde ele vai aparecer e o que o dispara. Se você não conseguir apontar uma tela e um evento, deixe-o de fora. Também vale listar quais telas nunca devem mostrar o mascote, como configurações, formulários de checkout e qualquer lugar em que o usuário precise se concentrar. Um personagem no lugar errado consome mais atenção do que traz de retorno.

Quando o mascote deve mostrar loading e quando deve mostrar thinking?

Use loading para esperas mecânicas: chamadas de rede, uploads, salvamento. Use thinking quando o produto estiver fazendo algo que pareça trabalho em nome do usuário, como gerar texto, analisar uma foto ou planejar uma rota. A diferença está no tom. Thinking sugere que uma resposta está a caminho.

O tempo importa mais do que a animação em si. A orientação do Nielsen Norman Group sobre indicadores de progresso:

• Menos de cerca de 1 segundo: não mostre indicador. Um lampejo de animação parece falha.
• Entre cerca de 2 e 10 segundos: um indicador em loop, que é onde um mascote de loading ou thinking se encaixa.
• Mais de 10 segundos: um indicador de porcentagem concluída ou de etapas, porque um loop sozinho deixa de tranquilizar as pessoas.

(NN/g, indicadores de progresso). Na prática, inicie o estado de loading após um pequeno atraso, para que respostas rápidas nunca o disparem. Em tarefas longas, mantenha o mascote, mas adicione uma barra de progresso ou uma linha de status ao lado dele.

Para orientações mais detalhadas sobre tempo, veja duração de animação e UX de carregamento.

Como devem ser as reações únicas de success e error?

Reações únicas devem ser curtas e inconfundíveis. O usuário acabou de fazer algo e quer uma confirmação, não um espetáculo.

• Success: um pulinho rápido, um aceno de cabeça ou uma pequena comemoração. Mantenha a proporção. Salvar um rascunho merece um aceno; completar uma sequência de 30 dias pode ganhar mais.
• Error: empático, não cômico. Uma careta ou um dar de ombros funciona. Nunca faça o mascote parecer estar rindo do usuário. Sempre combine a reação com uma mensagem de texto que diga o que deu errado e o que fazer.
• Yes / no: um aceno ou um balançar de cabeça para confirmações, quizzes e escolhas.

Mantenha as reações breves. As diretrizes de movimento do Material Design situam as transições típicas no mobile em torno de 300 ms e observam que durações acima de 400 ms podem parecer lentas (Material Design). A reação de um personagem pode durar mais que uma transição de interface, porque transmite emoção, mas deve terminar bem antes de o usuário acabar de ler o resultado.

Não bloqueie a interface enquanto uma reação única toca. O usuário deve poder tocar no próximo botão imediatamente. Quando a reação termina, o mascote volta ao loop que estava ativo, geralmente o idle.

O que o mascote deve fazer em estados vazios e no onboarding?

Estados vazios são o lugar mais comum em que um mascote é realmente útil. Uma caixa de entrada vazia ou uma tela de "nenhum resultado" é um momento vazio, e um personagem tranquilo preenche esse espaço sem gerar ruído. Boas opções:

• Um loop sleeping ou um idle lento para "nada por aqui ainda".
• Uma pose thinking para "nenhum resultado", ao lado de sugestões para uma nova busca.
• Uma pose apontando ou de attention, voltada para o botão que resolve o estado vazio, como "Adicione seu primeiro projeto".

No onboarding, funciona bem uma reação única de enter ou wave na primeira tela, seguida de idle. Evite repetir a saudação em cada tela do fluxo. Uma vez é boas-vindas; cinco vezes é atraso. Se o mascote aparecer em cada etapa, use reações pequenas (um aceno quando uma etapa é concluída) em vez de repetir a entrada.

Quando o usuário sai do fluxo, uma reação única de exit pode tirar o personagem da tela de forma limpa, em vez de cortá-lo no meio de uma pose.

Quando um mascote deve chamar a atenção?

Um loop de attention é o estado mais poderoso e o mais fácil de usar em excesso. Reserve-o para algo que o usuário realmente gostaria de saber: uma nova mensagem, uma recompensa pronta para resgatar, uma etapa que ele ainda não concluiu.

Diretrizes:

• Vincule-o a um sinal real e visível, como um selo ou banner. O mascote reforça o sinal; ele não é o único sinal.
• Pare o loop assim que o usuário abrir ou dispensar o item.
• Não acumule attention com outros movimentos na mesma tela.
• Limite quanto tempo ele roda. Depois de alguns ciclos, volte ao idle e mantenha o selo no lugar.

Nunca use attention em loop para empurrar upsells. Os usuários aprendem rápido a ignorar um personagem que sempre quer alguma coisa, e isso também enfraquece o estado para os momentos que importam.

Como conecto os estados do mascote aos eventos do app?

Mantenha uma única função pequena que traduz o estado do app em estado do mascote. O resto do seu código nunca conversa diretamente com a animação.

// mood numbers: 0 idle, 5 loading, 8 sleeping, 9 attention
function mascotMood(app) {
  if (app.isLoading && app.elapsedMs > 800) return 5;
  if (app.unread > 0) return 9;
  if (app.items.length === 0) return 8;
  return 0;
}

// one-shots are triggers, fired on events
onSaveSucceeded(() => mascot.fire("success"));
onSaveFailed(() => mascot.fire("error"));

No Rive, o loop costuma ser selecionado com um input numérico e as reações com inputs do tipo trigger. Com a API legada de inputs, você define o value de um input numérico e chama fire() em um trigger (documentação do Rive). Hoje o Rive recomenda Data Binding (view models) para trabalhos novos; arquivos existentes baseados em inputs continuam funcionando (guia de migração do Rive).

Os arquivos Rive do Charmotion seguem esse padrão: um número mood de 0 a 9 escolhe um de dez loops, e success, error, yes, no, enter e exit são triggers que voltam ao humor atual ao terminar. Veja state machines do Rive para código por framework.

Como evito que o movimento do mascote incomode os usuários?

Um mascote que nunca para de se mexer é, na melhor das hipóteses, ignorado e, na pior, uma distração. Incorpore moderação desde o início:

• Respeite o movimento reduzido. Na web, verifique prefers-reduced-motion: reduce (MDN). No SwiftUI, leia accessibilityReduceMotion. Mostre uma pose estática em vez de loops.
• Ofereça pausar ou parar. O critério de sucesso 2.2.2 da WCAG 2.2 exige uma forma de pausar, parar ou ocultar movimento que começa automaticamente, dura mais de cinco segundos e aparece junto com outro conteúdo, a menos que seja essencial (W3C). Uma animação de carregamento durante a qual não é possível fazer nada pode ser considerada essencial.
• Deixe-o descansar. Depois de um período sem interação, assuma uma pose parada. State machines do Rive podem se estabilizar e parar de avançar quando nada muda, o que também economiza bateria (documentação do Rive).
• Sem piscar. Nada deve piscar mais de três vezes por segundo.
• Um personagem por tela. Dois mascotes animados disputam a atenção.
• Cuidado com a repetição. Uma reação de success que encanta na primeira vez pode irritar na quinquagésima. Para ações que os usuários repetem o tempo todo, use uma reação menor ou nenhuma.

Mais detalhes em animação acessível e movimento reduzido.

Perguntas frequentes

De quais estados de animação um mascote de app precisa?

A maioria dos apps precisa primeiro de idle, loading, success e error. Depois, adicione um loop para o estado vazio, como sleeping, uma saudação para o onboarding e um loop de attention para notificações. Recursos de chat e voz também precisam dos estados listening, thinking e talking. Adicione cada um apenas onde ele corresponder a um evento real.

Qual é a diferença entre um loop e uma reação única?

Um loop se repete enquanto uma condição for verdadeira, como loading enquanto uma requisição está em andamento. Uma reação única toca uma vez em resposta a um evento, como success depois de salvar, e então devolve o controle ao loop que estava ativo antes de ela começar.

Devo mostrar uma animação de carregamento em requisições rápidas?

Não. O Nielsen Norman Group recomenda não exibir nenhum indicador em esperas de menos de cerca de um segundo, porque um lampejo rápido de animação parece uma falha. Atrase um pouco o estado de loading para que respostas rápidas nunca o mostrem, e adicione uma barra de progresso em esperas de mais de dez segundos.

Um mascote animado precisa de um botão de pausa?

Muitas vezes, sim. Pelo WCAG 2.2 SC 2.2.2, um movimento que começa automaticamente, dura mais de cinco segundos e aparece ao lado de outro conteúdo precisa de uma opção de pausar, parar ou ocultar, a menos que seja essencial. Fazer o personagem parar em uma pose estática depois de alguns segundos também evita o problema.

Respostas rápidas deste guia

• Quais estados um mascote de app deve ter?
• Qual é a diferença entre uma animação em loop e uma reação única?
• O que um conjunto de animações do Charmotion inclui?

Fontes

• Progress Indicators Make a Slow System Less Insufferable, Nielsen Norman Group
• Duration & easing, Material Design
• Understanding SC 2.2.2: Pause, Stop, Hide, W3C WAI
• prefers-reduced-motion, MDN Web Docs
• accessibilityReduceMotion, Apple Developer Documentation
• State Machines (web runtime), Rive
• Inputs (web runtime), Rive
• Data Binding migration guide, Rive