Changelog & What's new UI

El changelog no es un git log formateado: es una herramienta de adopción. Cada entrada debe responder "que puedo hacer ahora que antes no podia", no "que modifico el ingeniero". "Corregido bug #4821 en parser YAML" no comunica valor; "Los archivos de configuración ya no fallan en silencio al cargar" si. El tono imperativo ("Ahora puedes X") implica agencia y reduce la carga cognitiva al escanear.

Mezclar features principales, tweaks de UI y typos en una lista plana obliga al usuario a extraer señal del ruido. Muestra un sumario editorial de lo más impactante (2-4 items) visible de inmediato, con la lista completa tras un control de expansión. Linear aplica este patrón: un hero por release con título, contexto y media, seguido de secciones colapsadas de "Fixes, Improvements, API changes".

Un modal de "What's New" en cada deploy genera fricción acumulativa y entrena al usuario a cerrar sin leer, quemando confianza. El modal solo es adecuado para cambios criticos (seguridad, breaking changes, migración). Para actualizaciones rutinarias, usa un badge silencioso en navegación o un inbox de notificaciones: el usuario consulta cuando quiera sin interrumpir su tarea.

El orden cronologico inverso es el único útil: el usuario quiere saber que cambio hace poco. Cada grupo muestra la fecha de release de forma visible (no solo el número de versión, opaco para no-técnicos) como ancla de navegación. Las fechas relativas ("hace 5 días") hacen el changelog sentirse vivo; las absolutas dan precisión para soporte. Versiones sin fecha rompen la confianza.

keepachangelog define categorías estandar (Added, Changed, Fixed, Removed, Deprecated, Security) que permiten al lector saltar a lo que le importa. Una etiqueta visual consistente por tipo de cambio, con color y texto, hace el feed escaneable sin leer cada línea. Evita inventar nombres ad hoc por release: la consistencia entre versiones es lo que vuelve útil la categoría.

El badge "Nuevo" solo tiene valor mientras la feature realmente lo es. Si permanece para siempre, pierde significado y el usuario lo ignora ("el niño que gritaba lobo"). Caduca la señal en dos condiciones: cuando el usuario visita la entrada, marcandola como leida, y tras un plazo máximo (tipicamente 14-30 días). La primera respeta la agencia; la segunda mantiene la UI limpia. El modelo mental correcto es "hay algo sin ver", no "esto es nuevo para siempre".

El changelog es un punto de descubrimiento, no el destino de aprendizaje. Una entrada despierta interes, pero si el usuario no puede pasar a la acción de inmediato la oportunidad de adopción se pierde. Cada feature de complejidad media o alta debe enlazar a su documentación, tutorial o pantalla de ajustes. Un CTA específico ("Ver opciones de exportación") supera al genérico "Leer más". Los bug fixes menores pueden omitir el enlace.

El panel de "What's New" debe ser navegable por teclado, con encabezados semánticos (h2/h3 por fecha y feature) y aria-live="polite" o role="log" cuando actualiza dinamicamente. Nunca debe robar el foco ni exigir interacción para cerrarse. El badge de conteo sin leer necesita aria-label que exprese el número ("3 novedades sin leer"), no solo el digito visual. assertive es demasiado disruptivo salvo alertas criticas.