Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Intervenants Jérémy Desvaux de Marigny Directeur Conseil Technique freelance, expert #WordPress @jdmweb Florian Truchot Craft radical website with #Gutenberg @floriantruchot +

Slide 4

Slide 4 text

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 ?

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Scénario #1 . Création / refonte d’un thème

Slide 8

Slide 8 text

Création / refonte d’un thème Contexte Je souhaite monter une page en utilisant les capacités natives de Gutenberg.

Slide 9

Slide 9 text

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 :

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

“ 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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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.

Slide 14

Slide 14 text

Scénario #2 . Intégrer un Design System

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Problématique Comment intégrer un design système existant dans Gutenberg ?

Slide 17

Slide 17 text

Intégrer un Design System Solution Utiliser les capacités des blocs dynamiques pour hydrater et rendre les composants du design système.

Slide 18

Slide 18 text

“ Depuis que vous êtes passé en blocs dynamiques, le back office ne ressemble plus au front, je m’y perd. ” John Doe Éditeur

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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é

Slide 21

Slide 21 text

Scénario #2 . Industrialiser la création de sites

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

Problématique Comment sortir du thème les blocs précédemment codés ?

Slide 24

Slide 24 text

Industrialiser la création de sites Solution Construire une bibliothèque de blocs, sous forme d’un ou plusieurs plugins.

Slide 25

Slide 25 text

“ 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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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)

Slide 28

Slide 28 text

Scénario #4 . WordPress en mode headless

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

Problématique Comment gérer le rendu du bloc dans des contextes technologiques d’affichage concurrents ?

Slide 31

Slide 31 text

WordPress en mode headless Solution Utiliser les capacités d’administration de WordPress, et s’appuyer sur l’API REST.

Slide 32

Slide 32 text

“ 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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

En résumé Envisager les blocs comme un médiateur au carrefour de tous les métiers

Slide 36

Slide 36 text

— 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

Slide 37

Slide 37 text

Des questions ? Florian Truchot @floriantruchot Jérémy Desvaux de Marigny @jdmweb Plus tard Aujourd’hui Maintenant ☕ 🍻

Slide 38

Slide 38 text

No content