TravailleursDuWeb se BLACK OUT contre HADOPI

Guide à destination de nos amis graphistes… vu par un développeur

Publié le 19 December 2011, par Babozor dans la catégorie Développement, Gestion de projet, Graphisme

Oui ami graphiste, tu es beau svelte et musclé, tu manie la tablette graphique comme personne et tout ta famille te surnommes “photoshop”… mais voilà, parfois quand tu nous transmets tes jolis PSD et ben ça va pas.
Voici donc un petit guide pour calmer la guerre Dev VS Graphiste et te permettre de connaître les attentes des devs, les trucs qui vraiment nous énervent ou juste nous font perdre un temps infini.

Vilain psd

Design Général
Tu es plein de bonnes idées et c’est tout à ton honneur, mais autant cela semble un concept original et novateur, autant à mettre en place c’est juste un cauchemard…

Pleins de typos pas système
Oui certes cette police rend très bien sur tous les titres de tes créas, cette variante de “stencil” lui donne un air très martial, mais tu dois aussi prendre en compte que ce n’est pas un police système, donc il faudra soit créer physiquement les images et les inclure dans le site web, ou alors tenter de faire monter cette police de caractères dans les navigateurs nouvelle génération. Dans les deux cas une galère qui pourrait sans doute être évitée avec un peu de créativité et sans tomber dans la facilité d’une police bien funky mais qui n’est pas un standard

Des designs ronds
Peu importe la spécialité, si quelqu’un a déjà monté une page web, il te dira que la pire des chienlit est de tenter de monter un design bourré de courbes et de ronds. C’est certes esthétiquement très plaisant, mais vraiment galère à mettre en place. Si vraiment c’est “indispensable” penses à le rendre un minimum flexible, en le collant plus ou moins en image de fond, ou un truc du genre (ou même tentes simplement de laisser tomber cette idée lamantable)

Des câlages bizarres
Le langage utilisé sur le web est interprété, c’est à dire que le moteur de rendu le lit ligne après ligne et le rend au fur et à mesure. Cela rend le câlage de certains éléments dynamiques en hauteur pour le moins compliqué. Penses donc soit à limiter ou à fixer la taille en hauteur, soit à en discuter directement avec un dev si tu a un doute sur la faisabilité de ton design.

Ne pas penser et designer dans le sens inverse
C’est plus ou moins le même thème, mais par exemple faire un slider en jquery de haut en bas nécessite 2 includes et un appel… ultra simple. Tenter de faire ce même slider de bas en haut complique beaucoup les choses… donc penses-y au moment où tu design l’espace et les mouvements.

Les images en fond d’écran “fullsize”
C’est certes très joli (je connais quelques exemples qui rendent super bien) mais cela pose pleins de problématiques qui parfois peuvent emmener des tas d’emmerdes, en fonction de la taille du navigateur, de la hauteur du contenu, etc… et passer d’un dev trivial à un dev chaud avec plein de code javascript bizarre qui risque de ralentir de façon considérable le projet

Mettre le design dans son contexte
C’est très souvent oublié par beaucoup de graphistes, on nous rend un projet, une page, mais qui n’est pas remis dans son contexte. Quand le navigateur est très grand (1600 pixels de large par exemple) comment viens se câler le design de 990 pixels de large? Centré, câlé à gauche, à droite? Avec une marge sur le côté, en haut? Pensez-y…

Les PSD
Tel un gros orc bourrin ton arme favorite est le PSD de 40 Mo, voici donc quelques tips pour ne pas te faire haïr par les devs avec qui tu risque de travailler

Anti aliasing

un PSD fourre-tout
On y trouve tout et surtout n’importe quoi, des calques non utilisés ou vides, qui ont tendance à nous embrouiller lors des tentatives de découpage et d’export… j’ai déjà vu plusieurs version de design sur le même PSD, bref un galère pour savoir quoi garder et quoi mettre à la poubelle

les calques pas nommés ou avec des nommages inutiles
Je pense qu’on a tous vécu ça, un PSD de 30 Mo, avec 200 calques, aucun groupe et surtout des claques qui s’appellent de façon très originale “calque 1″, “calque 2″, etc.. Allez retrouver le bon morceau du design à exporter avec ça.
Comme pour les dev qui mettent des variables “prout” dans leur code, le mieux (même pour toi ami graphiste) pour s’y retrouver est encore de tenter de nommer les calques de façon correcte et compréhensible par tous.

des groupes de groupes de groupes, de groupes…
Grouper les calques c’est bien, en faire trop, ça ne sert pas à grand chose et cela à même tendance à compliquer le tout. Si un groupe a un seul calque, ce n’est plus un groupe (puisque la définition d’un groupe c’est que y’a plusieurs éléments à l’intérieur), donc tentez là aussi de grouper les calques sous un même thématique. Pas besoin de grouper comme des psychopathes, si les calques sont bien nommés ils parleront d’eux même.

Le web c’est 72 dpi pas 300
je sais que ça peut paraître bizarre, mais il m’arrive encore de temps en temps de recevoir des fichiers conçus en centimètres ou en pouces avec un définition print pour un montage web. Cela peut paraître anodin et vous allez me dire “Oh arrêtes de faire ta chochote t’a juste à le redimensionner”… certes, mais toutes les tailles des typos, les espacements, etc… s’en trouvent chamboulés, et puis c’est le travail du graphiste de nous remettre un fichier exploitable.

Penser à l’antialiasing
Le Gaming OldSchool j’adore ça, j’aime aussi beaucoup l’art 8bit, mais sorti de son contexte c’est moyen. Faites donc attention à l’antialiasing, sinon toutes vos polices, dégradés, ombres ou courbes risquent de rendre super moche, voir juste inexploitables.

Fournir les polices manquantes (ou pas système)
Si vous utilisez des polices non systèmes (qui ne sont pas inclus dans les principalement plateformes) ou exotiques, vous avez deux choix: rasteriser toutes les polices (si les textes ne changent pas) ou nous fournir des fichiers exploitables pour pouvoir utiliser correctement vos PSD. Si ce n’est pas le cas, vous courrez le risque de voir vos polices substituées par des polices système et donc votre design être dégradé.

Penser au découpage et à l’export
Vous savez utiliser des fonctions super funky de masquage de calque sur Photoshop c’est très bien, mais moi je sais pas l’utiliser, et ce que j’ai besoin c’est de pouvoir exporter votre travail en optimisant le temps passé dessus. Pensez donc qu’il peut y avoir deux versions de votre fichier: celui sur lequel vous travaillez (avec vos masques et tous vos trucs bizarres de graphistes) et la version pour export, plus simple et beaucoup plus basique.

Non mon but n’est pas ici de relancer la sacro-sainte guéguerre Dev contre Graphiste, mais justement de donner des clefs aux uns et aux autres pour comprendre pourquoi les graphistes râlent sur les Dev qui eux même râlent sur les Graphistes (et les Chefs de projet, les marketteux et globalement tout le monde)

Quelques conseils pour finir:
– n’hésitez pas à poser des questions à votre dev préféré: il n’y a aucune honte à poser des questions, aucune question n’est idiote, surtout si ça vous fait économiser du temps (ainsi qu’au dev) donc n’hésitez pas. Est ce que c’est faisable, chiant à monter, est ce que tu es capable de le faire, est ce que ça va pas nous mettre hors-budget? Just ask (damn it!)
– nettoyez vos PSD: rien n’est plus insupportable pour un dev que de devoir passer une demi journée à nettoyer le PSD qu’un graphiste viens de lui remettre (c’est d’autant plus désagréable quand il s’aperçoit que ce n’est pas la version finalisée du projet). L’état de votre PSD est très caractéristique de l’estime que vous avez de lui… faites un peu le ménage et il vous en sera très reconnaissant.
– demandez ce que le dev a besoin: sans tomber non plus dans l’exagération, vous pouvez échanger un peu sur les préférences sur le nommage des calques ou les éléments à exporter, cela facilitera la vie à tout le monde.

Voilà j’espère que nos joyeux amis graphistes ne se seront pas offusqués, et je suis sûr que pleins de dev ont des histoires de psd horribles à raconter, donc je vous laisses les commentaires pour le faire.



Laissez un commentaire