DrupalCamp Paris 2019 : nous y étions !

Retour sur le DrupalCamp Paris 2019

Bien que certains dans l'équipe aient arrêté de compter le nombre de DrupalCamps auxquels ils ont participé, c'était pour moi le 1er (après une petite Drupal Europe à Darmstadt).

Un DrupalCamp, c’est l’occasion de voir où en est l’état de l’art dans la communauté, et j’ai pu assister à 5 présentations business (dont deux des nôtres),

Les projets présentés représentent assez bien le coeur de cible de Drupal, à savoir :

• des projets ambitieux,
• avec des processus métiers complexes, nécessitant des adaptations custom.
• souvent multisites, et/ou multilingues.

Et en la matière, nous n'avons pas à rougir des dernières réalisations que nous avons pu sortir.

Et c’est bien sûr l’occasion de pouvoir assister à des conférences s’adressant aux développeurs, et d’apprendre énormément. Pour les curieux qui seraient intéressés par un bref résumé des conférences, un framapad de prises de notes collaboratives existe ici.

Je recommande d’ailleurs la lecture du compte rendu de deux présentations pour ceux qui sont comme moi en train de progresser dans Drupal :

• Audit de sécurité d'un site Drupal
• Drupal 8 - Best practices

Mais s’il ne devait en rester qu’une, LA présentation que je retiendrai c’est celle de Floris Moriceau

https://paris2019.drupal.fr/programme/sessions/economiser-du-temps-dintegration-dans-vos-projets-drupal

Exemple d'un projet Drupal qui tourne mal

Une histoire tragique d’intégration d’un site drupal qui tourne mal, inspiré de faits réels.

• Des maquettes construites sous photoshop et pas du tout conçues pour être responsives (colonnage plus qu'hasardeux).
• Maquettes qui seront ensuite validées par le client, sans que l’équipe technique n'ait son mot à dire.
• Et en plus qui seront validées, alors que le périmètre fonctionnel (ce qui sera développé) sera différent (X features en moins).
• L'UX designeur n'a aucune connaissance des contraintes technique du CMS. Parmi les nombreuses conséquences que cela va engendrer, il y a notamment la prise en compte du principe des "régions" d'un thème, et suivant l'affichage mobile ou desktop, d'essayer d'afficher les informations aux même endroits (un block en sidebar, qui se retrouverait dans le header par exemple).
• En plus d'être affichées dans des endroits différents, les informations en mobile sont différentes de celles en desktop, sans raison particulière.
• Et les maquettes pour mobiles arriveront quand on est déjà en train de faire l'intégration. Bref le site est "mobile-last".
• Des créa de pages de contenu avec un lorem ipsum qui ne dépasse jamais.
• Les fonts, sur psd chargées en 6 variantes, en vrai c'est pas terrible.
• Un thème de base  bien connu est choisi sans que le themeur ait son mot à dire (par exemple le tristement célèbre thème boostrap drupal). Thème de base qui sera très difficile à surcharger et rallongera considérablement le temps d'intégration, plutôt que de partir ex-nihilo.
• Les maquettes en psd sont ensuite recréées directement en page html/css. Et c'est aux devs à faire rentrer ensuite le "vrai" site dans l'intégration. D'après Floris, c'est à minima rallonger le temps d'intégration par 1.5. D'après moi, et pour l'avoir vécu, c'est plutôt multiplié par 3.
• Le multilingue => Pas de maquettes en plusieurs langues. Alors que certaines polices d’écriture n'ont pas des caractères spéciaux, que certaines langues sont plus verbeuses et peuvent casser la navigation. Et que certaines langues se lisent de droite à gauche. Vous vous rendrez compte de tout ceci pendant la recette évidemment.
• En pleine recette avant livraison, un audit SEO met en évidence une hiérarchie de titrage calamiteuse (conditionnelle suivant les pages, et incohérente en général). Mais le site est déjà developpé et intégré, et la charge prévue a depuis longtemps été dépassée.
• Afin de répondre aux diverses contraintes évoqués plus haut, vous avez (ab)user de hooks, de preprocess, de scripts JS custom, etc. C'est un peu comme faire de la chirurgie (pas très) esthétique et de découper une personne pour la faire rentrer dans une taille donnée d'habits.
• La conséquence directe de ce découpage bizarroïde, c'est que le site est devenu lent.

J’abonde en tout cas dans le sens de la conclusion :

"Il faut qu’il y ai un échange permanent entre le designer et le themer Drupal AVANT la validation des maquettes par le client. Cela n'empêchera en rien à ce que les maquettes vendent du rêve, de l'émotion, de racontez une user story dynamique et authentique , etc."

Et ca tombe bien, cette année nous allons ouvrir le recrutement pour un thémeur et un UX designer, afin d’internaliser ces compétences et d’avoir une meilleure synergie avec les « devs ».