Sauvez un projet, fouettez un graphiste (en plus il aime ça)

Je sais que depuis que je suis consultante, je n’ai pas mis beaucoup d’article sur la gestion de projet, mais je rattrape sous peu, plein de petits articles attendent au four.

Voici LA checklist du chef de projet pour qu’il casse les pieds, lourdement, aux graphistes, créa et autres ergonomes qui font dans la dentelle, la fantaisie, l’effet WWOuahou, et qui vont gentiment, sans le savoir, eux, plomber la relation client parce que « sur les maquettes c’était plus beau » ou « mais pourquoi c’est si lent ? » ou encore « comment ça c’est pas dans le périmètre du projet ? C’est sur les maquettes ! »

C'est beau le lisssage... en web ça donne plutôt la partie à gauche

  1. Le lissage des polices.


    Le lissage des polices sur une maquette, c’est la joie de présenter au client une maquette toute propre, suave, et peut-être éventuellement si les clients n’utilisaient que Firefox, quelque chose de presque reproductible.
    QUE NENIE. Le lissage sur les maquettes c’est le Bad, il faut le bannir, ça ne sert non seulement qu’à flatter l’égo du graphiste mais ça ne produit jamais l’effet final = l’effet web (tu sais le truc avec des pixels)
    Présenter une maquette « propre » à une direction de la communication, ce n’est pas présenter un site web à un million d’utilisateurs.
    Comment savoir ? Tout simplement, demander au graphiste « est-ce que tu as fait la grosse connerie de lisser les polices sur les maquettes, elle a l’air bien propre et… pas très ouebe » ? Vous verrez ça fait tout de suite son petit effet.

    polices_non_web

     

  2. Les polices « non web »


    On a beau se persuader que les navigateurs se modernisent à outrance, le jeu de police associé reste le même. Donc quand un graphiste ajoute une police non web à une maquette, le résultat sans Javascript activé = police web (entendez un moche Arial, un hideux time new roman, ou un acceptable Verdana) ; par conséquent ? Que faire ? Opter pour un de ces plugin JavaScript Barbare : @font-face ? @cùfon ?
    Et la compatibilité navigateur de ces petits plugins ? Une jolie petite blague pas vraiment drôle pour les versions d’Internet Explorer, et de longues heures de recette… (et puis avec les utilisateurs d’IE6, qui devraient être flagellés au marti-fouette trempé dans l’acide, parfois on se retrouve des heures à faire des tests et des ajustements sur une machine virtuelle aux performances tout ce qu’il y a de plus relatives)
    Bref, quand un graphiste introduit une police non-web attendez-vous à souffrir, par conséquent, prenez de l’avance, offrez-lui un cactus.

     

  3. Les blocs Étirables.


    Le bloc étirable est adaptable partout, il est beau, il est mignon… sauf que pour faire un bloc étirable il faut lui donner une structure proche de celle d’un plan d’architecte, tout en lui confèrent la solidité d’accueillir le contenu du client qu’il soit volumineux ou minuscule, bien sûr, celui-ci sera encore plus complexe dès qu’il aura des bords arrondis, des effets ombrés, du relief, une image qui en déborde etc… etc…
    Pour chaque minute de css pour répondre au besoin complet, mettez un petit caillou dans une jarre, une fois terminé, faites en une soupe que vous ferez boire au graphiste.

    graphiste_etirable

     

  4. Les alignements verticaux


    Il est mignon le bloc à gauche, et puis il est encore plus mignon le texte flottant à droite, qui est parfaitement aligné avec les titre de la 3ième lignes, du bloc de gauche… Pareil pour les deux blocs en dessous… Ha ? ils peuvent être intervertit ? C’est magique ??? Pas d’illusion ici : l’alignement vertical n’existe pas, pour aucun navigateur. Seul le JavaScript peut vous aider, et seule une construction souple adaptative et évolutive du code permet de jouer à ces petits jeux d’alignements qui, même en print (=à l’impression papier), ne se produisent jamais par hasard.
    Bref, quand le graphiste vous fait des alignements verticaux, à outrance, et que l’ergonome recommande le déplacement de tous les blocs dans tous les sens, alignez-les, eux aussi, tous les deux

    graphiste_align

     

  5. Le périmètre fonctionnel


    Ouahhh mais elle est géniale cette maquette, mais que fais le bouton ici ? Et le bloc là ? Et la fenêtre là ? Et la popin là ? Et la popup ici ? Tiens mais que fait ce nouvel élément dans le Footer ? Et cette fonctionnalité là, dans le header, elle vient d’où ? Elle fait quoi ?
    Soyez psychorigide, quand le graphiste réalise plus que le cahier des charges, ou qu’il ne respecte pas les story board de l’ergonome (qui lui était en atelier fonctionnel avec vous ): les développements devront couvrir TOUS le périmètre fonctionnel de maquettes, même si ces nouveaux points n’étaient pas initialement au périmètre fonctionnel du CDC ou du CCTP, a fortiori si les maquettes ou la charte graphique sont validés. Bref, quand un Graphiste ajoute un truc, demandez-lui d’aller chercher le budget correspondant chez le client, sans cravate et avec son beau sourire col-guette, et attendez patiemment qu’il écoute la courte et froide réponse du client.

     

  6. Le brief


    On se demande souvent pourquoi le graphiste n’a pas fait ce qu’on lui a transmis, pourtant on avait peut-être fait un pseudo Compte rendu de ce qu’on attendait… et en fait ça tombe vraiment à coté.
    Obligez-vous à rédiger un brief, pour le graphiste : soyez efficient, précisez ce que vous attendez, où trouver des informations graphiques propre au client, les terminaux cible, l’historique et les attentes du client, les navigateurs attendus et tout le tintouin, ça vous servira aussi pour le travail de montage graphique, ça vous assurera de pouvoir renvoyer le graphiste à la lecture de l’énoncé et s’il le lit pas tatouez le graphiste avec un RTFM

     

  7. La projection


    Malheureusement, de nombreux graphistes se persuadent encore que les développeurs sont meilleurs qu’eux. Ils ont raison. C’est dommage parce qu’ils pourraient devenir meilleurs et se souvenir qu’une maquette doit pouvoir être montée dans un environnement web, et par conséquent faire leur travail jusqu’au bout, mais non, ils savent que les développeurs talentueux, devineront les noms sibyllins mis derrière des calques de votre fichier toshop, gimp ou illustrator, que 2433 calques valent toujours mieux qu’une 50aines bien organisés, et que les calques « trashs » sont toujours utile quand on a du temps à gaspiller.
    Bref, la prochaine fois que vous donnez un brief à un graphiste, écrivez-le en sanscrit, faites lui livrer par coursier au bengali, et dites-lui de se débrouiller pour aller le récupérer.

     

  8. La culture


    Vérifiez, vérifiez tout derrière le graphiste.
    Recontez les nombres, vérifier les ordre alphabétiques des glossaires, vérifier la place et le n° des départements sur une carte vécu, refaite les parcours de produit, lisez les textes qu’ils ont choisi vécu aussi…, soyez vigilant, car même si le graphiste est dans le speed comme vous, lui, il n’est pas obligé d’avoir une culture ni de parler au client
    Là, si le graphiste fait de la merde et surtout qu’il refuse de corriger parce que c’est « une pétouille », enfermez-le dans une pièce avec 1 moustique, il verra ce qu’une broutille peut faire…

     

et le département de Marseilles tu le mets où ?

et vous ? vous mettriez quoi de plus à cette check-list ?

Comments 8

  1. Point 1 :
    Oui et non, les polices sont naturellement lissées dans les browsers modernes, après il y a lissage et lissage, parfois les créas abuses du lissage
    Point 2 :
    Ca marche très bien partout, il faut juste connaître les bons outils et faire les bons tests => fontsquirrel
    Point 3 :
    Si un intégrateur n’est pas foutu de savoir faire un bloc étirable complexe ou non, il peut arrêter le métier d’intégrateur / dev web
    Point 4 :
    Ca marche dans le cadre d’une liste, il faut juste connaitre la bonne petite technique. Idem si on veut toujours aligner du texte sur 1 à N lignes dans une zone dont on connaît déjà la hauteur. C’est faisable les doigts dans le nez et de manière générique
    Point 5 à 8 : Je me prononce pas, je ne suis pas chef de projet

  2. Le coup du point 4 dans le cas d’un story telling c’est quand même assez moche.
    Et pour le point 1. Le problème c’est que c’est que tous les navigateurs ne sont encore pas malheureusement modernes. Se moquer d’IE n’a jamais permis de vraiment l’évincer, et particulièrement sur mobile, il revient en force.

  3. Techniquement on peut faire bcp de ces choses en fait (mais ça a déjà été dit). Mais effectivement faire un site pixel perfect qui marce sur tous les navigateurs à partir d’une maquette très ambitieuse peut se révéler .

    +1 pour le moustique, j’aime.

  4. Valentin,
    Il faut que tu imagines 2 blocs cote à cote (gauche et droite, un coeur de page par exemple et une colonne de droite), et que dans ces deux blocs il ait du contenu, et un bouton d’action. Lorsque le contenu rentre parfaitement dans chacun des blocs (ou lorsqu’il est un peu moindre, aucun souci à aligner les deux boutons d’action, on pousse le bouton en bas du bloc et c’est marre.
    Lorsque un de ces blocs (prenons le droit pas exemple), est trop rempli de contenu, le blocs (de droite donc) s’étire vers le bas. Il embarque donc avec lui le bouton (toujours dans le bloc de droite), en le poussant plus bas que le bouton qui est dans le bloc de gauche. Donc pour que l’autre reste aligné, le bloc de gauche, au chargement de la page doit descendre pour faire descendre le bouton avec lui et se ré aligner sur le bouton du bloc de droite (et déjà à te raconter, tu sens que c’est un peu du merdier tout ça… tu te dis qu’il y aurait des astuces au montage mais bon)
    En gros, chaque fois qu’un bloc s’agrandit finalement il oblige plusieurs blocs alentours à se redimensionner, ça devient vite une règle d’algorithmie à la con lorsque c’est deux blocs, l’un au dessus de l’autre à droite, qui sont trop grands, et qui doivent agrandir 2, 3, 4 blocs à gauche donc, mais donc si un bloc de gauche descend il faudrait pas que le contenu de l’autre (au dessous ou au dessous) fasse descendre trop bas le bouton sinon il faudrait encore redimensionner le bloc de droite, en refaisant une petit passe de code… et donc il faut trouver des solutions d’encapsulation de div, de span, dans des div de span de div, et jouer sur des interdépendances en pensant à toutes celles possibles, en mettant des positions relatives, dans des absolutes avec des repères par rapport au haut, et au bas du bloc … Etc etc… Ca devient vite un mange temps au montage entre astuces de CSS et Javascript au chargement de page et ça donne des sites où quand t’arrive, et que ça rame un petit poil, tu vois des blocs se charger, se redimensionner, bouger, et quand tu veux cliquer faut trois plombes que ta page se charge pour avoir le droit de pouvoir enfin cliquer sur cette offre promotionnelle à -25% qu’on t’a vaillamment promise et qui se refuse à toi en se baladant sous ta souris, alors que toi, consommateur effréné t’étais prêt à donner ton argent, si y’avait pas eu toutes ces micros secondes d’hésitation qui t’avais fait penser qu’être parkinsonien, ce jour là t’aurais rendu service. (oui, le début de cette phrase était à « ça »)

    Cela dit, aujourd’hui, on voit de plus en plus de site verticaux, sans colonnes sur les cotés qui évitent de reproduire ce genre de bêtises maladroites, issu des standards de graphisme et d’ergonomie de ce qu’on pourra bientôt appeler le « c’était avant ».
    C’est le cas du site de l’agence Jouve interactive, par exemple (http://www.agence-interactive.jouve.com/) où on joue sur un graphisme dynamique, mais sans ces règles d’alignement (dont finalement, tous le monde se fout) puisqu’on optimise pour tablette et IPad.

    Je sais pas si j’ai été claire. Ca va tu respires ?

Laisser un commentaire