L’édition complète du site (FSE) Programme de sensibilisation a maintenant conclu sa première série de tests. Son premier domaine d’intervention était centré sur le mode d’édition de modèle introduit dans Gutenberg 9.6. Les volontaires impliqués dans le projet ont identifié plusieurs points faibles.
Gutenberg 9.6 a ajouté un nouveau bouton qui permet aux utilisateurs finaux, à condition qu’ils utilisent un thème basé sur des blocs, de basculer entre l’édition de leur publication et le modèle qui affiche la publication. As Josepha Haden dit l’année dernière, l’objectif ultime est de «se regrouper en une seule et belle interface intuitive». Essentiellement, cette nouvelle fonctionnalité fusionne le contenu et la conception d’une manière que nous n’avions jamais vue dans le cœur de WordPress auparavant. C’est un pas vers ce noble objectif.
Traditionnellement, WordPress a toujours séparé le contenu du design. Cependant, ces deux aspects des sites Web fusionnent continuellement. Il y a un désir pour cela. L’adoption des constructeurs de pages au cours de la dernière demi-décennie a été très claire.
Le plus gros problème avec ce nouveau mode de modèle est que les utilisateurs ont besoin d’une connaissance pratique du système de modèles WordPress pour comprendre les ramifications de leurs modifications. L’une des principales questions du domaine d’intervention était de savoir s’il était clair que l’utilisateur apportait des modifications à grande échelle à tous les articles lors du passage au mode d’édition de modèle.
« Je pense que l’impact de ces changements sur le site n’était pas assez clair » a écrit Héctor Prieto en réponse. « Si vous ne savez pas déjà comment fonctionnent les modèles, les éléments de modèle et les blocs globaux tels que le titre du site, vous ne comprendrez peut-être pas comment vos modifications affecteront le reste du site. »
Le changement de mode crée une fenêtre contextuelle rapide en bas à gauche de l’écran qui lit:
Modification du modèle. Les modifications apportées ici affectent tous les articles et pages qui utilisent le modèle.
Il est facile de le rater avant qu’il ne disparaisse. Il y a un ticket pour coller ce message sur l’écran et autorisez l’utilisateur à le rejeter. Il existe également un autre ticket pour clarifier quand un utilisateur est modification d’un modèle par rapport au contenu.
La méthode actuelle de Gutenberg est différente de ce que vous pourriez voir dans un constructeur de page typique. Lors du passage en mode d’édition de modèle, l’utilisateur n’édite plus la sortie frontale de ce message unique. Au lieu de cela, ils font des modifications globales. Un constructeur de page enregistre généralement toutes les personnalisations sur cette page uniquement. Si cela reste le même, cela pourrait être un obstacle pour l’utilisateur moyen à surmonter.
Une fonction de création de modèle doit faire partie de ce nouveau mode. Les utilisateurs doivent pouvoir créer un fork ou cloner leur modèle de publication unique existant et l’enregistrer en tant que nouveau modèle spécifique à ce message. Ou peut-être leur donner un moyen de l’enregistrer en tant que modèle réutilisable (par exemple, modèle de «page»). Paal Joachim Romdahl a partagé une pensée similaire, en le comparant à la fonction «Enregistrer sous…» que l’on trouve couramment dans les programmes informatiques.
Je me demande si les utilisateurs devraient être en mesure de modifier des modèles globaux tout en modifiant un seul article. Les deux ne sont liés que dans la mesure où le modèle affiche le contenu de l’article sur le front-end. WordPress devrait explorer tout type de travail de conception à partir de l’écran de post-édition en tant que, avant tout, spécifique à cet article.
Les bénévoles ont également identifié d’autres problèmes. L’application des modifications au modèle et l’enregistrement ramène l’utilisateur dans l’éditeur de publication. Le bouton «Annuler» est difficile à trouver – il se trouve dans un emplacement différent de celui où l’utilisateur a cliqué pour passer en mode d’édition de modèle.
Basculer entre l’édition de messages et de modèles ressemble à un type de chose FSE 2.0. L’équipe de développement a suffisamment de problèmes avec l’éditeur de site normal. C’est loin d’être un produit viable et prêt pour la production. L’objectif de l’équipe devrait être de résoudre les problèmes de ce système avant de le fusionner avec l’éditeur de publication. Rampez avant de marcher. Marchez avant de courir.
Cependant, je suis prêt à être agréablement surpris. À long terme, ce sera probablement une bonne chose que nous ayons un aperçu rapide de ce à quoi ces deux éléments différents de WordPress ressembleront en travaillant ensemble.
C’est également pourquoi la participation au programme de sensibilisation FSE est vitale. La communauté a besoin de ce type de processus plus formel pour identifier les domaines à améliorer.
Source link