.

Drupal à la recherche de la meilleure expérience éditoriale

L'expérience éditoriale devient de plus en plus importante pour chaque CMS. Les utilisateurs veulent plus de contrôle mais des interfaces plus simples. Dans Drupal, l'un des plus grands et des plus populaires CMS OpenSource sur le marché, la recherche de la meilleure expérience se poursuit jusqu'à aujourd'hui. Diverses approches sont testées par la communauté et à chaque édition, quelques nouvelles approches sont explorées et certaines sont abandonnées. Du point de vue d'une agence Drupal, il est assez intéressant de voir ce processus se dérouler.

Explorons comment l'expérience éditoriale de Drupal en est arrivée là et où elle se dirige.

Les débuts de Drupal

Initialement, les pages Drupal étaient construites sur des nœuds. Imaginez un nœud comme un article ou une page dans un CMS typique. Un nœud avait un titre et un corps. Vous intituliez le nœud et insériez tout le contenu dans un grand champ de texte. Typiquement, les gens tapaient dans le champ corps le contenu de la page - ce serait principalement du texte, mais vous pouviez y insérer tout ce que vous vouliez (HTML, images, etc.). Très vite, les gens ont intégré des éditeurs WYSIWYG dans le corps (CKEditor, TinyMCE et d'autres ont été intégrés comme modules communautaires). Vous pouviez désormais rédiger une page assez complexe sans connaissance de HTML.

Les WYSIWYG étaient si populaires, que dans Drupal 7, CKEditor a été intégré dans le noyau de Drupal.

Du côté de la base de données, tout était encore assez simple. Une table de nœuds avec un titre et une table supplémentaire pour le corps. C'est ainsi que WordPress est resté jusqu'à aujourd'hui. Dans Drupal cependant, l'évolution s'est poursuivie. 

Drupal 6 - la domination de CCK & le templating

À l'époque de Drupal 5, un module initialement petit a été créé, qui dans Drupal 6 a complètement changé les règles du jeu (le module Content Construction Kit, alias CCK).

CCK était un module contribué qui permettait d'ajouter des champs supplémentaires aux nœuds. Cela ne semble pas très excitant, mais ça l'était. Le module CCK absolument brillant permettait aux utilisateurs d'ajouter divers champs (nombre, texte, booléen, sélection, etc.) et il créait une table de base de données séparée pour chaque champ. Le champ de la table correspondait à ce que vous vouliez y stocker (un décimal, un flottant, un varchar, un texte, etc.). En plus de cela, il ajoutait le champ au formulaire de contenu par défaut. 

C'était magnifique parce que vous pouviez créer un formulaire avec plusieurs champs et ensuite afficher les données dans un modèle pré-construit par le développeur (une image à droite, des statistiques à gauche, de longs textes en bas — ce genre de choses). C'est ainsi qu'on construisait des pages dans Drupal. L'éditeur n'avait plus besoin de concevoir la mise en page dans un WYSIWYG. Vous pouviez simplement remplir un formulaire avec des champs et le modèle s'occupait du reste. 

De plus, vous pouviez désormais interroger en SQL des nœuds particuliers par le contenu du champ. Par exemple, si vous créiez un type de nœud Ville et ajoutiez un champ décimal de population, vous pouviez rechercher toutes les villes avec une population plus grande ou plus petite qu'un montant défini. 

Très rapidement après CCK, un autre module a été créé - le module Views. Views permettait aux utilisateurs de construire les requêtes dans l'interface d'administration. Vous pouviez désormais créer une liste de villes classées par population avec un titre, un aperçu et d'autres données sans avoir besoin de coder quoi que ce soit. C'était une percée massive qui permettait aux développeurs de créer des sites Web très convaincants sans écrire une ligne de code. 

CCK était si populaire qu'il a été intégré à Drupal dans la version 7 et Views a suivi dans Drupal 8.

C'est ainsi que les sites Web Drupal ont été construits pendant un certain temps. Beaucoup sont encore construits de cette façon aujourd'hui.

Drupal 7 - Premières tentatives de mises en page 

À partir de Drupal 7, les champs étaient considérés comme un standard. Le templating, cependant, ne suffisait plus pour la communauté et les clients. Les développeurs de Drupal ont commencé à chercher des solutions pour permettre plus de contrôle sur l'affichage du contenu avec juste l'UI.

La principale raison des efforts de recherche est la façon dont les sites Web ont commencé à être construits. La connaissance qu'un clic supplémentaire réduit la chance que le client accède au contenu se propageait. L'approche d'avoir une barre latérale et de diviser les informations en pages n'était plus intéressante. Les longues pages déroulantes étaient nées.

L'avènement des longues pages d'atterrissage avec du contenu en sections a commencé quelque part en 2010. C'était cependant le mobile qui a effectivement tué la barre latérale. Vous ne pouviez tout simplement pas insérer un sous-menu dans une barre latérale sur mobile. Vous deviez maintenant tout mettre sur une seule longue page déroulante avec plusieurs sections (faire défiler sur mobile est beaucoup plus facile que de cliquer sur des liens). Et chaque section devait être intéressante, attrayante et différente.

Les développeurs de Drupal ont commencé à chercher des solutions pour permettre aux éditeurs de créer des sections sur les pages plus facilement.

Les solutions initiales étaient :

  • Panelizer - un module basé sur un autre (Panels) qui prenait efficacement le contrôle de l'affichage du nœud. Au lieu de simples champs, vous pouviez désormais concevoir votre page pour inclure des blocs, des champs, des images statiques, des vues et divers autres éléments rendus par Drupal. Les éditeurs pouvaient remplacer la « mise en page par défaut » prédéfinie nœud par nœud. La solution était excellente et a obtenu beaucoup de traction dans le monde de Drupal.
  • Paragraphs - un peu en retard à la fête sur Drupal 7, Paragraphs a néanmoins fait sensation. Il a commencé à gagner en popularité très rapidement. La principale raison en était qu'il faisait le pont entre les 2 mondes : l'expérience de construction de formulaires Drupal et la liberté d'ajouter des blocs tout en maintenant la facilité d'utilisation pour les éditeurs, que les solutions ci-dessus n'avaient pas. 
  • Context - Context un module plus général, qui donnait aux utilisateurs un mécanisme pour bien - agir sur les contextes (par exemple sur quelle page vous êtes, quel utilisateur ou rôle vous avez, etc.). En utilisant ces conditions, on pouvait ajouter des réactions (par exemple, afficher ce bloc, définir ce paramètre). Context était très largement utilisé pendant un moment pour arranger les blocs sur les pages. Si je suis sur cette page, je veux voir ces blocs. L'inconvénient était que vous gérez les mises en page depuis un emplacement central, vous aviez besoin de privilèges d'administrateur pour gérer les mises en page et l'interface utilisateur n'était pas simple. Pas adapté aux grands sites Web.
  • Blockreference - un module simple mais puissant qui permet la référence de blocs à partir d'un nœud et les empile effectivement les uns sur les autres. Cette solution n'a pas obtenu beaucoup de traction.


État actuel dans Drupal 8 et au-delà

Drupal 8, étant une réécriture très importante de Drupal, a nivelé un peu le terrain de jeu, permettant à la communauté de voter à nouveau sur ce qu'elle pense devrait être l'approche pour construire des pages. 

Blockreference n'a pas obtenu de version D8, principalement parce que le module entityreference était maintenant dans le noyau de Drupal 8 et les blocs sont devenus des références. On pourrait théoriquement construire des pages comme cela en utilisant ce que Drupal donne par défaut, mais cela n'a pas pris.

Context n'a pas réussi à rassembler beaucoup d'utilisations dans D8 et jusqu'à aujourd'hui n'a pas de version stable.

Paragraphs - gagnant initial

Le module Paragraphs est sorti comme un gagnant clair. Il était stable très rapidement et est devenu la norme de facto dans Drupal 8 pendant plus d'un an. Avec plus de 140k installations, il fait désormais fonctionner un tiers de tous les sites Drupal. Il est également intéressant de mentionner que les distributions populaires de Drupal créées sur Drupal 8 ont choisi Paragraphs comme base de leur expérience d'édition de contenu. Ce seraient en particulier Thunder - distribué pour les maisons d'édition et Droopler - pour la création de sites Web d'entreprise. 

Voici un aperçu de comment Paragraphs fonctionne dans Drupal 8. Beaucoup de travail est également en cours pour améliorer encore l'expérience éditoriale dans le widget expérimental.

Panelizer déplacé vers le noyau (devenu Layout Builder)

Panelizer a pris une autre voie. Il a trainé derrière Paragraphs en termes de nombre d'installations, mais en raison de sa popularité dans D7, un travail était en cours pour le migrer dans le noyau de Drupal (tout comme CCK dans d7). Cependant, ce n'est que dans Drupal 8.5 que Layout Builder est devenu disponible (comme un module expérimental). À Drupal 7.8, il est devenu stable. 

Layout Builder offre une grande flexibilité et une grande promesse, mais l'interface utilisateur, même au moment de l'écriture, a encore un long chemin à parcourir pour être explicite (il faut un peu de formation car de nombreuses choses ne sont pas évidentes). De plus, il n'y a pas de "meilleure pratique" claire quant à la façon de gérer le contenu maintenant et ce qui devrait composer les pages. Les intégrations sont également à la traîne, surtout avec les modules de recherche. 

Actuellement, il n'y a pas de gagnant clair et la meilleure pratique n'est pas encore établie. Il y a le module Paragraphs avec 100k installations, de multiples intégrations et une interface utilisateur claire. D'un autre côté, il y a le Layout Builder qui est dans le noyau de Drupal, ce qui est une force incroyable. 

Pourtant, il y a de nombreux modules qui n'ont pas passé l'épreuve du temps et ont été supprimés du noyau.

Gutenberg (un éditeur WordPress)

Enfin et surtout, il y a le projet Gutenberg. C'est le plus récent des éditeurs intéressants dans Drupal. Il a été porté depuis WordPress où il est l'éditeur principal.

Gutenberg est un éditeur basé sur React qui prend en charge toute l'expérience d'édition, donnant à l'utilisateur une expérience WYSIWYG. Il diffère dans son approche de Paragraphs et Layout Builder en ce sens qu'il ne stocke pas la mise en page ou les entités dans la base de données, mais stocke le HTML généré. Vous créez le contenu avec un éditeur WYSIWYG et le HTML résultant est enregistré. Cela en fait un véritable WYSIWYG en termes de lisibilité du contenu pour les machines (les mises à jour ou migrations automatiques de ce contenu peuvent être problématiques). Néanmoins, il continue de s'intégrer de mieux en mieux à Drupal. Avec environ 900 installations, il n'est en aucun cas comparable aux deux ci-dessus mais la vitesse d'adoption est impressionnante. Consultez un aperçu rapide de Gutenberg dans Drupal.

Comme vous pouvez le voir, il n'y a pas de gagnant clair. La communauté Drupal teste toujours différentes approches pour construire des sites Web et responsabiliser les éditeurs. D'un côté, c'est fantastique car la concurrence aide la meilleure solution à gagner. De l'autre, les efforts des développeurs sont répartis sur de nombreuses approches différentes, ce qui ralentit le progrès. Quel est le meilleur ? Je ne sais pas.


 

3. Best practices for software development teams