Los diagramas publicados ya no pueden ser previews del editor

Las ultimas 24 horas en Nima Project tuvieron commits en cuatro repositorios:

• nikki-asteinza-web
• publish-service
• nima-editor
• world-cup-porra

La lista parece dispersa.

Una home personal, un servicio de publish, el editor desktop y una porra social no parecen el mismo problema.

Pero en estas horas los cuatro chocaron contra la misma regla:

una superficie publicada no puede seguir heredando comportamientos de preview interno.

Eso aparecio de dos formas:

• en Notipad y nikki-asteinza-web, porque un Mermaid publicado ya no podia verse como un bloque bonito dentro del editor;
• en Ultimate Porra, porque la entrada, el voto y los modales ya no podian permitirse feedback decorativo o ambiguo cuando el usuario esta operando de verdad.

La home de Nikki dejo de dibujar una idea y empezo a publicar una trayectoria

El frente mas visible estuvo en nikki-asteinza-web.

En menos de un dia pasaron varios commits encadenados:

• Use sequence diagram for home trajectory
• Use CV timeline Gantt on home
• Reposition full-stack training in home Gantt
• Shorten Gantt labels on home
• Correct home trajectory dates
• Show full yearly Gantt range

No fue una simple preferencia estetica entre un Mermaid y otro.

Fue descubrir que la trayectoria profesional de la home ya no podia tratarse como una ilustracion aproximada.

El sequence diagram servia para explorar una narrativa.

El Gantt, en cambio, obliga a fijar otra clase de contrato:

• que fechas son exactas y cuales se solapan;
• donde empieza de verdad el upgrade full-stack;
• cuanto espacio necesita cada etapa para leerse sin truncarse;
• y como se ve todo eso cuando se publica fuera del contexto del editor.

Por eso aparecieron despues correcciones tan concretas como acortar labels, recolocar una fase de formacion, corregir fechas y ampliar el rango anual completo.

El aprendizaje es util:

en cuanto una linea temporal se vuelve interfaz publica, deja de poder vivir de intuicion narrativa y pasa a depender de precision de datos, viewport y legibilidad real.

Publish tuvo que admitir que Mermaid no era solo contenido

La cadena fuerte de commits estuvo en publish-service:

• Use shared Mermaid Gantt styling
• Version published editor CSS assets
• Render published Gantt in wide scroller
• Zoom out published Gantt timeline
• Publish site static assets
• Version published static asset references
• Fit published Gantt gutter dynamically

Y en paralelo, nima-editor movio la misma conversacion a la fuente de verdad:

• Share Mermaid Gantt scroll styling
• Tune shared Mermaid Gantt gutter

Esto importa porque deja de tratar Mermaid como un SVG incrustado al que "ya se adaptara la web".

Ahora hay decisiones mucho mas explicitas:

• el editor define estilos compartidos para diagramas Gantt;
• publish deja de duplicar a mano esa capa y la reutiliza;
• el documento publicado gana un contenedor ancho y scrollable para timelines reales;
• el gutter ya no se fija con una constante fragil, sino que se ajusta dinamicamente;
• y los assets estaticos del sitio publicado pasan a versionarse para que CSS y recursos no dependan de cache vieja.

Ese ultimo punto parece infraestructura, pero en realidad es lectura.

Si cambias el comportamiento del diagrama pero el navegador sirve CSS anterior, el lector no ve el contrato nuevo.

No ve una mejora parcial.

Ve una publicacion rota.

La conversacion de chat fue mucho mas clara que el changelog

Los commits explican el que.

El chat explico el por que con mucha menos diplomacia.

En la sesión del 22 de junio el feedback fue muy concreto: quitar el brillo azulado de la preview del diagrama, eliminar cualquier hover y poner los diagramas de flujo en dos columnas.

Ese feedback resume mejor que cualquier diff el error de producto.

El problema no era que faltara un CSS.

El problema era haber dejado que la web publicada conservara señales visuales propias de una preview interactiva:

• brillo azulado;
• affordance de hover;
• y una sensacion de bloque "tocable" que no ayudaba a leer mejor el contenido.

Cuando un diagrama ya esta publicado, el lector no necesita recordar que viene de un editor rico.

Necesita que el contenido sea legible y estable.

Sin decoracion gratuita.

Sin estados heredados de una herramienta de edicion.

Ultimate Porra recibio la misma leccion por otro camino

En world-cup-porra la forma fue distinta, pero la presion de producto fue la misma.

Los commits de la ventana fueron:

• Show winner-only vote feedback
• Unify vote points feedback styling
• Improve entry dashboard and voting UX
• Fix modal scrim hover state

Vistos juntos, cuentan una misma historia:

la app ya no puede mezclar feedback principal, accion secundaria y decoracion visual como si el usuario estuviera explorando una maqueta.

Ahora la entrada y el voto tienen que dejar claro:

• que feedback importa de verdad para leer una apuesta;
• donde esta la accion de copiar o reutilizar votos;
• que informacion de resultado se anticipa ya desde el dashboard;
• y que un scrim es una capa de foco, no un elemento que deba "responder" al hover.

Esto conecta muy bien con la leccion del publish.

En ambos casos se esta corrigiendo el mismo anti-patron:

una interfaz madura no puede seguir reaccionando como si todo fuera una superficie de exploracion interna.

Lo que realmente cambio en estas 24 horas

La version superficial seria esta:

• Nikki cambio un diagrama por otro y ajusto fechas;
• publish arreglo Mermaid Gantt y versiono assets;
• el editor compartio estilos;
• Ultimate Porra pulio dashboard, votos y modales.

La version util es otra:

Nima Project empezo a separar con mas rigor lo que pertenece al editor de lo que pertenece al producto publicado.

Eso obliga a varias decisiones a la vez:

• una timeline publica necesita datos exactos, no solo una historia convincente;
• un diagrama publicado necesita scroll, gutter y ancho pensados para lectura real;
• los estilos que definen esa lectura no pueden bifurcarse entre editor y publish;
• y una microinteraccion en producto debe justificar su presencia, no heredar hover o brillo por costumbre.

Lo que me llevo de este tramo

• Mermaid deja de ser "contenido enriquecido" cuando el usuario depende de el para entender una trayectoria.
• Publicar bien no es solo renderizar Markdown; tambien es gobernar CSS compartido, cache y assets versionados.
• Un Gantt largo no falla por ser grande; falla cuando se intenta publicar con reglas pensadas para bloques pequenos.
• El hover es deuda si no comunica una accion real.
• Cuando una superficie publica sigue pareciendo preview, el problema no es visual: el contrato entre herramienta y producto todavia no esta cerrado.

Estas 24 horas no fueron sobre hacer diagramas mas bonitos.

Fueron sobre algo mas serio:

decidir que lo publicado ya no puede comportarse como una aproximacion de editor, porque ya esta ocupando el sitio de la interfaz final.

Parte de mis notas de producto y plataforma. Sigue el blog o escribeme.