Cuando empezamos el Journal, la prioridad era sencilla: documentar con cierta profundidad lo que estábamos construyendo. A medida que los artículos crecieron apareció otro problema. Un texto técnico de diez o quince minutos puede ser bueno y seguir obligando al lector a reconstruir mentalmente demasiadas relaciones.
La respuesta obvia habría sido añadir capturas o ilustraciones genéricas. Preferimos otra: si un artículo habla de un embudo de generación, dibujar ese embudo; si habla de componentes y motores, enseñar las capas; si explica Slant, representar diagonales y vértices; si habla de Kropki, que los puntos del diagrama signifiquen algo.
Decoración y explicación son problemas distintos
Una imagen puede dar ritmo a una página sin aportar información. Eso no es necesariamente malo, pero no resuelve el problema de un artículo de arquitectura o algoritmos. Queríamos visuales que redujesen trabajo cognitivo, no solo bloques de color entre párrafos.
Por eso empezamos por diagramas editoriales: flujos, capas, embudos, comparaciones y métricas. No intentan sustituir el texto. Le dan al lector un mapa antes de entrar en el detalle.
Si al quitar el texto de una imagen no queda ninguna idea, probablemente era decoración.
El primer sistema: visuales editoriales reutilizables
Construimos una pequeña gramática visual para el Journal: nodos, pasos, estadísticas, capas y callouts con la misma identidad. Esto permite crear una infografía sin inventar una composición completamente nueva en cada artículo.
La reutilización aquí no significa que todas las figuras se vean iguales. Significa que comparten reglas suficientes para que el lector entienda cómo leerlas y para que el sitio pueda adaptarlas a móvil, modo claro y futuras revisiones.
Después vino la parte difícil: dibujar la mecánica real
Un diagrama sobre «arquitectura» puede ser abstracto. Un diagrama de un puzzle no debería serlo. Si hablamos de Slitherlink, las líneas deben comportarse como aristas alrededor de pistas. En Kropki, un punto blanco y uno negro no son dos adornos distintos: codifican relaciones diferentes. En Aquarium, la altura importa.
Por eso hemos añadido un conjunto de diagramas específicos de puzzle al Journal. Son pequeñas representaciones editoriales, no motores jugables, pero intentan conservar la lógica visual suficiente para que alguien reconozca qué tipo de problema se está explicando.
Por qué no usar una colección de imágenes estáticas
Generar PNG para todo habría simplificado algunas cosas, pero nos habría hecho perder otras: adaptación a tema, escalado limpio, accesibilidad estructural y posibilidad de ajustar el sistema visual desde CSS.
Las infografías actuales están integradas en el HTML y los estilos del Journal. Esto permite que compartan tokens y respondan al layout. También hace que un cambio editorial pueda propagarse sin volver a exportar decenas de archivos.
El build también tiene opinión editorial
La publicación ya no consiste únicamente en copiar HTML. El pipeline localiza rutas, prepara metadatos, genera superficies de building in public, añade recursos editoriales y verifica que las piezas necesarias terminan conectadas.
En los últimos cambios incluso hemos tenido que ajustar el orden del build para que los diagramas y la localización no se pisen. Parece una cuestión menor hasta que recuerdas que el Journal se publica en el mismo producto que los juegos y comparte su disciplina de despliegue.
Esto también ayuda al building in public
Contar el desarrollo en público tiene un riesgo: convertir cada entrada en «hemos añadido X». Los diagramas nos obligan a formular mejor qué cambió realmente. Para dibujar una arquitectura primero hay que decidir cuáles son sus capas; para enseñar un flujo de IA hay que describir dónde entra la revisión humana; para representar la generación hay que explicitar qué se rechaza.
En ese sentido, preparar una infografía funciona casi como una revisión técnica. Si no podemos dibujar la relación de forma comprensible, quizá tampoco la estamos explicando bien.
El objetivo no es llenar todos los artículos de figuras
No queremos convertir el Journal en una presentación interminable. Hay ideas que se leen mejor en dos párrafos y no ganan nada con cajas y flechas. La regla que estamos adoptando es usar visuales cuando comprimen una relación, muestran una secuencia o permiten comparar.
También evitamos que la forma suplante al contenido. Un artículo debe seguir teniendo valor si se lee en modo texto, con un lector de pantalla o desde una vista simplificada.
De publicar artículos a diseñar una publicación
Esta es probablemente la diferencia más importante. Al principio, el blog era un lugar donde poner textos. Ahora el Journal tiene series, building in public, bitácora, navegación relacionada, portadas sociales, SEO estructurado y un lenguaje visual propio.
No lo hacemos porque PuzzleHub necesite parecer una revista. Lo hacemos porque la documentación técnica y de producto se ha convertido en parte de cómo pensamos el proyecto. Si vamos a construir en público, la calidad de lo que contamos también forma parte del producto.
La siguiente mejora editorial será menos visible
Con la base visual ya creada, el trabajo importante vuelve a ser el criterio: elegir qué merece un artículo largo, qué pertenece al devlog y qué diagrama realmente aclara una idea. Automatizar la publicación tiene sentido; automatizar la voz o llenar páginas por llenar no.
La meta sigue siendo la misma que con los juegos: más sistema para poder dedicar más atención a lo que no debería ser genérico.