Pixel Imperfect.

Para ello definí un pequeño backlog inicial en el que pudiese ordenar las primeras ideas, pasos a seguir y poder priorizar los elementos iniciales. No obstante decidí que habría unas lineas entre las que me quería mantener y a la vez  me propuse los siguientes retos:

• Crear un diseño adaptado a mi backround fotográfico.
• Desarrollar un CMS desde cero con PHP.
• No usar bases de datos.
• Crear una sección privada con acceso restringido.
• Los fundamentos básicos del diseño deberían ser también administrables desde el CMS (Tipografías, colores, efectos, border-radius, etc).

Diseño

A finales de los 90 estudié fotografía en el IEFC de Barcelona. De ahí pasé a estudiar Diseño Gráfico pero el background fotográfico quedo ahí. Mis diseños siempre han tenido una gran base fotográfica y mis composiciones se ha basado en mis conocimientos fotográficos. Así decidí que mi nuevo proyecto debería tener una gran base fotográfica y preferiblemente en blanco y negro, como mucho bi-tono. Además me interesaba experimentar con filtros de desenfoque sobre las imágenes a fin de conseguir un efecto de superposición de cristales.

Para la selección de colores me inspiré en la imaginería constructivista: básicamente blanco, negro y rojo. Finalmente, en vez de usar rojo, opté por combinar un magenta y un naranja a modo de colores primario y secundario.

Hecho esto me puse manos a la obra y realicé con Figma las primeras pruebas. No quise perder demasiado tiempo en ello así que realicé solo los componentes básicos a fin de poder ponerme tan rápido como fuera posible con la programación de FE, para así poder ver los primeros resultados en un browser, que es para mi el entorno óptimo para hacer las primeras pruebas conceptuales. Ya hemos llegado al Front-End.

Front-End

Para la realización de proyectos responsive me gusta usar Bootstrap. Lo he usado durante muchos años y me siento realmente cómodo con él. Para la definición de los primeros componentes empecé usando una estructura de PHP que después me sirvió para poder visualizar todos los módulos y crear la guía de estilo. 

Para la edición de CSS partí de la estructura SASS de Bootstrap 5 en la que repliqué la estructura de componentes y módulos. De esta manera el proyecto se mantendría lo más ordenado posible.

El primer gran reto del proyecto fue la posibilidad de poder editar elementos del FE mediante el CMS. ¿Cómo podría hacerlo? La solución fue combinar las Custom Properties de CSS con un archivo de PHP que me sirvió de puente. Es decir: la administración envía los parámetros a un archivo css.php que escribe dinámicamente las custom properties que finalmente son utilizadas por toda la estructura de CSS. Simple.

A esta circunstancia le apareció un imprevisto: el diseño tenía una gran cantidad de degradados y fundidos, por lo que la mayoría de colores deberían ser definidos en RGB en lugar de hexadecimal. Hasta ahí todo correcto, pero resulta que si quería hacer una administración, el color picker de HTML define colores solo en hexadecimal. No hubo problema: el mismo archivo CSS.PHP que creaba las custom properties también se encargaba de de transformar los valores hexadecimales a RGB.

Content Management System

Bases de datos, ¿quién necesita eso? 

Hemos llegado a un punto en el que estamos usando herramientas sobredimensionadas para proyectos que no las necesitan, o mejor dicho: en muchos casos usamos CMS complejos para proyectos simples. A primera vista puede parecer que no hay ningún problema, pero los hay, y el primero es el rendimiento. Cada vez que vemos una página hecha por ejemplo con Wordpress, estamos ejecutando un archivo que según los parámetros que tenga envía una query a una base de datos y ésta le devuelve una información determinada que entonces es transformada en la página que queremos ver. Además de requerir más tiempo estamos haciendo un consumo de energía innecesario con lo que nuestros proyectos no son tan sostenibles como creemos.

Hay una alternativa al uso de CMS con bases de datos: los Flat-File CMS. Sistemas de administración que guardan los datos en archivos alojados en el mismo servidor que nuestro proyecto. Eso hace que el sistema, entre otras cosas, sea mucho más rápido. Pero lo cierto es que entre los Flat-File CMS existentes no he encontrado ninguno que acabe de adaptarse a mis necesidades. Por esta razón opté por crear mi propio Flat-File CMS.

Un “inconveniente” teórico de los Flat-Flie CMS es que, al definir contenido en archivos planos, no tienen la posibilidad de filtrado que tiene una base de datos. En este proyecto no es el caso: dado que los datos están almacenados en Objects de JSON.

Resumiendo un poco: El sistema está basado en dos tipos de archivos JSON. Unos son los archivos con datos estructurales. Los otros conforman la estructura de información del proyecto a través de una taxonomía común. Los archivos son leídos por la aplicación PHP que transforma su contenido en Objects que son manipulados según las necesidades de cada módulo. A través de la administración los Objects de JSON pueden ser leídos y re-escritos cada vez que hacemos una modificación o una página nueva. 

Un “inconveniente” teórico de los Flat-Flie CMS es que, al definir contenido en archivos planos, no tienen la posibilidad de filtrado que tiene una base de datos. En este proyecto no es el caso: dado que los datos están almacenados en Objects de JSON, los datos pueden ser manipulados y filtrados con facilidad. Por ejemplo es posible mostrar u ocultar contenido restringido o mostrar listas ordenadas por fecha de publicación.

Para las imágenes desarrollé una galería que trabaja con el sistema de archivos reales que hay en el servidor. Cada vez que cargamos imágenes en la galería el sistema se encarga de transformarlas a formato WebP, escalarlas a un máximo de 2000 píxeles de ancho y además crea una copia de 900 píxeles que es usada por ejemplo cuando las imágenes son mostradas en contenedores pequeños o para el meta-tag og:image (la miniatura que se muestra al compartir una página en redes sociales).

Trabajar con PHP me ha permitido otras características interesantes como la detección automática de idioma del usuario, el sistema de acceso a contenidos restringidos, los formularios o la propia administración del CMS.

El nombre del proyecto

¿El nombre?¿El dominio.ch?
Bueno, respecto al nombre, no hay mucho que explicar. Si eres de la rama IT ya sabrás lo que significa Pixel Perfect y el nombre del proyecto te habrá hecho sonreír. Pixel Imperfect es sencillamente un juego de palabras, una broma. 

Respecto al dominio suizo… bueno, ya había usado un dominio suizo en mi proyecto anterior y sencillamente… es cool!