Gutenberg, à la recherche de l’utilisation optimale d’un bloc face aux exigences de vos métiers - Parlotte WordCamp Paris 2023

Slides de la parlotte donnée au WordCamp Paris 2023 en co-présentation avec Florian Truchot (@floriantruchot), dans laquelle on se questionne sur l'utilisation optimale d'un bloc Gutenberg dans le cadre de certains scenarios avancés.

Transcript

1. Gutenberg, à la recherche de l’utilisation optimale d’un bloc face aux exigences de vos métiers Jérémy Desvaux de Marigny & Florian Truchot
3. Intervenants Jérémy Desvaux de Marigny Directeur Conseil Technique freelance, expert #WordPress @jdmweb Florian Truchot Craft radical website with #Gutenberg @floriantruchot +
4. Préambule * ✅ Ce dont on va parler — Quelle stratégie de bloc employer selon le contexte ? — Comment s’adapter aux besoins métiers — Comment établir un langage commun ? Nous exposons des réflexions issues de nos expériences respectives, il n’y a aucune vérité derrière nos propos. * ⛔ Ce dont on ne parlera pas — Quel est le meilleur page builder ? — Comment créer des blocs Gutenberg ?
5. Contraintes des différents métiers Commanditaire Avoir un site à l’image de son organisation qui reflète sa marque Design Comprendre et retranscrire visuellement un parcours métier Éditeur Avoir un contenu facile à éditer au plus proche du rendu (front) Technique Rationaliser les comportements et mettre en production des versions fonctionnelles stables (rapidement) Internaute Consommer l’information sur différents supports
6. Problématique Comment coordonner tout ça ? — Création / refonte d’un thème — Intégrer un Design System — Industrialiser la création de sites — WordPress en mode headless
7. Scénario #1 . Création / refonte d’un thème
8. Création / refonte d’un thème Contexte Je souhaite monter une page en utilisant les capacités natives de Gutenberg.
9. Problématique — aux designers d’imaginer un rendu graphique — de respecter la charte du client pour que l’internaute s’identifie à la marque — aux développeurs de produire rapidement — aux éditeurs d’administrer facilement du contenu qui soit proche du rendu final Est-ce que Gutenberg permet :
10. Création / refonte d’un thème Solutions Voir si on peut utiliser les blocs natifs à disposition, et les composer via l’éditeur ou des blocs-patterns.
11. “ J’ai mis à jour les maquettes des cards produit, j’ai changé le style du titre et j’ai rajouté une réduction en dessous du prix ” John Doe Designer
12. Création / refonte d’un thème Problème — Pas de synchronisation des éléments statiques (natif, patterns, blocs statiques) — Nécessite de repasser sur son contenu pour resauvegarder — Nécessite de coder des variations de dépréciations Contraintes métiers ✅ Commanditaire ⚠ Design ⛔ Technique ⛔ Éditeur ✅ Internaute
13. Création / refonte d’un thème Conclusion Si vous identifiez des éléments sujets à évolution, attention aux contraintes de synchronisation des éléments statiques! La phase de conception est importante pour limiter les allers/retours, mettez-vous d’accord sur les attributs des blocs.
14. Scénario #2 . Intégrer un Design System
15. J’ai un guide de styles déjà existant en PHP. Permettre à l’éditeur de contenu de l’administrer dans son back office Intégrer un Design System Contexte
16. Problématique Comment intégrer un design système existant dans Gutenberg ?
17. Intégrer un Design System Solution Utiliser les capacités des blocs dynamiques pour hydrater et rendre les composants du design système.
18. “ Depuis que vous êtes passé en blocs dynamiques, le back office ne ressemble plus au front, je m’y perd. ” John Doe Éditeur
19. Intégrer un Design System Problème ServerSideRender may also be used when a legacy block is provided as a backward compatibility measure, rather than needing to re-write the deprecated code that the block may depend on. ServerSideRender should be regarded as a fallback or legacy mechanism, it is not appropriate for developing new features against. “ ” — Soit @wordpress/server-side-render — Soit double rendu avec import des assets Contraintes métiers ✅ Commanditaire ✅ Design ⛔ Technique ⛔ Éditeur ✅ Internaute
20. Intégrer un Design System Conclusion Si vous employez des blocs dynamiques, mais que vous souhaitez garder une belle expérience d’édition, un effort supplémentaire de double rendu sera demandé
21. Scénario #2 . Industrialiser la création de sites
22. Industrialiser la création de sites Contexte Je suis missionné sur un nouveau projet, je souhaite réutiliser les blocs déjà codés, pour faciliter la création de nouveaux thèmes.
23. Problématique Comment sortir du thème les blocs précédemment codés ?
24. Industrialiser la création de sites Solution Construire une bibliothèque de blocs, sous forme d’un ou plusieurs plugins.
25. “ Je veux bien passer les blocs en plugins, mais j’ai pas envie que tous les sites qu’on sort aient la même tête ” Jane Doe Design
26. Industrialiser la création de sites Problème Comment générer le rendu alors qu’on ne connaît pas le thème utilisé ? Contraintes métiers ✅ Commanditaire ⛔ Design ⛔ Technique ✅ Éditeur ✅ Internaute
27. Industrialiser la création de sites Conclusion Permettre aux devs du thème de surcharger le rendu grâce aux filtres, locate_template(), injection de dépendances ou autres… Scinder les blocs de “rendu” et ceux “fonctionnels”. Le plugin fournit l’aspect fonctionnel. (avec pourquoi pas un rendu par défaut)
28. Scénario #4 . WordPress en mode headless
29. WordPress en mode headless Contexte Mon commanditaire a développé une application mobile à côté de son site, mais souhaiterait mutualiser l’administration de ses contenus.
30. Problématique Comment gérer le rendu du bloc dans des contextes technologiques d’affichage concurrents ?
31. WordPress en mode headless Solution Utiliser les capacités d’administration de WordPress, et s’appuyer sur l’API REST.
32. “ Elle est sympa votre API HTML, mais j’aimerais utiliser les composants React Native de mon application mobile plutôt ” Jane Doe Développeuse Mobile
33. WordPress en mode headless Problème Ce n’est pas le rendu du bloc qui nous intéresse, mais sa définition, sa donnée, et l’API REST nous renvoie du rendu. Contraintes métiers ⛔ Commanditaire ✅ Design ⛔ Technique ⛔ Éditeur ✅ Internaute
34. WordPress en mode headless Conclusion Renvoyer de la data brute (attributs, valeurs) en lieu et place du markup. Chaque client interprète le rendu selon la technologie utilisée, seule la configuration du bloc fait foi. https://github.com/Automattic/vip-block-data-api
35. En résumé Envisager les blocs comme un médiateur au carrefour de tous les métiers
36. — Bien définir les attributs de chaque bloc. Attributs = ADN — Anticiper les évolutions éditoriales ou graphiques et choisir la typologie de bloc en conséquence — Choisir la responsabilité du plugin ou du thème pour gérer chacun des bloc — Découpler le rendu (l’aspect du bloc) et le fonctionnel (son expérience d’édition au sein de Gutenberg) L’utilisation optimale d’un bloc face aux enjeux métiers Memento
37. Des questions ? Florian Truchot @floriantruchot Jérémy Desvaux de Marigny @jdmweb Plus tard Aujourd’hui Maintenant ☕ 🍻