C’est posé, un peu brut c’est vrai, depuis 14 ans que nous travaillons avec Drupal, malgré les évolutions, c’est une constante à laquelle nous faisons encore face.
Le fait est que sur Drupal, on met en forme (principalement) des contenus et leurs champs. Pour pouvoir le faire il faut que le contenu et ses champs existent et soient « contribués ».
Les tâches d’intégration doivent donc attendre que le site building (+ dev) soient effectués AVANT d’intervenir. Pour nous, vieux devs Drupal, cela paraît logique mais pour beaucoup c’est contre intuitif.
On a une forte dépendance entre la structure de contenu et les « widgets » de mise en forme qui peut devenir complexe à gérer et maintenir, même lorsqu’on utilise l’inclusion de twig et « components ».
Malgré cela, la couche de rendering de Drupal reste un formidable outil et utilise des paradigmes puissant comme le render_array permettant un render « introspectif » : le conteneur n’a pas à connaître exactement son contenu.
Si cette couche a peu voire pas évolué significativement depuis des années, c’est certainement parce qu’aujourd’hui, il n’y a pas mieux.
ui_patterns & ui_suite introduisent une zone claire d’interface entre le contenu et sa mise en forme.
- L’inté crée un pattern (composant graphique) avec du twig / css / js.
- Il déclare son pattern, avec un simple yaml
- Drupal le reconnaît directement
- ui_suite le met à disposition de toutes les briques de mise en forme de contenu dans drupal :
- ◦ view_modes
- views
- layout_builder
- …
Le module ui_styles constitue également un "game changer" dans l'expérience contributeur les styles de patterns remontent directement dans l'interface d'admin offrant une grande souplesse dans la mise en forme tout en limitant le couplace donnée métier / mise en forme.
Last but not least il est possible de créer une « librairie » visuelle de tous les patterns sans la moindre ligne de code php !
Allez sur la page de l'initiative pour avoir plus d'infos techniques : https://www.drupal.org/project/ui_suite
On peut donc avoir un process plus « commun » :
Chez nos clients grand compte et notamment pour des clients « groupes » ou appartenant à un groupe, les notions de charte graphique, de ui kit ou encore d’atomic-design sont très représentées nous travaillons depuis 1 an déjà à la mise en place de ces solutions. Nous avons constaté que les impacts sont bien au-delà des équipes techniques. En effet, les processus et les principes d’architecture sont alignés sur toute la chaine : métiers > UI & UX > PO > front dev > site builders & back devs..
Pour les manager, ça veut dire qu’il est possible de gérer des compétences Drupal en paliers : plus besoin d’être un senior drupal pour faire du travail propre « à la Drupal ». Il devient possible de gérer des pools de compétence et le turn over en limitant la création de dette.
Merci à Pierre Dureau, Michael Fanini et Florent Torregrosa pour leur présentation et leur excellent travail.
