site-motion：Avaliação de Movimento do Site e Seleção de Versão
Quando o usuário diz que o site está "sem graça", o problema geralmente não é falta de animação, nem necessariamente carregamento lento, mas sim que cada ação exige sair e recomeçar, e a página é uma coleção de blocos não relacionados. Portanto, primeiro identifique o problema e depois decida o que animar.
Responda na linguagem do usuário. Mantenha termos técnicos no original.
Princípios
- Não mexa no código de produção antes da seleção: Primeiro, forneça diagnóstico, proposta e protótipo; só implemente após o usuário escolher explicitamente uma versão.
- Por padrão, não mexa no layout: Sem solicitação explícita, não altere cores, fontes ou layout; modifique apenas a interação. Mudar o estilo completo do site é outra questão.
- Mobile primeiro: Julgue e valide com base em 375px; desktop é um bônus.
- Movimento só conta se for clicável: Imagens estáticas não mostram a sensação; as versões devem ser protótipos funcionais.
- Movimento deve ter propósito: Cada animação deve responder a uma pergunta do usuário, como "Apertei?", "De onde vim?", "Os dados foram atualizados?". Se não responder, remova.
- Para sites que dependem de busca e anúncios, SEO e monetização vêm antes do exibicionismo: Animações não podem substituir URLs independentes, conteúdo HTML inicial ou visibilidade de anúncios. Backends e ferramentas internas após login não estão sujeitos a esta regra.
- Mudar conteúdo exige nova página; ajustar o mesmo conteúdo é no local: Ver outro artigo requer uma nova página, pois gera novas URLs e solicitações de anúncio; expandir, filtrar, ordenar é feito no local.
- Movimento não pode ultrapassar as linhas vermelhas do site: Primeiro, verifique as restrições normativas e de conformidade do projeto. Não use campos com valores ausentes para efeitos visuais, nem use animação para sugerir informações sem fundamento.
Fluxo
Passo 1: Identificar qual tipo de movimento ele quer
"Movimento" pode ser quatro coisas diferentes, com soluções completamente diferentes.
| Tipo | Possíveis Falas | O Que Realmente Fazer |
|---|---|---|
| Movimento de Dados | Conteúdo precisa se atualizar, ser em tempo real | cron, API, polling, principalmente trabalho de backend, combinado com sinal de atualização |
| Movimento de Feedback | Apertar não dá sensação, muito estático | Sensação de pressão, mudança de estado, flash de atualização |
| Movimento Contínuo | Parece pular página, muito primitivo, parece um monte de objetos | Transição de página, expansão no local, elemento compartilhado, gestos |
| Animação Narrativa | Home page precisa ter impacto, efeito de scroll, GSAP | Animação Hero, narrativa de scroll, momento de marca |
Quando for claramente movimento de dados, explique diretamente que não é um problema de animação e siga com a solução de dados. Nos demais casos, não pergunte de volta; vá direto para o Passo 2 e responda com observações reais.
Passo 2: Analisar a situação atual
Quando houver código-fonte do projeto, execute a partir do diretório raiz desta skill:
python3 scripts/motion_audit.py <diretório-do-projeto>
O resultado do script é uma pista, não um veredito; confirme cada item atingido um por um.
Quando puder abrir o navegador, percorra o caminho principal em 375px: home page, página interna, alternar abas, clicar em um item da lista, voltar. Anote as sensações reais:
- Quais ações recarregam a página inteira, quais são mudanças no local
- A página é uma entidade única ou um monte de blocos independentes
- O usuário vê ou não a atualização dos dados
- Há atraso no feedback? Há animação que atrapalha, por exemplo, números que pulam toda vez que entram na página
Quando não há site (site novo), ou o projeto é apenas um esqueleto sem páginas reais: Leia os documentos de planejamento, identifique o tipo de site, pule para o Passo 3 e explique que não é possível diagnosticar a tela real neste estágio.
Quando não se vê o site nem o código: Use as informações fornecidas pelo usuário para prosseguir, marque todos os "problemas" como inferência e liste os dados faltantes como "não verificado". Não invente observações.
Passo 3: Definir o tom com base no tipo de site
| Tipo de Site | Foco | Evitar |
|---|---|---|
| Sites de Dados e Ferramentas (placar, consulta, dashboard) | Movimento contínuo, sinal de atualização, densidade | Fade-in com scroll, animações que obstruem dados |
| Sites de Conteúdo e Artigos | Feedback leve, leitura sem interrupção | Qualquer efeito que atrapalhe a leitura ou empurre anúncios |
| Páginas de Marca e Marketing | Um momento narrativo cuidadoso | Animar tudo |
| Serviços estilo App | Gestos, operação no local, continuidade de estado | Só trocar a pele sem mudar a interação |
| Backend e Ferramentas Internas (após login) | Feedback, mudança de estado, redução de troca de página | Animações que atrasam operações repetitivas |
Passo 4: Planejar de 2 a 3 versões
Leia references/recipes.md para obter receitas de movimento e references/pitfalls.md para avaliar riscos.
Primeiro, passe pelo portão de navegação, que determina qual abordagem de troca de página pode ser proposta:
| Situação do Site | Abordagem de Navegação |
|---|---|
| Tem ou terá anúncios gráficos (ex.: AdSense) | Por padrão, use @view-transition entre documentos, mantenha a troca de página real, anúncios e análise de comportamento inalterados |
| Já tem anúncios automáticos, fixos, intersticiais, ou não é possível verificar o comportamento dos anúncios após a troca de página | Navegação suave no mesmo documento não é recomendada; se for listada, deve ser marcada como necessitando de teste real e ter um plano de fallback |
| Não tem anúncios, ou a abordagem de anúncios e análise foi verificada | Pode usar navegação suave no mesmo documento ou roteamento de framework; ainda é necessário verificar a análise e o estado de login após a troca de página |
Quando um site existente já usa navegação suave e está se preparando para adicionar anúncios, liste isso em "Onde está o problema", não como resolvido.
As versões devem ter diferenças substanciais, e devem ser diferenças no escopo da interação, não diferenças de cor. A escada sobe a partir da situação atual do site; itens já implementados não devem ser repetidos. Escada padrão:
- A Versão Leve de Toque: Não mexe na arquitetura de navegação, apenas adiciona feedback e sinal de atualização. Menor risco, pode ser concluída no mesmo dia.
- B Versão Contínua: A mais transições de página, elementos compartilhados, expansão no local. A abordagem de navegação depende do portão. Geralmente é a versão recomendada.
- C Versão Completa de Sensação de App: B mais gestos de deslize, troca de dados no local, notificações em tempo real, ou momentos narrativos para sites de marca. Maior sensação, maior custo e risco.
As versões devem passar pelo filtro do tipo de site do Passo 3: sites de conteúdo de artigo geralmente param em A ou B leve. Dê apenas duas versões se realmente houver diferença; não invente para completar. Se A já atende a todos os requisitos, diga isso diretamente. O custo da engenharia de animação deve ser proporcional à receita do site.
Passo 5: Criar um protótipo clicável
Siga references/prototype.md. Use dados reais e a aparência atual. Crie um arquivo onde seja possível alternar entre as versões. Teste em largura de celular antes de entregar. Pode começar com assets/prototype-template.html.
Passo 6: Proposta
Reporte seguindo a "estrutura de saída" abaixo e peça ao usuário para escolher a versão. Se o ambiente tiver ferramenta de seleção, use-a; caso contrário, liste opções numeradas, colocando a versão recomendada em primeiro lugar. O "não pergunte de volta" do Passo 1 se aplica apenas à fase de diagnóstico; aqui, pare e aguarde a escolha.
Passo 7: Implementação e Aceitação
Comece somente após o usuário escolher. Siga a ordem de references/acceptance.md para implementar e passar pela aceitação. Ao passar para outro agente, use o modelo de transferência desse arquivo.
Estrutura de Saída
A proposta usa esta estrutura fixa, curta e específica:
## Avaliação de Movimento: <Nome do Site>
**Onde está o problema**
<2 a 4 itens, cada um é um fenômeno observado, com a localização na página. Não fale de forma genérica como "falta de interação".>
**Comparação de Versões**
| | A Leve Toque | B Contínua | C Completa App |
|---|---|---|---|
| O que o usuário sentirá | | | |
| Principais mudanças | | | |
| Esforço | Número de arquivos e tempo aproximado | | |
| Risco de SEO e CWV | Baixo/Médio/Alto, com uma frase de motivo | | |
| Impacto em Anúncios e Análise | Escreva a abordagem de navegação e premissas | | |
| Custo de manutenção | | | |
**Recomendação**: <Qual escolher, com uma frase de motivo; se houver premissa, escreva-a>
**Protótipo**: <Link ou caminho, e liste 3 a 5 ações para testar>
**Mudanças de Layout**: <Itens que precisam de aprovação do usuário; se não houver, escreva "Nenhuma">
**Não Proposto**: <Itens solicitados pelo usuário mas não feitos desta vez, com motivo; omita se não houver>
**Não será alterado**: <Layout, cores, URLs, linhas vermelhas de SEO, etc.>
**Não Verificado**: <Itens não testados, como comportamento real de anúncios, sensação em dispositivo real>
Ao dar apenas duas versões, remova as colunas não utilizadas da tabela. O esforço deve ser um número real, por exemplo "modificar 4 a 5 arquivos"; o risco deve ser explicado claramente, não apenas "baixo". Indique se o número é medido ou estimado. Quando a solicitação do usuário for bloqueada por uma condição, explique onde e em que condições pode ser retomada, e ofereça uma alternativa. A versão recomendada deve basear-se no portão e nas condições de desempenho, não necessariamente na B.
Arquivos de Referência
| Arquivo | Quando Ler |
|---|---|
| references/recipes.md | Passo 4, escolher efeitos e parâmetros |
| references/pitfalls.md | Passo 4 para avaliar risco, Passo 7 ao implementar |
| references/prototype.md | Passo 5 |
| references/acceptance.md | Passo 7, incluindo modelo de transferência |
| assets/prototype-template.html | Template inicial para criar protótipos |