site-motion: Evaluación y planificación de animaciones en sitio…

site-motion: Evaluación y planificación de animaciones en sitios web

Cuando un usuario dice que un sitio es "rígido", el problema no suele ser la falta de animación, ni necesariamente que cargue lento, sino que cada acción requiere salir y volver a empezar, y la página parece un conjunto de bloques sin relación. Por lo tanto, primero se diagnostica el problema y luego se decide qué animar.

Responde en el lenguaje del usuario. Los términos técnicos se mantienen en su idioma original.

Principios

1. No tocar el código de producción hasta que se elija una versión: Primero se entrega el diagnóstico, las opciones y el prototipo; solo se implementa cuando el usuario elige explícitamente una versión.
2. Por defecto, no cambiar el diseño: Sin una solicitud explícita, no se cambian colores, tipografía ni maquetación. Solo se modifica la interacción. Cambiar el estilo de todo el sitio es otro asunto.
3. Priorizar móvil: Evaluar y validar con un ancho de 375px; la versión de escritorio es adicional.
4. La animación debe ser cliqueable para contar: Una imagen estática no muestra la sensación; las versiones deben ser prototipos funcionales.
5. Cada efecto debe tener un propósito: Cada animación debe responder una pregunta del usuario, como "¿lo pulsé?", "¿de dónde vengo?", "¿se actualizaron los datos?". Si no se puede responder, se elimina.
6. En sitios que dependen de búsqueda y publicidad, el SEO y la monetización priman sobre lo llamativo: Las animaciones no pueden reemplazar URLs independientes, contenido HTML del primer pliegue ni la visibilidad de los anuncios. Las herramientas internas y el panel de administración (tras inicio de sesión) no están sujetos a esta regla.
7. Cambiar contenido implica una nueva página; ajustar el mismo contenido se hace en el mismo lugar: Ver otro artículo requiere una nueva página, porque trae una nueva URL y nuevas solicitudes de anuncios; expandir, filtrar u ordenar se hace en el mismo lugar.
8. Las animaciones no pueden cruzar las líneas rojas del proyecto: Revisar primero las normas y restricciones legales del proyecto. No usar campos vacíos para efectos visuales ni insinuar información sin fundamento con animaciones.

Flujo de trabajo

Paso 1: Identificar qué tipo de dinamismo busca

"Dinamismo" puede referirse a cuatro cosas, cada una con una solución completamente diferente.

Tipo	Posibles expresiones	Lo que realmente hay que hacer
Dinamismo de datos	El contenido debe actualizarse solo, en tiempo real	Cron, API, polling; principalmente trabajo de backend, complementado con señales de actualización
Dinamismo de feedback	Al pulsar no se siente nada, demasiado estático	Presión, cambios de estado, destellos de actualización
Dinamismo continuo	Sensación de salto de página, muy primitivo, como un conjunto de objetos	Transiciones de página, expansión en el mismo lugar, elementos compartidos, gestos
Animación narrativa	La página principal necesita impacto, efectos de scroll, GSAP	Animaciones Hero, narrativa con scroll, momentos de marca

Cuando claramente se trata de dinamismo de datos, explica directamente que no es un problema de animación y opta por una solución de datos. En los demás casos, no preguntes de vuelta; pasa al Paso 2 y responde con observaciones reales.

Paso 2: Examinar la situación actual

Cuando se tiene acceso al código fuente del proyecto, ejecuta desde el directorio raíz de esta skill:

python3 scripts/motion_audit.py <directorio del proyecto>

El resultado del script es una pista, no un veredicto; cada elemento señalado debe verificarse manualmente.

Cuando se pueda abrir un navegador, recorre los caminos principales a 375px: página principal, página interna, cambiar de pestaña, hacer clic en un elemento de lista, volver atrás. Anota las sensaciones reales:

• Qué acciones recargan la página completa y cuáles cambian en el mismo lugar
• Si la página es un todo coherente o un conjunto de bloques independientes
• Si el usuario ve o no las actualizaciones de datos
• Si el feedback tiene retraso, o si alguna animación está causando problemas (por ejemplo, números que saltan cada vez que se entra en la página)

Si no hay sitio web (nuevo proyecto), o el proyecto es solo un esqueleto sin páginas reales: lee los archivos de planificación, determina el tipo de sitio y pasa al Paso 3, indicando que en esta fase no se puede diagnosticar la imagen real.

Si no se puede ver el sitio ni hay código: trabaja con la información proporcionada por el usuario, marcando todos los "problemas" como inferencias, y enumera como "no verificado" los datos faltantes. No inventes observaciones.

Paso 3: Definir el enfoque según el tipo de sitio

Tipo de sitio	Enfoque	Evitar
Sitios de datos y herramientas (marcadores, consultas, paneles)	Dinamismo continuo, señales de actualización, densidad	Desvanecimientos con scroll, animaciones que ocultan datos
Sitios de contenido y artículos	Feedback ligero, sin interrumpir la lectura	Cualquier efecto que distraiga la lectura o empuje anuncios
Páginas de marca y marketing	Un momento narrativo cuidado	Animación por todas partes
Servicios tipo app	Gestos, operaciones en el mismo lugar, estados continuos	Solo cambiar la piel sin modificar la interacción
Panel de administración y herramientas internas (tras inicio de sesión)	Feedback, cambios de estado, reducir cambios de página	Animaciones que ralentizan operaciones repetitivas

Paso 4: Planificar 2 o 3 versiones

Lee references/recipes.md para obtener recetas de efectos de movimiento, y references/pitfalls.md para evaluar riesgos.

Primero pasa por el "portal de navegación", que determina qué tipo de cambio de página puede incluirse en la propuesta:

Estado del sitio	Enfoque de navegación
Tiene o tendrá anuncios gráficos (p. ej., AdSense)	Por defecto, usa @view-transition entre documentos, manteniendo el cambio de página real; el comportamiento de anuncios y análisis no cambia
Ya tiene anuncios automáticos, anclados o intersticiales, o no se puede verificar el comportamiento de los anuncios tras el cambio de página	No recomendar la navegación suave en el mismo documento; si se incluye, debe ir marcada como "requiere pruebas previas" y dar una alternativa
Sin anuncios, o con anuncios y análisis ya verificados	Se puede usar navegación suave en el mismo documento o enrutamiento del framework; aún así hay que verificar análisis y estado de inicio de sesión tras el cambio de página

Si un sitio existente ya tiene navegación suave y se van a añadir anuncios, enumera esto como parte de "¿Cuál es el problema?", no lo des por solucionado.

Las versiones deben tener diferencias sustanciales, y deben ser diferencias en el alcance de la interacción, no diferencias de color. La escalera parte del estado actual del sitio; los elementos ya implementados no se repiten. Escalera por defecto:

• A: Versión ligera con sensación táctil: No toca la estructura de navegación, solo añade feedback y señales de actualización. Riesgo mínimo, se puede completar en el mismo día.
• B: Versión continua: A más transiciones de página, elementos compartidos y expansión en el mismo lugar. El enfoque de navegación se decide según el portal. Normalmente es la versión recomendada.
• C: Versión completa con sensación de aplicación: B más gestos de deslizamiento, cambio de datos en el mismo lugar, notificaciones en tiempo real, o momentos narrativos para sitios de marca. La sensación más potente, con el mayor costo y riesgo.

Las versiones deben pasar el filtro del tipo de sitio del Paso 3: los sitios de contenido y artículos normalmente se quedan en A o una B ligera. Si solo dos versiones tienen una diferencia real, da dos; no añadas por rellenar. Si A ya cubre todas las necesidades, dilo claramente. El costo de ingeniería de animación debe ser proporcional a los ingresos del sitio.

Paso 5: Crear un prototipo cliqueable

Sigue references/prototype.md. El prototipo usa datos reales y la apariencia actual; debe permitir cambiar entre versiones dentro de un solo archivo. Pruébalo con ancho de móvil antes de entregarlo. Puedes empezar con assets/prototype-template.html.

Paso 6: Propuesta

Informa siguiendo la "Estructura de salida" a continuación, y luego pide al usuario que elija una versión. Si hay una herramienta de selección en el entorno, úsala; si no, enumera las opciones con números, colocando la versión recomendada en primer lugar. La regla de "no preguntes de vuelta" del Paso 1 solo aplica a la fase de diagnóstico; aquí hay que detenerse y esperar la elección.

Paso 7: Implementación y aceptación

Comienza solo después de que el usuario haya elegido. Sigue el orden de references/acceptance.md para implementar y completar la aceptación. Al entregar a otro agente, usa la plantilla de transferencia de ese archivo.

Estructura de salida

La propuesta debe usar esta estructura fija, breve y concreta:

## Evaluación de dinamismo: <nombre del sitio>

**¿Cuál es el problema?**
<2 a 4 elementos, cada uno basado en observaciones reales, con la ubicación en la página. No digas cosas genéricas como "falta de interacción".>

**Comparación de versiones**
| | A: Sensación táctil ligera | B: Continua | C: Sensación completa de app |
|---|---|---|---|
| El usuario sentirá | | | |
| Principales cambios | | | |
| Cantidad de trabajo | Número de archivos y tiempo aproximado | | |
| Riesgo para SEO y CWV | Bajo/Medio/Alto, con una razón | | |
| Impacto en anuncios y análisis | Indicar enfoque de navegación y condiciones | | |
| Costo de mantenimiento | | | |

**Recomendación**: <cuál elegir, con una razón; si hay condiciones, indícalas>

**Prototipo**: <enlace o ruta, y enumera 3 a 5 acciones que probar>

**Cambios en el diseño**: <elementos que requieren aprobación del usuario; si no hay, escribe "Ninguno">

**No se propone**: <elementos que el usuario solicitó pero no se incluyen en esta ocasión, con razón; omitir si no hay>

**No se modificará**: <diseño, colores, URLs, líneas rojas de SEO, etc.>

**No verificado**: <elementos que no se han probado, como comportamiento real de anuncios, sensación en dispositivo real>

Cuando solo se den dos versiones, elimina las columnas que no se usen en la tabla. Las cantidades de trabajo deben ser números reales (por ejemplo, "modificar 4 a 5 archivos"), los riesgos deben explicarse con claridad, no solo "bajo". Indica si los números son medidos o estimados. Cuando una solicitud del usuario sea bloqueada por una condición, explica dónde está el bloqueo, bajo qué condiciones se puede retomar, y da una alternativa. La versión recomendada debe basarse en el portal de navegación y las condiciones de rendimiento; no tiene que ser necesariamente la B.

Archivos de referencia

Archivo	Cuándo leerlo
references/recipes.md	Paso 4, para elegir efectos y parámetros
references/pitfalls.md	Paso 4, para evaluar riesgos; Paso 7, al implementar
references/prototype.md	Paso 5
references/acceptance.md	Paso 7, incluye plantilla de transferencia
assets/prototype-template.html	Plantilla inicial para crear prototipos