Thèmes du futur : un cadre de conception et un thème principal

Le thème WordPress a une histoire riche. Au fil des ans, les auteurs de thèmes ont apporté une pléthore de fonctionnalités à la plate-forme. C'est en partie parce qu'ils ont souvent dû résoudre des problèmes fondamentaux avec WordPress pour créer les fonctionnalités souhaitées par les utilisateurs finaux.

Les classes post et body que tous les auteurs de thèmes utilisent aujourd'hui ? Ceux-ci étaient à l'origine dans un thème appelé Sandbox.

Images en vedette ? Ceux-ci ont été popularisés par des thèmes de magazines il y a une décennie.

Vous pensez que les formats de publication sont originaires de Tumblr ? Matt Mullenweg, co-créateur de WordPress, nous a appris à créer des articles de côté dans nos thèmes en 2004, mais ils existaient avant cela.

Les fonctionnalités de WordPress font souvent leurs débuts dans le monde des thèmes. Nous tenons parfois pour acquises les années d'expérimentation et d'itération sur des idées que les auteurs de thèmes mettent au travail. Même l'éditeur de blocs gère des éléments qui faisaient traditionnellement partie du domaine de la conception de thèmes. Le bloc de couverture en est un bon exemple. Pendant des années, les auteurs de thèmes ont créé des options de thème pour une image de héros de base avec du texte et des boutons superposés. Le résultat était souvent maladroit et pas idéal pour les utilisateurs. En intégrant cette fonctionnalité au cœur, les utilisateurs ont la possibilité de placer ce bloc de couverture dans n'importe quelle zone de bloc autorisée.

La raison pour laquelle de nombreuses fonctionnalités de thème sont intégrées au cœur est qu'elles fonctionnent simplement mieux lorsqu'elles sont standardisées. Les utilisateurs savent à quoi s'attendre et les auteurs de thèmes peuvent se concentrer sur l'aspect design plutôt que sur la résolution du problème d'expérience utilisateur.

Une partie du problème du passé est que chaque nouvelle fonctionnalité adoptée dans le noyau ne suivait aucun modèle de conception standard ou schéma de dénomination. Une grande compétence dans la conception de thèmes WordPress consiste à mémoriser le méli-mélo de centaines de classes.

L'éditeur de blocs est dans une position unique pour changer cela en créant un cadre de conception universel.

WordPress a-t-il besoin d'un cadre de conception frontal ?

Avec les modèles de blocs à venir et la personnalisation complète du site à un moment donné, les auteurs de thèmes se demandent exactement où ce navire navigue. C'est excitant parce que les possibilités sont illimitées pour les utilisateurs finaux. C'est effrayant pour les auteurs de thèmes qui ont construit leurs empires sur une seule façon de faire les choses, mais le développement est plus une question d'adaptation qu'autre chose.

Armés de la prescience que le paysage est en train de changer, c'est le moment où les auteurs de thèmes doivent s'unir pour façonner leur avenir dans un monde basé sur les blocs.

Il y a une petite blague dans l'un des groupes de développeurs dans lesquels je suis impliqué, à savoir que les développeurs principaux ne sont pas des auteurs de thèmes. Du point de vue de l'auteur du thème, il peut parfois sembler que les idées sont lancées au hasard sans aucune réflexion sur les systèmes de conception CSS.

Oh, je vois des BEM. Pourquoi ce sous-élément ne suit-il pas le même schéma de nommage ? Attendez. Est-ce une classe utilitaire de 38 caractères ?

Ce qui a toujours manqué à WordPress, c'est un système de conception frontal universel. Parfois, cela a été une bonne chose. Il a permis aux auteurs de thèmes d'utiliser leur cadre préféré. Tout auteur de thème qui est dans le jeu depuis assez longtemps vous le dira, ce genre de flexibilité est génial… jusqu'à ce que ce ne soit pas le cas . Avez-vous déjà essayé d'ajouter des classes contextuelles aux widgets ? Qu'en est-il de l'ajout d'une classe utilitaire au wrapper de formulaire de commentaire ? Vous aurez besoin d'une aspirine. Ou deux.

Avec WordPress, certaines choses sont gravées dans le marbre et d'autres sont enfichables. Certaines fonctionnalités suivent un schéma de dénomination de classe standard et d'autres n'ont aucun sens. Le résultat pour les thèmes est souvent un CSS gonflé dans une tentative de brouiller les différents composants.

Il est presque impossible d'utiliser pleinement un framework de classe utilitaire comme Tailwind CSS dans un thème sans recréer les fonctionnalités de base.

Une grande partie de cela découle d'années d'accumulation de code hérité et de l'engagement de WordPress en matière de compatibilité descendante. Mais l'avenir n'a pas à ressembler au passé. Nous sommes au seuil d'une nouvelle ère, et il est maintenant temps pour les concepteurs front-end de se lancer dans la conversation.

WordPress a besoin d'un cadre de conception frontal solide.

C'est une déclaration chargée. Si vous mettez 20 designers dans une pièce et leur demandez de discuter des cadres de conception, cela pourrait être une recette pour des coups de poing. J'ai tendance à être optimiste et j'espère que le débat a donné des résultats.

Gutenberg nous a partiellement poussés dans cette direction, mais cela ne va pas assez loin. Avec l'édition complète du site à l'avenir, il est nécessaire d'adopter une approche plus holistique pour résoudre ce problème.

Plus que tout, nous avons besoin de plus de concepteurs frontaux dans la conversation. Il n'y a aucun moyen que .has-subtle-pale-green-background-color existe en tant que classe utilitaire sur quelque chose comme .bg-pale-green , .bg-green-100 ou même .background-pale-green , si vous vouloir être plus verbeux. Il n'y avait aucun concept d'optimisation dans cette décision. À une époque où les développeurs utilisent des connexions Internet gigabit, il est facile d'oublier qu'une grande partie du monde suit à un rythme plus lent.

Un schéma de nommage basé sur les composants avec une bonne dose de classes d'utilité est une option qui pourrait toucher plusieurs zones idéales. Ce n'est pas un argument en faveur d'un framework CSS plutôt qu'un autre. Il existe de nombreuses bonnes options existantes. WordPress devrait s'attaquer à ce problème en empruntant aux bases établies par d'autres projets et en créant quelque chose d'unique WordPress. Il devrait être un chef de file dans le domaine.

Les frameworks de conception concernent également les plugins. Il y a un croisement dans le domaine des thèmes où les deux se livrent une guerre continue depuis l'aube du système de thèmes. Le champ de bataille entre thèmes et plugins est jonché de morts de bonnes idées. Beaucoup trop d'entre eux n'ont jamais obtenu le soutien dont ils avaient besoin pour atterrir dans le noyau. Une sorte de norme de conception universelle pourrait calmer le flot de problèmes et appeler à un cessez-le-feu.

Un plugin qui produit un composant frontal personnalisé n'a aucun moyen de savoir comment le thème actuel gère le rythme vertical, par exemple. Utilise-t-il la marge supérieure ou inférieure ? Quelle est la valeur et l'unité utilisée ? C'est un élément fondamental, et il est presque toujours cassé lorsque le plugin tente d'ajouter un CSS personnalisé pour le gérer.

WordPress a besoin d'un cadre de conception, ou d'un langage, qui permet à toutes ses parties mobiles de s'assembler en harmonie sur le front-end. Je suis sûr que nous y arriverons à un moment donné. J'espère qu'il est plus cohérent que les composants aléatoires et les schémas de nommage du passé. Nous devrions également avoir une feuille de route claire qui renseigne certains détails techniques afin que les développeurs et les concepteurs puissent être préparés.

Un avenir à thème unique est-il possible ?

Rich Tabor fait valoir que le cœur de WordPress pourrait fournir un thème parent unique dans son article A Look at WordPress Themes of the Future. L'idée est que les auteurs de thèmes seraient relégués à créer un thème enfant pour ce thème "maître".

La réaction instinctive de beaucoup serait que cela ne fonctionnerait pas, les thèmes perdraient leur personnalité et nous vivrions dans un monde de conceptions à l'emporte-pièce.

La réalité est que nous nous dirigeons vers un avenir où l'idée d'un parent unique ou d'un thème principal est une considération sérieuse.

La plupart des thèmes sont des regroupements personnalisés d'éléments standard qui existent dans presque tous les thèmes. Certaines décisions, en dehors des préoccupations stylistiques, rendent les thèmes différents les uns des autres, comme la disposition de l'en-tête. Un thème peut avoir un titre de site et un menu de navigation dans un bloc. Un autre pourrait avoir un menu de navigation, un titre et un deuxième menu de navigation ci-dessous. Pourtant, un autre thème peut afficher un champ de recherche. Dans un monde où la personnalisation complète du site appartient à l'utilisateur, ces décisions font partie de l'expérience utilisateur plutôt que de l'expérience du développeur.

Les thèmes devront se démarquer avec des palettes de couleurs, une typographie et leur propre marque de bizarrerie - un retour de l'époque de CSS Zen Garden mais à une échelle beaucoup plus grande.

Je ne serai pas triste à ce sujet. Il serait intéressant de voir la compétition entre les meilleurs designers du domaine. Cela peut également ramener le thème WordPress à une époque où n'importe qui pouvait le faire avec un peu de connaissance et de détermination CSS.

Bien que nous ne soyons pas tout à fait prêts pour un avenir dans lequel un thème domine tout, c'est un endroit pour commencer la conversation. Si nous concevons WordPress pour ce futur potentiel, même si nous n'implémentons jamais de thème maître, à quoi ressemblerait la feuille de route ? Quels obstacles se dressent sur le chemin ? Est-ce faisable ?