Hier, Josepha Haden Chomphosy a annoncé la feuille de route pour décider si l’édition complète du site (FSE) atterrira dans WordPress 5.8. Après le lancement de Gutenberg 10.4 le 14 avril, un petit groupe de chefs de file participera à une démo go / no-go.
Les personnes suivantes seront à l’appel :
- Matias Ventura – Chef de projet Gutenberg qui animera la démo
- Matt Mullenweg – Chef de projet WordPress
- Helen Hou-Sandì – Développeur principal
- Josepha Haden Chomphosy – Directrice exécutive
L’ordre du jour de la réunion est simple. Ventura accueillera la démonstration, et le groupe discutera et couvrira les questions de mise en œuvre.
S’il n’y a pas de bloqueurs, ils partageront un plan pour fusionner FSE dans WordPress. Le résultat le plus probable est qu’ils trouveront au moins quelques éléments qui doivent être traités. Dans ce cas, ils les partageront publiquement avec un plan pour les aborder avant une deuxième date de non-départ le 27 avril.
La première version bêta de WordPress 5.8 est prévue pour le 8 juin, avec une version grand public pour le 20 juillet. L’équipe doit décider de l’inclusion au début du cycle de publication pour donner aux développeurs de thèmes et d’extensions le temps de se préparer.
Alors que beaucoup sont sur leurs gardes en attendant une décision finale, tout le monde doit avoir un peu de patience pour le moment. Tout doit être soigneusement pesé par les chefs de projet. Il y a de fortes chances que nous ne connaîtrons pas le résultat avant cette deuxième date limite du 27 avril.
La majeure partie de la transition FSE serait une exécution bêta pour un sous-ensemble d’utilisateurs. Inclure ces fonctionnalités dans le noyau ne signifie pas que WordPress bascule immédiatement le commutateur et active tout pour 40% du Web. Pour l’expérience FSE globale, les utilisateurs doivent faire un choix explicite pour installer et activer un thème basé sur des blocs.
Dans cet esprit, l’expérience d’intégration doit être accueillante qui invite les utilisateurs à modifier le site tout en leur faisant connaître les problèmes potentiels. S’il s’agit d’une version bêta intégrée, ils doivent vraiment comprendre que des améliorations sont à venir.
Une version bêta intégrée comme celle-ci est également la bienvenue, étant donné le lancement de l’éditeur de blocs par le projet il y a quelques années. Peu importe si les gens ont aimé ou détesté l’éditeur de blocs, le déploiement n’a pas été facile pour tout le monde. WordPress a plongé les utilisateurs finaux dans un système remanié, ce qui a été un changement choquant pour beaucoup. Le projet a une chance de faire mieux cette fois-ci en introduisant progressivement des fonctionnalités aux utilisateurs et en permettant aux autres de se plonger dans la nouvelle expérience de leur propre choix.
«Le contexte le plus important à partager est que ce n’est pas la livraison en tant qu’expérience complète par défaut pour les utilisateurs», A écrit Chomphosy dans le post, notant que l’équipe grandit au-delà des erreurs du passé. « L’un des retours les plus clairs du processus de fusion de Phase One était que nos extensions (agences, auteurs de thèmes, développeurs de plugins, créateurs de sites, etc.) n’avaient pas assez de temps pour se préparer aux changements à venir. »
Les décideurs peuvent également décider d’expédier certaines pièces mais pas d’autres. FSE est un projet composé de plusieurs composants.
«L’ensemble du projet d’édition de site complet est en quelque sorte un terme générique pour une collection d’outils et de projets, il serait donc possible que certaines pièces soient expédiées tandis que d’autres ne le font pas», a déclaré Haden Chomphosy. « Il y a probablement quelques exceptions à cela, comme vous l’avez mentionné, mais beaucoup d’entre elles peuvent être expédiées dès qu’elles sont prêtes. »
Les exceptions auxquelles elle faisait référence sont des éléments qui ont plus de sens ensemble. Par exemple, les thèmes basés sur des blocs via un fichier de configuration theme.json et la plupart des blocs d’édition de site ne sont pas aussi utiles lorsqu’ils sont séparés.
Bien sûr, il existe des cas où quelque chose comme le bloc Requête pourrait être utilisé en dehors de l’éditeur du site. Les utilisateurs peuvent créer des requêtes personnalisées dans une page sans bénéficier de l’éditeur de site, par exemple.
Ma principale préoccupation ne concerne pas les fonctionnalités liées à l’éditeur de site, mais les widgets basés sur des blocs. C’est un outil de transition pour les utilisateurs sur des thèmes traditionnels. Avec le nouvel écran des menus de navigation, il ne fait pas partie de l’expérience des thèmes basés sur des blocs. L’objectif est de permettre aux utilisateurs de commencer à utiliser des blocs dans plus d’endroits. Cependant, cela entraînera une rupture de l’UX dans de nombreux cas.
L’expérience des widgets est encore partiellement interrompue, traitant chaque bloc comme un widget séparé. Les utilisateurs doivent apprendre à mettre un titre (titre du widget) et un autre bloc (contenu du widget) dans un groupe (wrapper de widget) pour les classes appropriées liées aux widgets sur le front-end du site. Pour certains thèmes, le fait que les utilisateurs le fassent ne sera pas un problème. Pour d’autres, cela aura l’air moche au mieux et au pire cassera la mise en page. Mettre cette responsabilité sur les épaules des utilisateurs finaux a été considéré comme une solution acceptable.
Je voulais me concentrer sur ce problème car c’est l’une de ces choses qui peuvent simplement être inversées pour tous les utilisateurs. J’ai toujours peur que la transition d’un système fonctionnel à un système potentiellement cassé ne conduise à une conduite cahoteuse.
L’équipe de publication de WordPress 5.6 a décidé de ne pas livrer de widgets basés sur des blocs. Hou-Sandì, en tant que chef de file de la technologie de base pour la version 5.6, a fourni un compte rendu historique de la décision et des raisons pour lesquelles elle n’était pas prête à être incluse :
Ma question pour les fonctionnalités qui affectent le front-end est « puis-je essayer cette nouvelle chose sans risquer de gâcher mon site? » – c’est-à-dire la confiance des utilisateurs. En ce moment, étant donné que les zones de widgets ne sont pas affichées comme ce que vous voyez sur votre site sans que les thèmes y mettent vraiment des efforts et que vous devez enregistrer vos modifications en direct sans révisions pour obtenir une vue contextuelle réelle, les blocs de zones de widgets ne le font pas. vous permettent d’essayer cette nouvelle fonctionnalité sans vous pénaliser pour l’expérimentation.
Bien que les widgets se soient sans doute améliorés, je vois toujours la réponse comme étant la même qu’en octobre dernier. Je n’ai pas vu assez d’adhésion de la communauté de développement de thèmes pour prendre en charge l’éditeur de blocs lui-même, et encore moins les nouvelles fonctionnalités liées aux blocs. Cependant, à un moment donné, le projet doit simplement avancer. Ils auront juste besoin de suivre le rythme.
Comme ça :
J’aime chargement..