Il était une fois une maquette

Par Thomas Zilliox

Mini-conf (15 mn) :

Langue :

Français

CSS

HTML

Liens connexes

• Diaporama (PDF)

Le sujet

Un intégrateur HTML pleure de joie.
C'est un grand jour pour sa maquette.
Elle qui avait été conçue de son union avec un graphiste.
Elle qui était née d'un besoin exprimé par un client.
Elle qui avait grandi jusqu'à être compatible sur de nombreux navigateurs.
C'est le jour J : elle va enfin rencontrer celui pour lequel elle était promise.
Elle va s'unir avec un code métier.

Sa vie ne sera plus jamais la même : on va désormais l'appeler thème (pour Wordpress), ou template (pour Symfony). Elle ne pourra plus jamais être lue dans un navigateur sans son code métier. L'intégrateur n'aura alors plus la main directe sur sa maquette…

Ceci arrive tous les jours, et ce n'est pourtant pas un événement anodin :

• Quels sont les réels impacts de cet événement sur la vie de votre projet ?
• Est-ce qu'il est possible de travailler par itération avec ce fonctionnement-là ?
• Ne faudrait-il pas laisser une maquette vivre sa vie, même après son union avec du code métier ?
• Comment concilier alors la vision modulaire du code métier et la vision hiérarchique de l'HTML ?
• Quels sont les alternatives pour mieux respecter le travail de chacun ?

Ces questions, que je me suis posées, méritent de plus amples réflexions. Sans vous donner de solutions universelles, j'essaierai de vous donner des pistes de réflexion sur la collaboration entre intégrateurs HTML et développeurs back.

Présenté par

Transcription

(Merci à Tanguy Lohéac pour la transcription.)

Thomas Zilliox : bonjour à toutes, bonjour à tous.
Merci d’être là.
Alors je vais vous présenter une conf qui s’appelle : il était une fois une maquette.
Alors on va regarder si… Hop.
Il était une fois une maquette. Et si on veut y mettre un peu de troll dedans, j’ai envie de dire intégrateurs HTML et développeurs métier, est-ce qu’on pourrait commencer à collaborer efficacement ?
Alors moi je me présente. Je m’appelle thomas Zilliox. Je fais du web depuis un peu plus de 5 ans maintenant.
J’suis démarré en freelance il y a pas longtemps en tant que Pixel 418.
Et je fais aussi bien de l’intégration que du développement.
Et sur des projets je fais de l’intégration, sur des projets je fais du développement.
Et assez rarement, je fais l’intégration et le développement.
Parce que quand je fais les deux, il se trouve que après je m’énerve, je me boude.
Et pourtant c’est pas un problème de communication parce que d’habitude je me communique assez bien avec moi.
Et finalement, j’ai essayé de chercher le pourquoi du comment.
Et c’est ces pistes de réflexion que je vais vous présenter aujourd’hui.
Donc c’était l’histoire d’une maquette.
Donc la maquette elle est faite par l’intégrateur HTML, qui avait été faite par les graphistes avant, qui venait d’un besoin client.
Et d’un autre côté le client il va définir un périmètre fonctionnel.
Il y a un chef de projet qui va les transformer en questions.
Et le développeur va faire le code métier.
Alors développeur métier c’est une traduction personnelle de développeur back.
Et finalement la maquette et le métier sont à l’opposé mais pourtant ils sont faits l’un pour l’autre.
Le métier est fait pour la maquette, la maquette est fait pour le métier.
Et ils vont se marier.
Mais c’est le développeur qui va les marier ensemble.
Jusqu’au jour où le client trouve un bug.
Il le dit au chef de projet qui le renvoie au développeur.
Et le développeur dit : « ah ça c’est un bug IE6, c’est pas pour moi ! Je leur envoie l’intégrateur. »
Et l’intégrateur : en effet c’est un bug IE6.
Il se trouve un peu embêté parce qu’il sait bien que sa maquette… bon il sait pas trop ce qui se passe de l’autre côté.
Mais il sait que sa maquette elle est plus comme avant. Elle a changé.
Donc il va chercher à reprendre du site en ligne le code HTML pour le modifier, faire des corrections et le redonner au développeur pour le réintégrer.
Et là l’intégrateur dit une phrase qui reste dans la mémoire du développeur. Quelque chose comme ça :
« Tiens j’ai corrigé le bug IE6. Et j’en ai profité pour aligner le footer, corriger le rang de recherche, améliorer le contraste des liens sur le côté et réaligner le header. »
Et là le développeur s’est mis à pleurer en fait parce que il a que deux choix.
L’un c’est refaire son boulot.
Et le deuxième c’est comparer à l’œil nu les différents fichiers, essayer de trouver les différences, copier/coller.
Ce qui fait que dans les deux cas ça va être long et que dans les deux cas, il va se retrouver avec des nouveaux bugs.
Et c’est pour ça que c’est l’histoire d’une maquette.
C’est-à-dire que la maquette dans vos projets, la plupart du temps c’est du one shot.
La maquette est très jolie. Elle est insérée, enfin elle est donnée au développeur et après on l’oublie.
Ca devient une template.
Pour la gestion de projet, c’est pas pratique.
Donc on va essayer aujourd’hui de définir un coupable.
Et le coupable bein il y a en déjà 5 des suspects.
Donc à vous de choisir lequel vous paraît le plus coupable.
Sachant que la bonne poire c’est souvent le client [quelques sourires dans la salle].
Alors on va commencer l’enquête.
Quand on va faire notre enquête de terrain on va tout de suite voir qu’il y a deux visions complètement différentes.
Celui de l’intégrateur et celui du développeur.
C’est-à-dire que quand on va commencer à poser des questions par rapport au client., il y en a un qui va nous parler d’un contact au marketing et l’autre qui va nous parler d’un contact au service informatique.
Il y en a un qui va parler d’un site web, l’autre d’une application web.
L’autre qui nous parle que de fonctionnel, l’autre que de l’apparence.
Et finalement le résultat de leur travail, c’est pas du tout le même.
Il y en a un qui va nous faire une maquette et il y en a un qui va nous faire une template.
Et la différence est énorme. C’est-à-dire que si je fais un zoom sur deux caractéristiques essentielles, enfin deux différences essentielles entre la maquette et la template.
C’est-à-dire que, pour résumer, la maquette elle va être en HTML et CSS.
Et par nature ces langages sont hiérarchiques et globaux. Enfin ils ont une vision hiérarchique et globale.
C’est-à-dire que quand vous modifiez une CSS elle risque d’affecter toute la page, voire même toutes les pages.
Donc vous êtes toujours obligé de réfléchir globalement.
Et quand vous faites de l’HTML, votre nœud HTML il a de sens que par sa hiérarchie.
On le déconnecte pas du reste.
On pense toujours globalement et hiérarchie.
Alors que les développeurs web, back, ils travaillent pas du tout comme ça.
Ils ont leur métier, besoins métier :
Je prends un élément de la colonne de droite, je la fous à gauche…
Si on peut le faire, pourquoi pas le faire.
Et les framework c’est pareil. On découpe les problèmes.
Moins on a d’interaction entre les éléments de notre projet, mieux c’est: Plus on va pouvoir travailler à plusieurs, plus on va pouvoir découper notre code, corriger un bug d’un côté sans casser le reste.
Et finalement c’est deux visions qui sont complètement différentes.
En fait on donne la maquette qui est une vision hiérarchique et globale au développeur, qui a lui, une vision de son projet inversement.
Et ce développeur on lui donne des outils qui sont des outils de développeur.
C’est-à-dire qui sont découpés et modulaires.
Donc il va nous faire un truc comme ça. Pour afficher une liste de liens de produits :
Il va nous coller un ul.
Il va nous faire un foreach avec des accolades dedans.
Et puis un include.
Donc là on a deux gros problèmes. C’est-à-dire que première accolades pour mettre un foreach, ça veut dire que notre maquette on peut plus la voir dans un navigateur.
C’est fini.
Il y a des include.
Donc bein là on a un ul, on s’attendrait à avoir un li.
Et on un include de fichier.
Donc est-ce qu’il y a un li de fichier ? est-ce qu’il va rester longtemps ce li ?
Quand une première personne va essayer de maintenir, il va peut-être l’enlever.
Donc c’est pas du tout ce qu’aurait fait un intégrateur.
On va essayer de chercher donc la solution idéale.
Est-ce qu’on peut changer les outils ?
C’est-à-dire que au développeur on lui donne un ciseau. Donc on va pas s’étonner qu’il découpe le papier avec quoi.
Donc à la recherche de la solution idéale, on va plutôt se pencher sur ce qu’il y a côté JavaScript.
Parce que JavaScript c’est une technologie qui a un peu ce côté de vision d’HTML.
Donc je vous prends ces deux projets que vous connaissez peut-être déjà qui s’appellent BarmanJS et Distal qui sont des outils de templating en JavaScript,
Et qui en fait travaillent pour mettre les informations de templating, toute la logique du templating, en attributs HTML5.
Donc votre template HTML elle est toujours valide dans un navigateur.
Votre maquette vous pouvez, enfin votre template du coup, vous pouvez la donner à votre intégrateur.
Il peut la modifier. Et vous ça vous gêne pas.
Il va pouvoir la modifier dans son navigateur.
Mais ça va pas assez loin.
C’est-à-dire quand même le développeur va aller mettre les pattes dans la maquette quand même.
Donc, un autre projet qui s’appelle Pure où là finalement on va pouvoir sortir les informations de templating dans un fichier à part.
Donc on met, par exemple si on veut sélectionner la classe product, on met .product.
Tout simplement. Une sorte de foreach. Et puis, on remplit le nom du produit.
Une piste pour un monde meilleur :
Si on peut continuer cette logique là et la porter côté back office, enfin côté métier.
On garde le layout. On refait l’histoire du foreach tout ça comme avant.
Mais on pourrait tester s’il y a un container pour mes produits.
S’il n’y a pas de container, je demande à ma maquette de rendre quelque chose, pour qu’on affiche la liste des produits, bêtement.
Et que c’est pas un contenu principal.
C’est-à-dire qu’on pourrait enlever la maquette et tester le métier.
Et en même temps, enlever le métier et toujours tester la maquette.
Oui ? Non ? [rire]
Là la maquette elle est comme d’origine.
Et là le métier n’est pas lié à la maquette.
Si on l’enlève on peut toujours l’avoir.
Donc on pourrait utiliser un thème par défaut ou voir la maquette comme elle est.
Bon ça c’est dans un monde idéal. Et en attendant, bein il faut d’autres choses.
Donc en attendant on va essayer de revoir un peu les process et voir si on peut pas essayer de changer le rôle de chacun.
Et trouver un système à moyen terme.
Donc à moyen terme, au lieu que la maquette HTML soit passée au développeur est-ce qu’on pourrait pas dire :
Le développeur il travaille avec des frameworks.
Il travaille avec des termes, des CMS, des frameworks qui génèrent du HTML, des CMS qui on des thèmes par défaut.
Est-ce qu’on peut pas dire :
Bon bein le développeur métier il a du HTML valide.
Il le donne à l’intégrateur. Et l’intégrateur HTML finalement c’est un intégrateur pas HTML dans ce cas-là. C’est un intégrateur qui va faire que du CSS.
Il va habiller.
Ce qui donne en fait une solution assez évidente.
Si on prend un système comme ça, le client qui un bug,
Il le passe au chef de projet. Il lui dit il y a un bug.
Le chef de projet il va dire : il y a un bug.
Et le développeur métier il va dire ça c’est IE6. C’est pas à moi.
Si c’est un bug métier, il le corrige.
Si c’est pas un bug métier, il le passe à l’intégrateur qui le corrige.
Pas d'aller-retour. Pas de souci.
Tout ce passe bien dans le meilleur des mondes.
Mais non. Alors c’est une solution qui marche.
J’ai vu des projets passer avec très bien, nickel.
Par contre, ça marche pas sur tous les projets.
C’est-à-dire que l’intégrateur c’est pas un magicien.
Il peut pas faire n’importe quel rendu avec n’importe quel HTML de manière propre.
Donc il faut avoir une bonne coopération entre le développeur et l’intégrateur.
Il faut qu’ils aient l’habitude de travailler ensemble, qu’ils puissent s’appeler facilement.
Ou c’est encore mieux s’ils sont dans un bureau l’un à côté de l’autre.
Et enfin ce qui gêne un peu des fois, c’est que finalement, avec ce système-là on va se retrouver avec un client qui va pouvoir voir le rendu du site qu’à la fin du projet.
Il va pas se retrouver avec une maquette dans nos navigateur qu’il va pouvoir cliquer, changer d’avis tout de suite, depuis le projet "Parfait ! on recommence !".
Là on va avoir fait le métier. Puis on va faire la maquette, par-dessus.
Et puis là, il va changer d’avis.
C’est un peu dommage.
Finalement, j’ai pas parlé du coupable.
Alors qui est le coupable ?
Qui doit-on désigner comme responsable pour changer cette situation ?
Et bein le coupable, j’ai envie de dire, c’est le développeur.
Finalement c’est lui qui tient l’arme du crime.
C’est lui qui a découpé sa maquette.
Et encore pire que ça. J’sais pas si vous déjà vu deux développeurs travailler ensemble. Mais ils travaillent avec des webservices, des interfaces, des APIs.
Jamais un développeur va s’amuser à mettre les pattes dans le code d’un autre s’il comprend pas ce qu’il a voulu faire.
Et là, le travail d’intégrateur, il arrive. Et il prend 5 maquettes et il les transforme en 100 templates.
Et il a aucun souci, aucun scrupule. C’est ses outils.
Est-ce que le développeur aurait pas pu se rendre compte à un moment qu’il fallait qu’il se détache de ce code maquette ?
Et en complice j’ai quand même bien envie de mettre le chef de projet.
Donc soit qui a pas essayé de faire un autre système d’organisation, soit justement qui a fermé les yeux sur le fait que toutes les maquettes étaient découpées en 100 petits morceaux, sans rien faire.
Alors pour résumer un peu ce que je viens de dire :
Donc on a une solution à long terme qui existera pas tout de suite,
Une solution à moyen terme qui est de réorganiser l’équipe.
Mais ça marche pas pour tous les projets.
Donc il faut aussi trouver des solutions à court terme.
Donc il faut de meilleurs outils. Donc ça on a bien vu que ça marchera pas.
Le chef de projet décide, à chaque début de projet, qui va générer le HTML.
Est-ce que c’est l’intégrateur ? Est-ce que c’est le développeur ?
Le développeur découpe raisonnablement sa maquette.
C’est-à-dire qu’il découpe pour factoriser. Donc pour gagner en maintenabilité.
Or, à gagner en maintenabilité en découpant il perd de la maintenabilité.
Donc il y a une limite à trouver. Et pas découper, ouais moi j’ai vu des projets à 200, 300 templates.
Ca commence à faire beaucoup.
L’intégrateur peut essayer de séparer au moins le layout du contenu.
J’ai fait des projets où l’intégrateur faisait bien l’effort de mettre 2 3 include php.
Et finalement, les développeurs et les intégrateurs s’entendent vachement mieux quand ils ont déjà un peu la même logique.
L’intégrateur et le développeur utilisent le même repository.
Alors là il y a… ça va sûrement pas plaire à tout monde.
Mais je l’ai vu en projet et ça se passe bien.
Comme ça, à chaque fois que le développeur il voit qu’il y a un commit du dossier de la maquette, il le met à jour.
Et inversement, si le développeur commence à toucher à la maquette l’intégrateur le sait tout de suite.
Et le site ? Bein le développeur s’il corrige un bug CSS et qu’il a pas le temps de faire un aller retour avec l’intégrateur ou parce qu’il a pas besoin, et bein il le fait dans un fichier à part.
Et il le commente.
Commenter c’est très important parce que il va corriger un bug qui ne va peut-être plus existe après quand on va mettre à jour la maquette.
Et si on sait pas ce que ça voulait résoudre, et bein on va pas réussir à l’enlever.
Donc on va se retrouver avec plein de corrections de bugs qui existent plus.
Donc j’espère que ça vous a plu, un peu.
Si vous avez des questions, c’est maintenant ou plus tard, ou par mail, ou par Twitter.
[Applaudissements]
Question intervenant salle : du coup je me sens un peu accusé là tout de suite [sourire].
T Zilliox : c’était le but. Au moins d’interagir.
Intervenant : j’accepte. Effectivement, en tant que développeur, je découpe des templates et je fais des include dans tous les sens. Parce que ça m’arrange. Voilà.
[hochement d’approbation de T Zilliox]
Après, on s’arrange. J’essaie avec les intégrateurs de leur remonter tous les problèmes que j’ai pus avoir.
Et quand l’intégrateur corrige un bug, il m’en parle. Voilà. Au final chez nous on traite les problèmes avec la communication.
Et ça marche plutôt bien.
Sans avoir des outils évolués. On n’a même pas Git. Et on y arrive. Voilà.
T Zilliox : la communication, du coup tu fais du versioning par mail ?
Intervenant : voilà. Ca peut marcher.
T Zilliox : dès que tu fais une modif t’envois un mail ?
Intervenant : non. C’est en exagérant.
Et voilà. Nous le seul outil ça va être une bonne communication déjà, à la base.
Et l’autre truc c’est : je pense qu’il y ait de solution miracle sur chaque projet.
Quand on bosse avec des personnes qu’on connaît, ça peut marcher.
Même si on change d’intégrateur, de développeur sur chaque projet, les gens travaillent de façon différente.
Ca peut être… Voilà, enfin sur du long terme, de travailler avec des gens différents, ça entraîne du coup une méthodo différente à chaque projet etc…
Donc je suis pas trop d’accord avec les grands points à dire "voilà comment faut faire quoi".
Et l’autre question pour accuser un peu les intégrateurs :
Moi je fais du JavaScript aussi.
T Zilliox : oui.
Intervenant : quand un intégrateur va toucher à mon JavaScript, par exemple, je vais me sentir aussi mal que ce que tu as exprimé tout de suite. Voilà.
Donc est-ce que t’as une méthode, dans l’autre sens, quand l’intégrateur va toucher au JavaScript parce qu’il a modifié un nœud HTML, parce que son menu dépliant doit changer etc ? Enfin voilà.
[T Zilliox esquisse une réponse]
Intervenant : la communication.
T Zilliox : ouais.
Intervenant : sachant que, est-ce qu’un intégrateur, voilà, en parlant du niveau de chacun aussi… Nous on a une problématique en ce moment à l’agence c’est : où est-ce que les intégrateurs s’arrêtent dans le JavaScript, par exemple ?
Quand est-ce qu’on va leur dire :
Ok bein le JavaScript que tu fais, arrête là parce que c’est pas du bon JavaScript. C’est au développeur de le faire, maintenant.
Ca c’est une problématique actuelle qu’on a sur chaque projet. Et on n’arrive pas à la résoudre.
T Zilliox : Alors…
Intervenant : j’ai dit plein de choses.
T Zilliox : tous les projets sont différents. Clairement.
Il y a pas de solution miracle. C’est un peu pour ça qu’il y a eu beaucoup d’idées et pas beaucoup de solutions à utiliser pour de vrai en fait.
Mais la communication ça marche mieux, ouais.
Si on connaît bien l’intégrateur ça se passe vachement mieux.
Moi par exemple le cas qui s’est passé avec IE6, j’ai eu la chance de dire une fois : « tu ne me refais pas une maquette. Tu fais chez toi et après tu m’envoies un mail avec toutes les modifications que t’as faites. »
Donc j’avais un mail avec 50 modifications : ce nœud-là tu le mets au-dessus, cette classe tu la descends.
Bon c’est pas digeste, mais au moins le résultat était bon.
Donc la communication, oui. C'est la meilleure.
Pour découper côté JavaScript, on se retrouve avec exactement les mêmes problématiques.
Mais c’est vrai qu’elles sont moins isolées. Donc c’est un peu plus flou à la limite.
Donc là ouais, c’est pareil. Ca dépend aussi des compétences de chacun. Est-ce que t’as un intégrateur qui est à l’aise avec le JavaScript ou pas ?
Normalement, moi j’ai l’habitude de dire de s’arrêter à l’animation.
Enfin présentation et animation. Mais c’est pareil. C’est-à-dire que la fois où ça s’est bien passé, c’était aussi avec un repository en commun.
C’est-à-dire qu’à chaque fois qu’ils modifiaient le HTML, nous on pouvait ajuster tout de suite le tir.
C’est-à-dire que, éviter d’avoir le slider, la démo qui marche plus parce que bein il y a un div en plus autour du header, qui est arrivé…