Temas del futuro: un marco de diseño y un tema maestro

La tematización de WordPress tiene una rica historia. A lo largo de los años, los autores de temas han aportado una gran cantidad de funciones a la plataforma. En parte, se debe a que a menudo han tenido que resolver problemas fundamentales con WordPress para crear las funciones que desean los usuarios finales.

¿Las clases de publicación y cuerpo que todos los autores de temas usan hoy en día? Esos estaban originalmente en un tema llamado Sandbox.

¿Imágenes destacadas? Esos fueron popularizados por temas de revistas hace una década.

¿Crees que los formatos de publicación se originaron con Tumblr? Matt Mullenweg, co-creador de WordPress, nos enseñó cómo crear publicaciones aparte en nuestros temas en 2004, pero existían antes de eso.

Las características de WordPress a menudo comienzan en el mundo de los temas. A veces damos por sentado los años de experimentación e iteración de ideas en las que los autores temáticos 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 la cubierta es un buen ejemplo. Durante años, los autores de temas crearon opciones de temas para una imagen principal básica con texto y botones superpuestos. El resultado era a menudo torpe y no ideal para los usuarios. Al llevar esta función al núcleo, proporcionó 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 de los temas llegan al núcleo es que simplemente funcionan mejor cuando están estandarizadas. Los usuarios saben qué esperar y los autores de 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 característica nueva adoptada en el núcleo no seguía ningún patrón de diseño o esquema de nombres estándar. Una gran habilidad en el diseño de temas de WordPress es memorizar la mezcolanza de cientos de clases.

El editor de bloques está en una posición única para cambiar eso mediante la creación de 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 de temas se preguntan exactamente hacia dónde navega 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.

Armados con el conocimiento previo de que el panorama está cambiando, este es el momento en que los autores de temas 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 participo de que los desarrolladores principales no son autores de temas. Desde la perspectiva del autor del tema, a veces puede parecer que las ideas se juntan al azar sin pensar en los sistemas de diseño CSS.

Oh, veo algo de BEM. ¿Por qué este subelemento no sigue el mismo esquema de nombres? Esperar. ¿Es esa una clase de utilidad de 38 caracteres?

Lo que a WordPress siempre le ha faltado es un sistema universal de diseño de front-end. A veces, eso ha sido algo bueno. Ha permitido a los autores de temas usar su marco preferido. Cualquier autor de temas que haya estado en el juego el tiempo suficiente le dirá que ese tipo de flexibilidad es genial... hasta que deja de serlo. ¿Alguna vez ha intentado agregar clases contextuales a los widgets? ¿Qué hay de agregar una clase de utilidad al envoltorio del formulario de comentarios? Necesitarás una aspirina. O dos.

Con WordPress, algunas cosas están grabadas en piedra y otras son conectables. Algunas características siguen un esquema de nomenclatura de clase estándar y otras no tienen sentido. El resultado de los temas suele ser un CSS inflado 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 de que los diseñadores front-end participen en la conversación.

WordPress necesita un marco de diseño front-end sólido.

Esa es una declaración cargada. Si pones a 20 diseñadores en una habitación y les pides que discutan los marcos de diseño, podría ser una receta para los 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 va lo suficientemente lejos. Con la edición de sitios completos 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-subtle-pale-green-background-color deba existir como una clase de utilidad sobre algo como .bg-pale-green , .bg-green-100 o incluso .background-pale-green , si quiero ser más detallado. No hubo ningún concepto de optimización en esa decisión. En una época en la que los desarrolladores funcionan con conexiones de Internet de gigabits, es fácil olvidar que gran parte del mundo lo sigue 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 alcanzar varios puntos óptimos. Este no es un argumento a favor de un marco CSS sobre otro. Hay muchas buenas opciones existentes. WordPress debería abordar esto de frente tomando prestadas las bases establecidas por otros proyectos y creando algo exclusivo de WordPress. Debe ser un líder en el campo.

Los marcos de diseño también se tratan de complementos. Hay un cruce en el reino 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. Demasiados 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 frontal personalizado no tiene forma de saber cómo el tema actual maneja el ritmo vertical, por ejemplo. ¿Utiliza 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 interfaz. Estoy seguro de que llegaremos allí en algún momento. Espero que sea más cohesivo 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 solo 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 de WordPress del futuro. La idea es que los autores de temas queden relegados a crear un tema secundario para este tema "maestro".

La reacción visceral de muchos sería que no funcionaría, los temas perderían su personalidad y viviríamos en un mundo de diseños prefabricados.

La realidad es que nos dirigimos hacia un futuro en el que la idea de un tema principal o maestro único 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, además 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, un título y un segundo menú de navegación debajo. 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 marca de extravagancia: un regreso a los días de CSS Zen Garden pero a una escala mucho mayor.

No estaré triste por eso. Sería interesante ver la competencia entre los mejores diseñadores en el campo. También puede devolver la temática de WordPress a una era en la que cualquiera podía hacerlo con un poco de conocimiento y determinación de CSS.

Si bien no estamos del todo preparados para un futuro en el que un tema lo gobierne todo, es un lugar para comenzar la conversación. Si diseñamos 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?