Cuando una web tiene cinco juegos, cada detalle puede resolverse de forma local. Una tarjeta distinta no molesta demasiado. Un botón pequeño afecta a una sola pantalla. Una navegación improvisada todavía cabe en el header. Incluso un tema oscuro con colores escritos a mano puede sobrevivir durante bastante tiempo.
Con más de setenta juegos ocurre lo contrario. Cualquier incoherencia se multiplica. El producto deja de tolerar soluciones «solo para esta página» porque la suma termina convirtiéndose en fricción estructural.
En los últimos días hemos trabajado precisamente en esa capa menos visible: navegación móvil, footer responsive, tamaño de controles, modo claro y oscuro, separación entre producto y contenido editorial, una home de marca propia y una hoja de ruta pública. Ninguna de estas tareas añade un puzzle al catálogo, pero todas cambian cómo se siente usar la plataforma.
Responsive no significa que el contenido «quepa»
Durante mucho tiempo, el criterio mínimo de responsive fue bastante común: si la página no produce scroll horizontal y el tablero reduce su tamaño, podemos darla por buena. Es una definición demasiado pobre para una aplicación interactiva.
En móvil importan la densidad, el tamaño de objetivos táctiles, la jerarquía visual, el orden de los controles y la cantidad de decisiones visibles a la vez. Un tablero puede caber perfectamente y seguir siendo incómodo si los botones se vuelven minúsculos o si la navegación ocupa media pantalla.
La revisión reciente ha atacado precisamente estos puntos. El Home recibió una navegación móvil accesible y una composición más compacta. Los controles de juego crecieron en varios breakpoints para mantener una superficie táctil razonable. El footer dejó de ser un bloque pensado exclusivamente para escritorio y pasó a tener un comportamiento definido en pantallas estrechas.
Son cambios pequeños por separado, pero tienen un multiplicador enorme. Arreglar un patrón común mejora decenas de juegos de una vez.
La mejor optimización de un catálogo grande es dejar de corregir la misma interfaz juego por juego.
La navegación móvil necesitaba dejar de ser una versión encogida del escritorio
Una barra horizontal funciona mientras hay espacio. Cuando empiezas a añadir juegos, estadísticas, blog, secciones de producto y controles de tema, reducir tipografía no resuelve el problema.
La nueva navegación móvil se plantea como un estado propio. Tiene botón accesible, controla correctamente aria-expanded, se cierra con Escape, responde a clics fuera del menú y vuelve a su estado normal al cambiar a un breakpoint de escritorio.
Puede parecer demasiado detalle para un menú. Pero ese tipo de comportamiento es el que separa un componente visual de un componente de producto. Si el menú se queda abierto después de navegar, si atrapa foco de forma extraña o si no se puede cerrar con teclado, la implementación está incompleta aunque la captura de pantalla sea bonita.
El tamaño de los controles era deuda transversal
Varios juegos habían heredado botones y selectores diseñados cuando la densidad del shell era distinta. En escritorio podían parecer correctos; en tablet y móvil se volvían demasiado pequeños o demasiado comprimidos.
En lugar de parchear cada motor, añadimos una capa común de sizing responsive. El objetivo es que las acciones principales —nuevo juego, deshacer, pista, dificultad, tamaño y controles específicos— conserven legibilidad y una superficie táctil suficiente.
Esto también obliga a decidir qué controles merecen estar visibles a la vez. Responsive no es solo CSS; es priorización. Una pantalla pequeña te fuerza a reconocer qué acciones son principales y cuáles pueden vivir en un menú secundario o en una disposición distinta.
El footer también forma parte del sistema
Los footers suelen posponerse porque parecen la zona menos importante de una aplicación. En una plataforma grande cumplen varias funciones: cerrar la navegación, ofrecer rutas institucionales, reforzar marca y evitar que cada página termine de manera distinta.
Definir un footer responsive común nos ayuda además a preparar la separación de productos. Puzzles puede conservar identidad de producto mientras sigue enlazando a Blupoli. El blog podrá hacer lo mismo desde su futuro subdominio. La consistencia no requiere que todas las cabeceras sean idénticas; requiere que el usuario entienda en qué parte del ecosistema está y cómo volver.
Modo claro: una auditoría involuntaria de arquitectura visual
El tema claro ha sido una de las mejores pruebas para detectar deuda visual. Cuando una interfaz nace oscura, es muy fácil escribir colores absolutos: un gris que «se ve bien», un borde semitransparente, un fondo negro con opacidad. Todo funciona mientras el contexto no cambia.
Al introducir modo claro, esas decisiones implícitas dejan de funcionar. Un texto secundario pierde contraste. Un borde desaparece. Una celda seleccionada ya no se distingue. Un tablero personalizado conserva un fondo oscuro y rompe la coherencia.
Por eso tratamos el tema como sistema de tokens y estados. La preferencia del usuario se persiste. Si no existe una selección explícita, respetamos prefers-color-scheme. El icono y la etiqueta del selector cambian según la acción disponible. El theme-color del navegador también se sincroniza.
La home de Blupoli ha adoptado el mismo comportamiento. No queríamos que la portada de marca pareciera otro proyecto distinto al entrar o salir de Puzzles.
Una política de seguridad puede romper una mejora aparentemente inocente
La incorporación del selector de tema en blupoli.com descubrió un detalle que nos gusta especialmente porque muestra cómo las capas se relacionan.
La home inicial era estática y no necesitaba JavaScript. Su Content Security Policy declaraba script-src 'none'. Era una política estricta y correcta para ese estado. Cuando añadimos un pequeño script propio para el tema, el navegador iba a bloquearlo.
La solución fácil habría sido añadir 'unsafe-inline' o relajar más de la cuenta. En su lugar cambiamos la regla a script-src 'self'. La portada puede ejecutar sus scripts versionados desde el mismo origen y sigue rechazando fuentes externas.
Es un ejemplo sencillo de un principio que intentamos mantener: cuando una nueva funcionalidad choca con una restricción de seguridad, primero entendemos qué permiso necesita exactamente antes de eliminar la restricción.
Separar Puzzles del blog era también una mejora de UX
Durante meses, el Journal fue una sección natural de PuzzleHub. El producto y la historia de construirlo eran prácticamente la misma cosa. Con Blupoli eso ha cambiado.
El contenido editorial habla cada vez más de infraestructura, agentes de IA, arquitectura de despliegue, decisiones de marca, Android, GitHub, diseño y procesos. Obligar a entrar en Puzzles para leerlo empieza a ser conceptualmente extraño.
Por eso hemos eliminado los accesos editoriales globales de la navegación de Puzzles y hemos creado una puerta editorial en la home de Blupoli. El movimiento físico hacia blog.blupoli.com llegará después, con redirecciones y canonicales correctos.
Esta separación también mejora la navegación dentro del producto. Cuando alguien está resolviendo un puzzle, las opciones principales deberían ser juegos, estadísticas y funciones del producto, no una colección creciente de enlaces a Journal, devlog, building y roadmap.
Cada superficie debe enseñar solo las decisiones que pertenecen a su contexto.
La home raíz tenía que dejar de competir con el producto
La primera pregunta al diseñar blupoli.com fue qué debía contener. Era fácil caer en un portal gigantesco con tarjetas para todo lo que podríamos construir algún día.
La primera versión incluso enseñaba Brain como producto futuro. Lo quitamos. No queremos usar «próximamente» como decoración. Hoy existen Blupoli, Puzzles y el contenido editorial. La home debe representar esa realidad.
Esto nos llevó a un diseño mucho más simple: identidad de marca, acceso claro a Puzzles, entrada al blog y una hoja de ruta. El espacio libre es una decisión, no una carencia.
Cuando aparezca un producto real nuevo, la portada podrá crecer. Mientras tanto, es mejor que un visitante entienda en diez segundos qué puede hacer ahora que enseñarle cinco nombres que todavía no llevan a ninguna parte.
La hoja de ruta pública no es el backlog
También añadimos una roadmap a la home. Aquí teníamos otro riesgo: copiar nuestras tareas internas y convertir la portada en una lista interminable de trabajo técnico.
Una hoja de ruta pública tiene otra función. Debe explicar dirección, no gestionar ejecución. Por eso usa estados amplios como «en curso», «siguiente» y «exploración», y de momento habla principalmente de Puzzles.
No publicamos fechas inventadas. Tampoco prometemos productos solo porque estén en una nota interna. La roadmap comunica qué estamos intentando consolidar: profundidad del catálogo, plataforma compartida, cuenta y estadísticas sincronizadas, y posibles nuevas superficies como Android.
La diferencia con un backlog es importante. El backlog puede cambiar cada día. La roadmap debería seguir siendo comprensible aunque una tarea concreta se adelante o se retrase.
La consistencia no consiste en que todos los juegos se vean iguales
Uno de los peligros de crear un sistema de UI común es borrar personalidad. Si cada tablero tiene exactamente el mismo color, los mismos controles y la misma composición, puede resultar consistente pero también plano.
Nuestra intención es compartir la estructura que reduce fricción y dejar libres las partes que expresan la mecánica. El shell puede decidir dónde vive la dificultad, cómo se abre el onboarding o cómo se muestran acciones. El motor decide cómo se representa una celda, una arista, un barco, una bombilla o una pieza.
Los colores de categoría y los acentos ayudan a mantener una identidad reconocible sin convertir el producto en un collage. La consistencia debe sentirse en el comportamiento antes que en la uniformidad visual absoluta.
El onboarding también forma parte de esa coherencia
En paralelo al rediseño visual, el sistema de onboarding pasó a utilizar perfiles por mecánica y asignaciones explícitas. Cada juego tiene que saber cómo enseñar su primera interacción.
Esta decisión conecta con el responsive y la navegación más de lo que parece. Una interfaz común reduce lo que hay que explicar de nuevo. Si el botón de deshacer, los selectores y la estructura general cambian en cada pantalla, cada tutorial empieza desde cero. Si el shell es estable, el onboarding puede concentrarse en la mecánica que realmente diferencia al juego.
CI comprueba además que los juegos no se publiquen sin cobertura. Estamos intentando convertir una expectativa de UX en una regla verificable del repositorio.
El blog y el devlog nos obligan a mantener memoria
El rediseño editorial no es solo una cuestión de publicar más. Queremos que el proyecto pueda explicar por qué existe cada capa.
El Journal recoge decisiones que necesitan contexto largo. El devlog registra cambios más pequeños. Devlog conecta hitos y prioridades. Git aporta hechos verificables sobre lo que realmente cambió. Juntos forman una memoria que resulta útil tanto para quien sigue el proyecto como para nosotros mismos.
La nueva home de Blupoli refuerza esa idea al dar al contenido editorial un acceso propio. Y la futura separación en blog.blupoli.com permitirá que esa memoria siga creciendo aunque Puzzles cambie su navegación.
- navegación móvil con comportamiento accesible;
- footer responsive compartido;
- controles de juego mayores y coherentes por breakpoint;
- modo claro/oscuro persistente y respetuoso con el sistema;
- tokens visuales en lugar de dependencias de un fondo concreto;
- separación entre navegación de producto y navegación editorial;
- home de marca independiente;
- roadmap público de alto nivel;
- CSP ajustada a la funcionalidad real sin permisos innecesarios.
Las mejoras transversales son menos visibles y más rentables
Si mañana añadimos otro puzzle, podremos hacer una captura y enseñarlo. Es un cambio muy fácil de comunicar. Mejorar un breakpoint, una política de scripts o la semántica del menú es menos espectacular.
Sin embargo, esas son las tareas que más rendimiento producen cuando el catálogo ya es grande. Una mejora en el shell puede llegar a setenta y seis juegos. Una regla de CI puede impedir setenta y seis futuros fallos. Una decisión de navegación puede reducir ruido en todas las páginas.
Estamos entrando en una etapa donde el crecimiento de PuzzleHub se medirá cada vez menos por cuántas tarjetas nuevas aparecen y más por cuánto trabajo repetido conseguimos eliminar.
Una plataforma usable es la que puede seguir creciendo sin volverse más pesada
La meta de todo este trabajo no es dejar la web «terminada». Es conseguir que el siguiente cambio cueste menos en lugar de más.
Si añadir un producto obliga a rehacer la home, algo falla. Si añadir un tema obliga a editar cien colores manualmente, algo falla. Si cada juego necesita un menú móvil distinto, algo falla. Si mover el blog rompe el producto, las fronteras estaban mal definidas.
Responsive, temas, navegación, roadmap y separación editorial parecen tareas distintas porque aparecen en archivos diferentes. En realidad responden a la misma pregunta: ¿cómo hacemos que un sistema grande conserve claridad?
La respuesta que estamos probando es sencilla de describir y difícil de ejecutar: compartir comportamiento, mantener fronteras explícitas y dejar que cada mecánica conserve su identidad.
Eso es lo que convierte una colección de juegos en una plataforma. No el contador del catálogo, sino la capacidad de cambiar una pieza sin tener que volver a aprender cómo funciona todo lo demás.