Traducido del artículo: “Themes of the Future: A Design Framework and a Master Theme” de:

Justin Tadlock, noviembre 8 de 2019

El tema de WordPress tiene una rica historia. Con los años, los autores del tema han aportado una gran cantidad de características a la plataforma. En parte, porque a menudo han tenido que resolver problemas fundamentales con WordPress para crear las funciones que los usuarios finales desean.
¿Las clases post y body que todos los autores de temas usan hoy? Esos fueron originalmente un tema llamado Sandbox.
¿Imágenes destacadas? Esas fueron popularizadas por temas de revistas hace una década.
¿Cree que los formatos de publicación se originaron con Tumblr? Matt Mullenweg, cocreador de WordPress, nos enseñó cómo crear publicaciones aparte en nuestros temas en 2004, pero existían antes de eso.

Las funciones de WordPress a menudo comienzan en el mundo de los temas. A veces damos por sentados los años de experimentación e iteración de ideas en las que los autores de los temas están trabajando. Incluso el editor de bloques maneja elementos que tradicionalmente han estado dentro del ámbito del diseño de temas. El bloque de cubierta es un buen ejemplo. Durante años, los autores del tema crearon opciones de tema para una imagen de héroe básica con texto y botones superpuestos. El resultado fue a menudo torpe y no ideal para los usuarios. Al incorporar esta característica al núcleo, brindó a los usuarios la capacidad de colocar este bloque de cobertura en cualquier área de bloque permitida.

La razón por la que muchas características del tema llegan al núcleo es que simplemente funcionan mejor cuando están estandarizadas. Los usuarios saben qué esperar y los autores de los temas pueden centrarse en el aspecto del diseño en lugar de resolver el problema de la experiencia del usuario.
Parte del problema del pasado es que cada nueva característica adoptada en el núcleo no siguió ningún patrón de diseño estándar o esquema de nomenclatura. Una gran habilidad en el diseño de temas de WordPress es guardar la mezcla de cientos de clases en la memoria.
El editor de bloques está en una posición única para cambiar eso creando un marco de diseño universal.

¿WordPress necesita un marco de diseño front-end?
Con los patrones de bloques en el futuro y la personalización del sitio completo en algún momento después de eso, los autores del tema se preguntan exactamente dónde está navegando este barco. Es emocionante porque las posibilidades son ilimitadas para los usuarios finales. Es aterrador para los autores de temas que han construido sus imperios sobre una forma de hacer las cosas, pero el desarrollo tiene más que ver con la adaptación que con cualquier otra cosa.

Armado con el conocimiento previo de que el paisaje está cambiando, este es el momento en que los autores del tema deben unirse para dar forma a su futuro en un mundo basado en bloques.
Hay una pequeña broma en uno de los grupos de desarrolladores en los que estoy involucrado y es que los desarrolladores principales no son autores de temas. Desde la perspectiva del autor del tema, a veces puede parecer que las ideas se unen al azar sin pensar en los sistemas de diseño CSS.
Oh, veo algo de BEM. ¿Por qué este sub elemento no sigue el mismo esquema de nombres? Espere. ¿Es esa una clase de utilidad de 38 caracteres?

De lo que WordPress siempre ha carecido es de un sistema de diseño frontal universal. A veces, eso ha sido algo bueno. Ha permitido a los autores de los temas utilizar su marco preferido. Cualquier autor de temas que haya estado en el juego el tiempo suficiente te dirá que ese tipo de flexibilidad es genial … hasta que no lo sea. ¿Alguna vez has intentado agregar clases contextuales a widgets? ¿Qué pasa con la adición de una clase de utilidad al contenedor de formulario de comentarios? Necesitarás una aspirina. O dos.

Con WordPress, algunas cosas se establecen en piedra y otras son conectables. Algunas características siguen un esquema de denominación de clase estándar y otras no tienen sentido. El resultado para los temas a menudo es CSS hinchado en un intento de disputar los diversos componentes.
Es casi imposible usar completamente un marco de clase de utilidad como Tailwind CSS en un tema sin recrear las características principales.
Gran parte de esto se debe a años de acumulación de código heredado y al compromiso de WordPress con la compatibilidad con versiones anteriores. Pero, el futuro no tiene que parecerse al pasado. Estamos en el umbral de una nueva era, y ahora es el momento para que los diseñadores de front-end salten a la conversación.
WordPress necesita un marco de diseño de front-end sólido.
Esa es una declaración pesada. Si pones a 20 diseñadores en una habitación y les pides que discutan los marcos de diseño, podría ser una invitación para puñetazos. Tiendo a ser optimista y espero que el debate haya dado resultados.

Gutenberg nos ha empujado parcialmente en esta dirección, pero no llega lo suficientemente lejos. Con la edición completa del sitio en el futuro, existe la necesidad de un enfoque más holístico para abordar este problema.
Más que nada, necesitamos más diseñadores front-end en la conversación. No hay forma de que .has-sutil-pale-green-background-color (color de fondo verde sutil) deba existir como una clase de utilidad sobre algo como .bg-pale-green (verde pálido), .bg-green-100 (verde 100) , o incluso .background-pale-green (fondo verde pálido), si usted quiere ser más detallado. No había ningún concepto de optimización que entrara en esa decisión. En un momento en que los desarrolladores “corren” en conexiones de Internet de gigabits, es fácil olvidar que gran parte del mundo siga a un ritmo más lento.

Un esquema de nomenclatura basado en componentes con una buena dosis de clases de utilidad es una opción que podría llegar a varios puntos clave. Este no es un argumento para un marco CSS sobre otro. Hay muchas buenas opciones existentes. WordPress debería abordar este problema tomando prestado el trabajo preliminar establecido por otros proyectos y creando algo exclusivo de WordPress. Debería ser un líder en el campo.

Los marcos de diseño también tratan sobre complementos. Hay algunos cruces en el ámbito de los temas donde los dos han estado librando una guerra en curso desde los albores del sistema de temas. El campo de batalla entre temas y complementos está plagado de muertes de buenas ideas. Muchos nunca obtuvieron el apoyo que necesitaban para aterrizar en el núcleo. Algún tipo de estándar de diseño universal podría detener la avalancha de problemas y exigir un alto el fuego.
Un complemento que genera un componente front-end personalizado no tiene forma de saber cómo el tema actual maneja el ritmo vertical, por ejemplo. ¿Utiliza el margen superior o inferior? ¿Cuál es el valor y la unidad utilizada? Esto es fundamental, y casi siempre se rompe cuando el complemento intenta agregar CSS personalizado para manejarlo.
WordPress necesita un marco de diseño, o lenguaje, que permita que todas sus partes móviles se unan en armonía en la parte frontal. Estoy seguro de que llegaremos allí en algún momento. Espero que sea más coherente que los componentes aleatorios y los esquemas de nombres del pasado. También deberíamos tener una hoja de ruta clara que complete algunos de los detalles técnicos para que los desarrolladores y diseñadores puedan estar preparados.

¿Es posible un futuro de un tema?
Rich Tabor argumenta que el núcleo de WordPress podría proporcionar un tema principal único en su artículo Una mirada a los temas del futuro de WordPress. La idea es que los autores del tema se releguen a la creación de un tema secundario para este tema “maestro”.
La reacción instintiva para muchos sería que no funcionaría, los temas perderían su personalidad y viviríamos en un mundo de diseños para cortar galletas.
La realidad es que nos estamos precipitando hacia un futuro donde la idea de un padre soltero o tema principal es una consideración seria.
La mayoría de los temas son agrupaciones personalizadas de elementos estándar que existen en casi todos los temas. Hay algunas decisiones, aparte de las preocupaciones estilísticas, que hacen que los temas sean diferentes entre sí, como el diseño del encabezado. Un tema puede tener un título de sitio y un menú de navegación en un bloque. Otro podría tener un menú de navegación, título y un segundo menú de navegación a continuación. Sin embargo, otro tema podría mostrar un cuadro de búsqueda. En un mundo donde la personalización del sitio completo pertenece al usuario, esas decisiones se vuelven parte de la experiencia del usuario en lugar de la experiencia del desarrollador.
Los temas deberán destacarse con paletas de colores, tipografía y su propia peculiaridad: un regreso de los días de CSS Zen Garden pero a una escala mucho mayor.

No voy a estar triste por eso. Sería interesante ver la competencia entre los mejores diseñadores en el campo. También puede devolver el tema de WordPress a una era en la que cualquiera podría hacerlo con un poco de conocimiento y determinación de CSS.
Si bien no estamos listos para un futuro en el que un tema rige todo, es un lugar para comenzar la conversación. Si diseñáramos WordPress para este futuro potencial, incluso si nunca implementamos un tema maestro, ¿cómo sería la hoja de ruta? ¿Qué obstáculos se interponen en el camino? ¿Es factible?

Quién es Justin Tadlock

Justin Tadlock es desarrollador, diseñador y escritor. Es un ganador del Mes Nacional de Escritura de Novelas. Ha trabajado con WordPress de alguna forma desde 2005. También tiene muchos gatos, pollos y patos.