Una web puede crecer de dos maneras. Puede añadir más cosas a la misma superficie hasta que cada página cargue con todas las responsabilidades, o puede aprender a separar funciones sin perder coherencia. Durante bastante tiempo Blupoli —y antes Blupoli Puzzles— creció de la primera forma. Era razonable: había una sola experiencia, un catálogo de puzzles y una publicación alrededor del proyecto. A medida que el producto maduró, aquella simplicidad inicial empezó a convertirse en mezcla. La navegación de juego hablaba de contenidos editoriales. El espacio editorial mezclaba anuncios de producto con diarios de desarrollo. El footer, el logo y algunos patrones visuales no siempre estaban sincronizados entre la home y Puzzles. Y el resultado era una sensación difícil de definir: todo pertenecía al mismo proyecto, pero no siempre parecía diseñado como un sistema único.
La reestructuración reciente intenta resolver precisamente eso. No estamos persiguiendo una estética completamente nueva por gusto, ni rehaciendo la interfaz para que cada semana parezca diferente. Estamos usando el diseño para aclarar la arquitectura del producto. Blupoli es la marca raíz. Blupoli Puzzles es la experiencia para jugar. El Blog cuenta noticias, lanzamientos, ideas y cambios relevantes para las personas que usan la web. El Devlog explica cómo construimos lo anterior: decisiones, errores, experimentos, arquitectura y aprendizaje. Cuando cada superficie sabe para qué existe, el diseño deja de ser una colección de componentes bonitos y empieza a actuar como un lenguaje.
El problema no era que el diseño fuese oscuro
Uno de los primeros impulsos cuando una interfaz no termina de convencer es tocar la paleta, los radios, las sombras o la tipografía. Es lógico porque son los elementos más visibles. Pero al revisar la web vimos que el problema principal no estaba ahí. Había buenas piezas visuales, especialmente en la experiencia de los juegos. Lo que faltaba era jerarquía entre productos y contenidos.
Un visitante podía llegar para jugar y encontrarse con navegación editorial que no era esencial para su tarea. Otra persona podía abrir un artículo sobre una nueva función y terminar en una página que visualmente se parecía demasiado a una bitácora técnica. Habíamos acumulado contenido interesante, pero la forma de presentarlo no ayudaba a comprender qué tipo de contenido era ni por qué estaba ahí. La interfaz, en lugar de reducir decisiones, añadía preguntas.
Por eso el rediseño empezó por algo menos espectacular que un nuevo hero: definir responsabilidades. La home de Blupoli debía representar la marca y conducir a productos reales. Puzzles debía priorizar catálogo, juego y descubrimiento. El Blog debía comportarse como publicación pública. El Devlog debía tener espacio para la profundidad y la cronología del trabajo. Este reparto permitió después tomar mejores decisiones visuales porque cada botón, título o tarjeta podía evaluarse con una pregunta concreta: ¿ayuda a cumplir el propósito de esta superficie?
Pasamos de una sola superficie que intentaba contarlo todo a varias áreas con una misión explícita.
Blog y Devlog por fin significan cosas distintas
La separación entre Blog y Devlog es probablemente el cambio más importante de esta fase porque afecta tanto al diseño como a la forma de escribir. Antes usábamos términos como Journal, Bitácora o Devlog y una parte de los contenidos se cruzaba entre ellos. Eso había funcionado mientras el volumen era pequeño. Con decenas de artículos, sin embargo, se volvía difícil saber dónde debía vivir una historia y qué esperaba el lector al entrar.
Ahora el Blog tiene un criterio público. Aquí queremos hablar de cambios que importan por el resultado: una nueva forma de organizar el catálogo, un lanzamiento, una mejora grande de diseño, un artículo sobre un tipo de puzzle o una noticia de Blupoli. No hace falta haber seguido el desarrollo para entender el texto. Debe poder leerse como una pieza autónoma, con contexto suficiente y una conclusión útil.
El Devlog mira el mismo proyecto desde otra distancia. Allí podemos explicar que un build tenía una limitación, que una ruta heredada exigió una migración, que un motor necesitó un solver propio o que una decisión de diseño surgió después de detectar una incoherencia concreta. El lector del Devlog no solo quiere saber qué cambió; quiere entender cómo llegamos a esa decisión y qué aprendimos por el camino.
Esta división también cambia la interfaz. Las etiquetas, los enlaces de retorno, los metadatos y los listados pueden explicar mejor el contexto. Una persona que entra en Devlog sabe que encontrará profundidad técnica y proceso. Una persona que entra en Blog sabe que no necesita leer una reconstrucción de commits para entender la noticia. Esa claridad reduce fricción y, al mismo tiempo, nos permite escribir piezas más ambiciosas en ambos espacios.
Las portadas dejan de ser decoración opcional
Otro cambio visible es la decisión de que las publicaciones importantes tengan una portada real. Cuando una página editorial crece sin imágenes, el problema no es solamente estético. Las tarjetas terminan pareciéndose demasiado unas a otras, la navegación se convierte en una lista de bloques de texto y cada artículo pierde una parte de su identidad antes incluso de abrirse.
Estamos tratando las portadas como parte del sistema editorial, no como un adorno añadido al final. Deben comunicar el tema, funcionar en formato social, verse bien en móvil y acompañar la identidad de Blupoli sin convertir todas las publicaciones en clones. Un artículo sobre calidad del catálogo puede usar la idea de un gate o un proceso de verificación. Una pieza sobre diseño puede representar la relación entre superficies. Un devlog de arquitectura puede enseñar flujo, dependencias o capas.
Esto tiene además una ventaja práctica: obliga a definir visualmente el tema antes de publicar. Si no sabemos qué representar en la portada, muchas veces significa que el artículo todavía no tiene una idea central suficientemente clara. La imagen se convierte en una pequeña prueba editorial.
Y las infografías tienen que explicar algo
Las imágenes de portada resuelven identidad y descubrimiento, pero dentro de un artículo largo necesitamos otro tipo de visual. Hemos empezado a incorporar diagramas e infografías semánticas porque hay ideas que se entienden mejor cuando se ven. La clave está en que esos elementos no sean relleno.
Un diagrama de flujo puede mostrar cómo pasa un juego de prototipo a publicado. Una comparación puede explicar por qué Blog y Devlog tienen misiones diferentes. Un esquema de arquitectura puede relacionar Blupoli, Puzzles, Hosting y dominios. La intención es que una persona pueda detenerse en la figura y obtener información que complementa el texto, no simplemente descansar la vista con una ilustración genérica.
Este principio encaja especialmente bien con los puzzles, donde muchas reglas son espaciales. Pero también funciona para producto y desarrollo. Una buena infografía permite resumir una decisión compleja sin simplificarla hasta volverla incorrecta. Y, al formar parte del HTML y de los estilos compartidos, puede mantenerse responsive y accesible sin depender de una captura estática ilegible.
Un logo, una fuente de verdad
La identidad visual también arrastraba una incoherencia pequeña pero persistente: distintas partes de la web podían representar el logo de maneras diferentes. Había marcas duplicadas, símbolos dibujados desde componentes distintos y un footer que no siempre encontraba el asset correcto. El resultado era especialmente evidente cuando se comparaban la home de Blupoli y Puzzles.
La solución no fue dibujar una versión nueva en cada sitio. Fue hacer lo contrario: reducir. Creamos un asset compartido y empezamos a hacer que los distintos puntos de la interfaz lo utilicen desde una fuente común. La B blanca sobre azul funciona como marca compacta y puede convivir con el nombre escrito cuando hay espacio. Header, footer y otras superficies dejan así de reinterpretar la identidad por su cuenta.
La ventaja de centralizar un elemento tan básico parece trivial hasta que hay que cambiarlo. Si cada superficie incrusta su propio SVG o recrea la marca con CSS, cualquier ajuste genera una persecución de variantes. Una fuente de verdad evita esa deriva y hace posible añadir tests que detecten cuando una parte vuelve a introducir una copia obsoleta.
El header compartido importa más de lo que parece
La navegación superior es una de las pocas piezas que el usuario ve en casi todas las páginas. Si la home y Puzzles usan patrones distintos, el cambio de subdominio se siente como abandonar un producto y entrar en otro sitio sin relación. Pero si copiamos exactamente los mismos enlaces en todas partes también perdemos la especialización que buscamos.
La solución es compartir la estética y el comportamiento, no necesariamente el contenido exacto. Logo, proporciones, estados de foco, forma de los botones, tratamiento responsive y lenguaje visual deben pertenecer al mismo sistema. Los destinos pueden adaptarse: Puzzles necesita accesos ligados al juego; la home necesita explicar el ecosistema; Blog y Devlog necesitan navegación editorial. Esa combinación mantiene identidad sin obligar a que todas las superficies finjan tener las mismas prioridades.
También estamos eliminando duplicaciones de chrome que históricamente crecieron en archivos distintos. Cuanto más compartido sea el componente base, menos probable será que un cambio de espaciado o un arreglo de accesibilidad llegue a un sitio y se olvide en otro.
El footer deja de ser el lugar donde terminaba lo que sobraba
Los footers suelen recibir poca atención porque están fuera de la primera pantalla. En nuestro caso eso produjo dos problemas: visualmente resultaba demasiado oscuro y pobre en algunas superficies, y en móvil directamente podía desaparecer o quedar relegado por la estructura de la página. Además, el footer de Puzzles no explicaba bien que existía una home general de Blupoli.
El rediseño le da una función más clara. Debe cerrar la página, ofrecer rutas útiles, reforzar identidad y permitir volver a Blupoli desde un producto. No pretendemos convertirlo en un sitemap gigante. Queremos que sea una pieza consistente, legible en modo claro y oscuro, y que no deje al usuario atrapado en un subdominio.
Este cambio sirve además como prueba de madurez del sistema compartido. Un footer que se ve bien en escritorio pero desaparece en móvil no está realmente terminado. Un footer que muestra un logo roto porque depende de una ruta relativa distinta tampoco. Resolverlo obliga a pensar en assets, breakpoints, contexto de despliegue y accesibilidad al mismo tiempo.
Modo claro y oscuro sin convertir cada página en una excepción
Blupoli ya venía trabajando con temas, pero al separar nuevas superficies era fácil que cada una desarrollase su propia versión. La dirección actual es la contraria: tratar el tema como una expectativa de plataforma. Si una persona elige un modo o su sistema indica una preferencia, la experiencia debe respetarla con la mayor continuidad posible.
Esto exige revisar más que el fondo. Tarjetas, bordes, enlaces, código, figuras, estados activos, textos secundarios y superficies de juego necesitan contraste correcto en ambos modos. Blog y Devlog son particularmente sensibles porque contienen piezas largas; un color secundario con contraste insuficiente puede convertirse en fatiga después de veinte minutos de lectura.
El objetivo no es que claro y oscuro sean idénticos. Pueden tener personalidad. Lo importante es que ambos sean deliberados y que añadir una nueva publicación no obligue a introducir excepciones manuales para que resulte legible.
La tipografía editorial necesita respirar
Separar Blog y Devlog nos ha permitido pensar también en la lectura como una experiencia propia. Una página de juego optimiza espacio para controles y tablero. Una página editorial optimiza concentración, ritmo y jerarquía. Tratar ambas con la misma densidad visual sería un error.
Los artículos largos necesitan una medida de línea contenida, espacio suficiente entre párrafos, encabezados que permitan escanear y figuras que interrumpan el texto con intención. También necesitan una cabecera que responda rápidamente a preguntas básicas: qué estoy leyendo, de qué categoría es, cuándo se publicó y cuál es la idea principal.
Esta es una de las razones por las que queremos que el Blog sea una delicia de leer y no simplemente un repositorio de anuncios. Una pieza de tres mil palabras solo funciona si el diseño acompaña. El contenido puede ser excelente y seguir sintiéndose pesado si la interfaz no respeta el tiempo de lectura.
La portada del Blog deja de ser un batiburrillo
Cuando todas las piezas editoriales comparten un único listado, las categorías pierden significado. Un tutorial de Sudoku puede aparecer junto a una nota de infraestructura, después de un anuncio de marca y antes de un diario de debugging. Técnicamente todos son artículos; editorialmente no cumplen la misma función.
La reorganización crea categorías más inteligibles y permite que el hub del Blog muestre contenido de una forma más cercana a una publicación. Noticias y cambios de producto pueden convivir con guías y artículos sobre puzzles, pero sin ocultar que pertenecen a familias distintas. El Devlog, por su parte, puede ordenar desarrollo, arquitectura, diseño, IA, calidad o aprendizaje sin contaminar el espacio público principal.
Esto también mejora el descubrimiento. Alguien que llega desde un buscador a un artículo sobre Akari puede encontrar otras guías de puzzle. Quien lee sobre la nueva etapa de calidad puede saltar al Devlog que explica cómo funciona la auditoría. Los enlaces dejan de ser aleatorios y empiezan a formar recorridos.
Diseñar enlaces entre superficies, no muros
Separar no significa aislar. De hecho, la nueva estructura solo tiene sentido si las partes se conectan mejor que antes. Un artículo del Blog sobre la reestructuración del catálogo puede enlazar al Devlog técnico que explica los gates. Una entrada sobre un puzzle concreto puede llevar directamente a Blupoli Puzzles cuando ese juego está publicado. Una historia de diseño puede enlazar a la nueva etapa del catálogo porque ambas decisiones comparten una misma idea: menos ruido y más intención.
El reto consiste en que esos enlaces sean útiles, no promocionales. No queremos terminar cada párrafo con una llamada a otra página. Queremos construir contexto. Si una pieza explica el resultado y otra explica el proceso, se complementan. Si un artículo describe una mecánica y existe un juego disponible, tiene sentido permitir probarla. Si un contenido menciona una idea futura que todavía no está publicada, no debemos fingir que se puede usar.
El SEO también forma parte del diseño de información
Canonicales, títulos, hreflang, metadatos sociales y datos estructurados suelen verse como tareas técnicas separadas del diseño. En realidad describen la arquitectura a buscadores, navegadores y redes del mismo modo que la navegación la describe a las personas. Si Blog y Devlog están separados visualmente pero los metadatos siguen llamando a todo Journal o Devlog, el sistema continúa contando dos historias distintas.
Por eso la migración incluye limpieza de nombres, publisher, títulos de navegador, descripciones, rutas y referencias históricas. «Blupoli Puzzles» se conserva cuando es necesario para explicar el pasado, pero la identidad activa es Blupoli y el producto es Blupoli Puzzles. Del mismo modo, «Devlog» puede seguir apareciendo en nombres de archivos internos por compatibilidad, pero la superficie pública se llama Devlog.
Estas decisiones hacen que la web sea más coherente incluso fuera de la web. Cuando un enlace se comparte, la tarjeta social debe enseñar la portada y el nombre correctos. Cuando un buscador indexa una versión inglesa y otra española, debe entender que son alternates reales, no duplicados accidentales. Cuando cambiamos una ruta, una redirección debe proteger el historial sin convertir la arquitectura antigua en la identidad nueva.
Una web responsive no es una versión encogida del escritorio
Buena parte del trabajo reciente ha consistido también en revisar móvil. El catálogo y los juegos ya nos habían enseñado que reducir anchos no basta. La navegación necesita estados distintos, los controles necesitan superficies táctiles razonables y un footer que funciona al final de una columna de escritorio puede comportarse de manera diferente en una vista con barras persistentes.
Blog y Devlog tienen sus propios retos. Una portada grande debe conservar jerarquía sin empujar el comienzo del texto demasiado lejos. Las infografías necesitan reorganizar nodos y etiquetas sin depender de zoom. Las líneas de código no deben romper el layout. La navegación editorial debe seguir accesible sin comerse media pantalla.
Estamos intentando convertir esas decisiones en componentes y reglas compartidas para que cada nueva publicación herede un buen comportamiento por defecto. El objetivo real de un sistema de diseño no es acelerar la primera página; es evitar que la página número cincuenta necesite cincuenta arreglos específicos.
El diseño empieza a tener memoria
Hay otro cambio menos visible que nos importa mucho: estamos añadiendo comprobaciones para evitar volver atrás sin darnos cuenta. Un logo compartido puede tener un test. Una marca antigua puede activar un guard en el build. Una publicación puede exigir portada, metadatos o estructura. Una ruta editorial puede validarse.
Eso convierte decisiones visuales y editoriales en contratos. No significa que el diseño quede congelado. Significa que, si cambiamos una convención, lo hacemos conscientemente y actualizamos el contrato. Esta idea es especialmente útil en un proyecto donde trabajan agentes, scripts y procesos automatizados: la documentación orienta, pero una comprobación automática evita que una tarea aislada reintroduzca una incoherencia que ya habíamos resuelto.
Qué no estamos intentando hacer
No queremos que Blupoli parezca una suite corporativa gigantesca antes de tiempo. Tampoco queremos crear cinco subdominios vacíos para demostrar que existe una arquitectura. La home debe seguir siendo pequeña. Puzzles debe seguir siendo rápido de entender. Blog y Devlog deben justificar su existencia con contenido, no con menús.
Por eso algunos nombres internos seguirán siendo heredados durante un tiempo y algunas rutas se migrarán de forma incremental. Cambiar todo a la vez podría producir una limpieza aparente y una colección de regresiones reales. Preferimos que la identidad pública sea coherente mientras la infraestructura interna evoluciona con seguridad.
Tampoco buscamos que cada página tenga un diseño distinto. La personalidad está en el contenido, las portadas y el propósito. El chrome, los componentes básicos, el logo, el tema y los patrones de interacción deben ser previsibles. La coherencia libera espacio para que los artículos y puzzles sean los protagonistas.
Compartimos la estructura que da confianza y diferenciamos lo que da propósito.
Lo que notarás al navegar ahora
El resultado acumulado debería sentirse más tranquilo. Al entrar en Puzzles, el foco está en jugar. Al abrir la home, la marca no promete productos que todavía no existen. Al visitar el Blog, las historias públicas tienen una presentación editorial más cuidada, con portadas y categorías. Al entrar en Devlog, el nombre ya dice qué tipo de profundidad vas a encontrar. Header y footer empiezan a hablar el mismo idioma visual. Y el logo deja de depender de cuál fue la última carpeta que alguien editó.
Probablemente no todos los cambios llamen la atención por separado. Eso es buena señal. Un sistema de diseño útil no necesita que cada componente grite que ha sido rediseñado. Debe reducir pequeñas fricciones hasta que navegar resulte más obvio.
Seguiremos ajustando detalles a medida que añadamos contenido real. Las mejores decisiones de diseño editorial aparecen después de ver títulos largos, imágenes diferentes, categorías con volúmenes desiguales y artículos que superan las tres mil palabras. Lo importante es que ahora contamos con una estructura que permite aprender sin volver a mezclar responsabilidades.
La nueva etapa de Puzzles y el rediseño son la misma decisión
A primera vista, marcar juegos incompletos como «próximamente» y separar Blog de Devlog parecen proyectos distintos. Para nosotros expresan la misma idea: mostrar con claridad el estado real de las cosas. Un prototipo no debe fingir que está terminado. Un diario de desarrollo no debe fingir que es una noticia de producto. Una marca raíz no debe fingir que es solo el catálogo de puzzles. Y un componente duplicado no debe fingir que pertenece a un sistema compartido.
Estamos intentando que la interfaz sea honesta con la arquitectura y con el nivel de madurez del contenido. Eso quizá reduzca algunos números visibles a corto plazo y obligue a invertir más tiempo en cada publicación o juego. A cambio, todo lo que permanece visible tiene un significado más claro.
Puedes leer más sobre este cambio de criterio en Una nueva etapa para Blupoli Puzzles. Y si te interesa la parte más técnica, el Devlog sobre la separación editorial entra en las decisiones de arquitectura, migración y compatibilidad que hay detrás de esta nueva organización.
Diseñar una casa en la que podamos seguir creciendo
Blupoli todavía está en una etapa temprana. Eso hace tentador aplazar este tipo de trabajo y dedicar toda la energía a añadir más juegos o funciones visibles. Pero también es el mejor momento para definir fronteras antes de que cada excepción se convierta en dependencia.
Queremos una web donde sea fácil saber dónde estás, qué puedes hacer y qué tipo de contenido estás leyendo. Queremos que Puzzles pueda crecer sin cargar con toda la marca. Queremos que el Blog sea interesante incluso para quien no sigue nuestros commits. Queremos que el Devlog conserve la memoria del desarrollo sin convertir cada noticia en una clase de ingeniería. Queremos que el logo, el footer y la navegación se sientan familiares aunque cambie el subdominio.
Eso es, en el fondo, lo que significa este rediseño. No una nueva capa de pintura, sino una casa con habitaciones mejor definidas. Seguiremos moviendo muebles, corrigiendo proporciones y aprendiendo qué funciona. Pero por primera vez la estructura empieza a reflejar de verdad el proyecto que queremos construir: una marca común, productos con propósito y una publicación que sabe cuándo contar el resultado y cuándo enseñar el proceso.