Guidelines pour produire des PSD adaptés au web

Je préparais dernièrement un document pour un boulot afin de montrer à des boîtes de créa print comment faire des PSD propres pour le web. Le but inavouable de la démarche était d’éviter de se retrouver avec des charniers inexploitables en intégration, chose qui arrive encore un peu trop souvent.

Pas de règles de ninja ou de gimmicks avant-gardistes ici, juste des bonnes bases saines pour faire un boulot clean. J’ai omis sciemment les nouveautés CSS3 et autres gadgets pour me focaliser sur l’essentiel. Après avoir soumis ma petite liste sur Twitter et à quelques copains, j’ai constaté que beaucoup avaient leur mot à dire sur la question et il m’a paru intéressant de publier la chose pour avoir des retours plus complets.

Dernière modification : le 12 juin 2014.

Préparer le fichier

Quelques règles de base et rappels simples pour préparer un document web-safe :

  • Travailler en RVB et profil sRVB (pas de CMJN !).
  • Travailler en px (pas de pt, de cm ou autre). Et les dpi (ou ppi), on les laisse pour le print, ça ne nous concerne en rien.
  • Utiliser les repères de document pour définir de façon stricte et inaltérable le zoning du site et s’y tenir (sauf exception dûment identifiée). Idéalement utiliser une grille (personnalisée ou non, voir par exemple Blueprint, 960…).
  • Utiliser l’alignement automatique des formes vectorielles sur la grille (« magnétisme des pixels » dans les options des formes) de façon à éviter les pixels « flous » sur les formes simples.
  • Ne jamais aplatir :
    • Les textes doivent rester sélectionnables.
    • Les images doivent, dans la mesure du possible, être traitées de façon réversible, à l’aide de masques bitmap ou vectoriels et de styles de calques. L’idéal étant d’utiliser des objets dynamiques et de recadrer avec des masques vectoriels.
  • Ranger et nommer de façon intuitive les calques dans des dossiers imbriqués de manière logique et fournir un PSD avec les calques et groupes repliés.
  • Si certaines zones du layout sont génériques au site (header, footer, sidebar…), utiliser les objets dynamiques afin d’alléger le poids du document. ATTENTION cependant à ne pas abuser des objets dynamiques, il est pénible pour l’intégrateur d’ouvrir 50 objets imbriqués pour isoler un texte ou une image !
  • Limiter la taille du PSD autant que faire se peut (supprimer les calques non-visibles et les versions de travail, rester vigilant sur la taille des objets dynamiques importés).

Adapter la créa aux contraintes web

Quelques règles à garder en tête au moment de la phase de création :

  • Tenir compte de la cible du site lors du dimensionnement du layout. Par exemple pour un site desktop d’une résolution cible de 1024×768, la largeur de la surface « utile » du site en devra pas dépasser 960px maximum (849px pour être sûr d’être dans les clous).
  • Pour un site responsive dont le design changera et s’adaptera en fonction du viewport du poste client, s’assurer que l’ordre des contenus suive la même logique d’un palier à l’autre. Identifier les exceptions et les limiter dans la mesure du possible.
  • Dans le cas d’un site supportant les devices haute définition (HDPI, Retina), prévoir que les éléments de design devront être fournis en taille doublée. Si possible, créer ces éléments directement en format vectoriel.
  • Utiliser en priorité les polices web-safe pour tout le contenu dynamique (texte, titres, onglets…), parmi lesquelles :
    • Arial ;
    • Verdana ;
    • Georgia ;
    • Times New Roman ;
    • Courier ;
    • Impact ;
    • Comic Sans (avec parcimonie…).
  • Utiliser dans un second temps seulement les polices non web-safe, et dans ce cas être extrêmement vigilant sur :
    • La licence de la typographie retenue (s’assurer qu’elle couvre bien les usages web via @font-face) ;
    • L’intégrité de son rendu sur le web (de grosses différences peuvent apparaître selon la qualité de la fonte) ;
    • La présence des caractères accentués dans les différentes langues nécessaires (y compris les majuscules !).
  • Ne jamais utiliser une taille de police inférieure à 10px.
  • Le pixel est un entier indivisible, éviter les tailles de police à décimales comme « 12.5px » !
  • Ne pas lisser le texte en dessous de 14px. OK, arrêtons avec celle-là, RIP Windows XP.
  • Pour les fontes web-safe, limiter drastiquement les variations de graisse, seules deux sont disponibles en CSS : regular (400) et bold (700). Oubliez light, black, etc.
  • Pour les fontes @font-face, limiter également ces variations : chacune d’entre elles devant être ajoutée en tant que nouveau fichier typographique sous peine d’être (mal) émulée par le navigateur, leur accumulation est rapidement coûteuse en poids.
  • Utiliser avec modération les propriétés d’approche / crénage des caractères, qui sont beaucoup moins souples en CSS que sous Photoshop (se méfier notamment des approches négatives). Ne surtout pas modifier exceptionnellement une approche sur un texte sous prétexte que ça le fait « entrer » dans son conteneur !
  • Utiliser l’option « majuscules » dans la palette caractères pour les textes en majuscules. Ne pas les taper directement en majuscules !
  • Utiliser de préférence du texte de paragraphe (bloc de texte et pas texte seul).
  • Décocher l’option « césure » pour les textes de paragraphe, dans la mesure où cette option n’existe pas en CSS (ou pas partout, ou pas bien).
  • Préférer les longs blocs de texte (contenant à la fois titres, paragraphes, listes à puces…) afin de faciliter le copier/coller du rédactionnel. Mettre en forme grâce aux propriétés de taille, de retrait et de justification de l’outil texte (ne pas bourrer d’espaces !).
  • Préférer l’insertion des textes en les copiant/collant directement depuis le document d’origine (Word, Powerpoint, etc.), afin de conserver la ponctuation et la micro-typographie. Ne pas les recopier à la main !
  • Traiter à part les puces graphiques des listes (les extraire du rédactionnel pur).
  • Éviter de faire des cas particuliers trop séduisants en alignant au pixel près les textes « lorem ipsum » pour servir la créa : ces zones de texte sont amenées à évoluer, elles doivent rester souples et être comprises comme telles.
  • Préférer les couleurs pleines aux couleurs obtenues par superposition, alpha, fusion (surtout pour les textes, les ombres portées et les contenus dynamiques en général). Les modes de fusion n’existent pas en CSS (ou en tout cas pas sur tous les navigateurs) !
  • Ne pas skinner les éléments système select, radio ou checkbox.
  • Prévoir les comportements visuels des états link, hover, focus et visited pour les éléments qui le nécessitent (navigation, liens, formulaires…).
  • Prévoir que les principaux conteneurs seront extensibles en hauteur. En conséquence, éviter notamment d’utiliser des dégradés radiaux et diagonaux dans ces blocs, et prévoir des textures « qui bouclent » si jamais textures il y a.
  • Anticiper l’internationalisation : si le site est prévu en plusieurs langues, prévoir que certains textes prennent nativement « plus de place » (comme l’allemand), « moins de place » (comme l’anglais) voire ont des sens de lecture différents (comme l’arabe, ce qui implique des chantiers plus importants) ou nécessitent des tailles de police plus grandes pour être lisibles (langues asiatiques).

Et voilà. Cette liste est en constante évolution à mesure que le web évolue, n’hésitez pas à apporter votre pierre à l’édifice, que ce soir pour ajouter, retirer ou contester une partie.

Pour finir, Romy me rappelle très justement son billet sur le même sujet, qui peut être un complément intéressant.

Je rajoute aussi le lien proposé par Colegram, Photoshop Etiquette (en anglais).

Posté le 23 novembre 2010

Arf, le champ est vide…

Tous les billets de blog

Commentaires (59)

  • Très chouette checklist, que je suis surpris de ne pas avoir lue plus tôt, tellement elle est essentielle.

    Pour compléter ton propos : quelques astuces supplémentaires ; qui en effet ne méritent pas d’être gravées dans le marbre cependant.

    • Connaître les rendus par défaut des propriétés CSS 3 (ombrés, bordures, etc.) afin de les restituer au plus proche dans Photoshop ;
    • utiliser une grille verticale et horizontale ;
    • ne pas hésiter à user et abuser de l’outil « Annotation » ;
    • pour la safe area, je conseille de consulter ce très bon résumé chez Designers Toolbox ;
    • pour les polices web safe, Code Style propose lui un excellent condensé ;
    • produire une palette de couleur me semble une bonne astuce également, qui permet de s’assurer qu’aucune dégradation ne sera effectuée à ce sujet ;
    • ne lissez pas vos textes d’une taille inférieure à 12 pixels (c’est plus compliqué que ça, mais ça donnera une bonne idée de départ ;
    • enfin, je sais qu’il est souvent d’usage de présenter la maquette dans un faux navigateur pour aider le client à se projeter et que produire un export (toujours à jour !) du psd est plus que pratique.
    #1 par Vincent

    23 Nov. 2010 à 12h38

  • Yeah, si ça pouvait tourner dans toutes les agences…

    “Préférer les couleurs pleines aux couleurs obtenues par superposition, alpha, fusion (surtout pour les textes !).” Si seulement…

    #2 par Bouctoubou

    23 Nov. 2010 à 12h48

  • Comme je disais sur Twitter, cet article arrive à point. En effet cela fait un moment que, en tant que graphiste, je me pose la question de savoir comment traiter au mieux nos PSD pour que nos amis intégrateurs nous aiment 🙂

    Et ce genre de check-list ne pouvait pas être mieux rédigé que par des intégateurs.

    Merci à tous ceux qui ont participé et participeront dans ces commentaires.

    J’imprime ce document et l’accroche sur mon tableau en liège …

    #3 par pixenjoy

    23 Nov. 2010 à 12h49

  • Petit soucis avec mon Blog (problème de validation de paiement chez Gandi), mais j’avais laissé deux trois règles trainer ici concernant le poids des fichiers :

    http://www.bootleygues.net/index.php?post/2010/10/16/Julien-%3A-Tips-and-Tricks-de-la-production-de-design-avec-Photoshop

    Je rajouterai également une règle primordiale souvent oubliée qui est la gestion des états des liens qui donnent une information précise sur la navigation à savoir link, visited, active et hover.

    Il y a beaucoup à gagner en faisant intégrer le plus tôt possible un grid system dans la création et la conception. Cela permet aux équipes de se caler sur les même grilles.

    #4 par Adrien Leygues

    23 Nov. 2010 à 12h57

  • “Il y a beaucoup à gagner en faisant intégrer le plus tôt possible un grid system dans la création et la conception. Cela permet aux équipes de se caler sur les même grilles”

    Merci Adrien ! En fin un tech. qui approuve l’utilisation des grids système. (Il n’y a que Thomas Parisot qui semblait les promouvoirs côté intégrateur)

    Cela fait 2 ans que j’essaye de faire comprendre cela aux intégrateurs (cf ma conf ParisWeb 2009) et jusqu’ici je n’ai eu que des retours du style “les grid système c’est beurk !”

    #5 par pixenjoy

    23 Nov. 2010 à 13h17

  • Hello Christophe, bonne idée cette checklist ! J’aurais quelques recos à ajouter, mais je pense que ce serait hors-sujet parce que tu te situes dans le cadre d’un PSD et non d’un projet de plusieurs maquettes.

    Après je ne suis pas forcément d’accord avec Vincent sur le fait de devoir utiliser absolument une grille horizontale, attendons déjà que l’utilisation d’une grille verticale soit bien intégrée dans les habitudes avant de compliquer la tâche (oui idéalement il faudrait)

    L’utilisation de calques dynamiques pour les éléments répétés (boutons et autres éléments graphiques) devrait être obligatoire pour ne pas se retrouver avec 45 sortes de bouton “valider” par exemple.

    Une petite pensée également pour les différentes résolutions d’écran, comment mon desig, va se comporter en 800, 1024, 1600, sur petit écran, etc. Pensez à fragmenter les designs, stop aux gros placards d’images !

    #6 par Eric Le Bihan

    23 Nov. 2010 à 14h04

  • Bon récap, mais ça peut être dangereux : comment vous allez bien pouvoir vous dédouaner de vos intégrations foireuses maintenant ?

    krr krr krrr

    #7 par Julien

    23 Nov. 2010 à 14h22

  • chanmé. Des petits screenshots pour illustrer / donner des exemples ? (c’est juste pour contribuer gratuitement. Puis j’aime bien les images ça me donne des repères dans la hauteur d’une page. Non, bon d’accord je ne lis pas, je regarde que les images en fait)

    #8 par kazes

    23 Nov. 2010 à 14h45

  • Très bon billet.

    Il y a certainement d’autres éléments à ajouter à cette liste de bonnes pratiques déjà bien complète.

    J’ajouterais pour ma part, à propos des calques :

    • supprimer tout calque inutile (souvent masqués car ils ne servent pas en définitive) ;
    • communiquer des fichiers PSD dont tout les calques et groupes sont refermés (Ctrl + clic sur le triangle des calques, groupe de calques, de plus haut niveau)
    #9 par Emmanuelc

    23 Nov. 2010 à 15h30

  • Cool ! Ça complète, avec plus de précision, semblable article pour graphiste web débutant(e) : http://romy.tetue.net/premiere-maquette-web-comment-faire

    #10 par tetue

    23 Nov. 2010 à 16h19

  • Bien vue, la checklist, merci de la partager. Petit mot pour Pixenjoy, Thomas n’est pas le seul “tech” à promouvoir les grilles, j’en parle depuis, pfiou, très longtemps également : il n’y a pas que les participants à Paris Web dans la vie 😀

    #11 par bruno bichet

    23 Nov. 2010 à 16h28

  • Bruno,

    Mea culpa, je répare cet oubli. Dans le web, 2 intégrateurs au moins préconisent l’utilisation des grilles :

    Thomas et Bruno !

    On me dit dans l’oreillette que Vincent aussi … ( et il parait qu’il y en a d’autres mais ils n’osent pas le dire)

    #12 par pixenjoy

    23 Nov. 2010 à 18h40

  • Merci à tous pour vos réponses !

    @Vincent : Merci pour tes compléments, comme je le disais j’essaie de ne pas trop entrer dans le détail : CSS3, le rythme vertical, les annotations, les palettes de couleur, tout ça c’est bien sûr très bien mais c’est un peu trop « avancé » pour la liste que j’avais prévue (et c’est souvent absent de beaucoup de PSD que je considère quand-même « propres »). Bref, on pourrait prévoir une évolution pokemon de ce draft qui incluerait tout ça ! Je vais peut-être rajouter le lissage des fonts effectivement, mais je doute un peu de l’universalité de cette règle c’est pour ça que je l’avais écartée quand Jérémie Patonnier me l’avait suggérée. Pour ce qui est de présenter la maquette dans un navigateur, ça s’adresse plus au client qu’aux techos derrière, personnellement je ne trouve pas ça indispensable…

    @Bouctoubou : Fais-tourner 😉

    @Pixenjoy : J’espère que ça aidera, je ne sais pas si c’est très compatible Gimp par contre…

    @Adriens : Effectivement pour les liens, bien que j’aie un peu de réticences avec :visited depuis qu’il a été révélé que c’est une faille de confidentialité facilement exploitable. Pour les grilles je les ai mentionnées mais je ne suis personnellement pas très fan des outils CSS qui les supportent, je ne vais pas entrer dans le débat ici parce que Vincent va nous faire un joli billet sur le sujet (pas vrai ?).

    @Éric : Plutôt d’accord sur la grille horizontale, d’autant plus que c’est ultra pénible à mettre en place concrètement. Oui pour l’homogénéisation des éléments répétés, et oui pour les différentes résolutions mais là comme les points de Vincent on arrive pour moi dans du « advanced »…

    @Julien : Et sinon, tu penses quoi de cette taxe injuste qui touche les AE ? =D

    @kazes : Woh l’autre eh, c’est trop de boulot, je suis feignant moi !

    @EmmanuelC : Oui, c’est déjà dedans pour les calques inutiles, et oui effectivement pour les PSD « bien refermés », je vais le rajouter. Merci !

    @Romy : Roooh, j’avais complètement oublié ton billet (en plus j’avais commenté, honte, honte). J’irai sûrement faire mon marché chez toi =)

    @Bruno : C’est vrai, n’oublions pas Le Web ! =D Blague à part les grilles c’est peut-être très bien mais après avoir goûté Blueprint j’avoue que… j’aime pas. Bon, c’est pas le sujet ici de toute façon…

    Merci encore pour vos interventions, je mets à jour le billet… =)

    #13 par STPo

    23 Nov. 2010 à 18h51

  • Oui ça m’aide beaucoup car figure toi que j’ai décidé de remettre mes compétences PS à jour.

    Je souhaite fournir à mes clients des PSD plus optimisés car la compatibilité Gimp PS est de moins en moins optimale.

    #14 par pixenjoy

    23 Nov. 2010 à 19h11

  • Je fais tourner à mes amis graphistes débutants ou maitrisant mieux le print. C’est simple, précis, et un bon point de départ . Si on avait déjà toujours ça ce serait bien. Juste un petit truc en plus SVP > Donner un nom explicite aux calques et pas “calque 32” ou “objet vectoriel_copie” quand il y en a beaucoup, c’est long, c’est long de faire le ménage . et oui , oui, oui pour : > communiquer des fichiers PSD dont tout les calques et groupes sont refermés (Ctrl + clic sur le triangle des calques, groupe de calques, de plus haut niveau)

    Les intégrateurs(trices), au moins moi vous disent Merci , Christophe 🙂

    #15 par véronique lapierre

    23 Nov. 2010 à 23h43

  • @Gilles : OK je vois, donc tu vas te servir de Photoshop pour optimiser tes exports PSD ?

    @Véronique : Très justes remarques, j’en avais déjà un peu parlé mais sans doute pas de façon assez explicite, je corrige. Merci !

    J’ai mis à jour le billet !

    #16 par STPo

    24 Nov. 2010 à 10h46

  • «Cela fait 2 ans que j’essaye de faire comprendre cela aux intégrateurs (cf ma conf ParisWeb 2009) et jusqu’ici je n’ai eu que des retours du style “les grid système c’est beurk !”»

    J’ai essayé de pousser les grid systems chez nous, mais c’est côté graphistes que ça a bloqué, pas côté intégrateurs. Moi je dis ça, je dis rien…

    #17 par Florent V.

    24 Nov. 2010 à 11h48

  • merci, excellente initiative qui m’évite d’avoir à faire la même chose pour mes créas et éviter que mes intégrateurs ne déclarent la guerre.

    Je me réjouis quand même de voir que la majorité des points sont respectés chez nous, il faut du temps et de la patience pour changer les habitudes (bonnes ou mauvaises).

    beau boulot 😉

    #18 par vincent elmalih

    24 Nov. 2010 à 15h54

  • J’ai pensé à un truc en plus : l’internationalisation. Combien de fois je me retrouve avec des créas explosées dès qu’on passe le site en allemand… “oh bin zut, le texte dépasse de l’onglet de nav faut tout refaire” Je rajoute !

    @Florent : Chez nous, c’est les graphistes ET les intés qui n’en veulent pas =)

    @Vincent Elmalih : Merci, n’hésite pas à faire tourner oui !

    #19 par STPo

    25 Nov. 2010 à 11h20

  • À ce sujet, le finlandais prend encore plus de place que l’allemand ! mais est moins courant dans nos contrées, certes 🙂

    Tu peux citer l’hébreu aux côtés de l’arabe : à ma connaissance ce sont les deux seules langues très répandues à s’écrire RtL.

    Pour revenir au graphisme, les blocs avec dégradés en diagonale çaÿmal. Merci de consulter l’intégrateur avant de choisir ça, qu’il sache si c’est compatible avec l’extensibilité de cette zone-là. Horizontal et vertical no problemo

    #20 par Felipe

    25 Nov. 2010 à 14h42

  • Ah tiens, je viens de tomber sur une taille de font de 44.05px dans une créa. Ça me rappelle que le pixel est une unité entière indivisible, et qu’apparemment ça ne fait pas de mal de le rappeler. Je rajoute !

    @Felipe : Très juste remarque pour les dégradés radiaux / diagonaux, je vais le rajouter, merci =)

    #21 par STPo

    26 Nov. 2010 à 11h49

  • Sympa cette petite liste c’est une bonne idée ! C’est là où l’on comprend bien que pour faire du design web, mieux vaut connaître les contraintes liées au web. Ça parait pourtant simple à première vue :/

    #22 par Auré

    26 Nov. 2010 à 12h05

  • Bravo pour ce guideline et merci de le partager. Je vais le mettre en annexe de tout mes briefs créa, comme ça, le graphiste pourra pas dire qu’il ne savait pas !

    #23 par Ludovic - Consultant Web et e-commerce

    26 Nov. 2010 à 12h07

  • J’ajoute : éviter de trop jouer avec les crénage-approche (palette caractère de Photoshop) qui bien souvent ne sont pas reproductibles en CSS. L’inter-mot et l’inter-lettre sont assez “grossier” (pour le moment) dans les navigateurs. Exemple type : le crénage est modifié pour passer en une ligne dans la maquette mais casse sur deux lignes dans un navigateur.

    #24 par Emmanuel C.

    26 Nov. 2010 à 12h36

  • @Auré : Merci, oui effectivement pour les contraintes, même si certains affirmeront qu’il faut savoir s’en affranchir pour réellement “créer” (non, pas de noms)…

    @Ludovic : Avec un crédit de l’auteur et un lien, aucun problème, bien au contraire !

    @Emmanuel : Bien vu, j’en avais un peu parlé dans les “cas trop séduisants” mais je complète. Merci !

    #25 par STPo

    26 Nov. 2010 à 20h47

  • Et encore des bonnes pratiques… Avec ça effectivement il n’y a plus de place pour foirer sa créa, tout comme en intégration avec celles de Elie… Seulement voilà, ça bloque toujours quelque part… l’intégrateur… le graphiste… mais aussi la direction artistique, non ? Alors j’ai en vie de dire WTF ? Merci à vous qui nous montrez la voie…

    #26 par ctito17

    26 Nov. 2010 à 21h08

  • Et voilà comment des guidelines intéressantes pour ranger un PSD déjà fait et ne pas faire n’importe quoi se transforment en règle fantasmées pour les intégrateurs.

    Je ne rigole qu’à moitié. Pas de dégradés en diagonales ou radial ? RLY ?

    #27 par Julien

    26 Nov. 2010 à 21h29

  • @ctito17 : La direction artistique et le web design sont deux choses distinctes, ici je ne parle que de web design (et encore, que de la partie qui peut éventuellement poser problème techniquement). Il ne manquerait plus qu’on empêche aux DA de faire leur boulot tiens !

    @Julien : Je ne te refais pas notre discussion en off, l’idée ici n’a jamais été de “ranger un PSD” mais de “produire un PSD adapté au HTML”. Se mêlent donc (de façon un peu anarchique il est vrai) règles et recommandations, les unes étant indiscutables, les autres relatives au contexte (merci Élie Sloïm sur ce point). Ça mériterait un tri, je le ferai peut-être plus tard quand mon agenda s’éclaircira…

    #28 par STPo

    27 Nov. 2010 à 10h15

  • @Julien : le psd est en quelque sorte le cahier des charges de l’intégrateur. Certains éléments, s’ils sont bien renseignés (et c’est ce dont on parle ici il me semble) vont être reporté à l’identique dans la CSS. Par exemple des codes couleur, des cotes en pixel, des tailles typo etc.

    Plus le graphiste portera attention à ces éléments, et mieux la chaine de production s’en portera, et mieux l’intégration sera fidèle à la maquette, et moins elle laissera place à l’interprétation approximative, faute d’éléments clairement définis.

    Pour prendre une comparaison, l’architecte ne communique pas ses croquis initiaux aux différents corps de métier construisant un bâtiment. Les croquis sont très importants pour donner une idée, communiquer l’intention, la sensation, mais ce sont des plans précis qui sont communiqués aux constructeurs, ne laissant pas (ou le moins possible) place à l’interprétation.

    Cela étant - et c’est un point acquis pour les architectes - le plan, même le plus précis, N’EST PAS l’édifice, c’est une représentation, une vue de l’esprit de celui-ci. De fait, même respecté au plus près, si l’on reprend les cotes d’un bâtiment après construction et qu’on le compare au plan, il sera différent. Prends ton logement, mesures-le au centimètre près, reporte-le sur plan. Il y a déjà de quoi s’amuser à le constater (et je ne parle même pas des angles droits qui ne le sont pas tout à fait).

    Plan != bâtiment et PSD != écran intégré. Le travail étant de minimiser la part d’interprétation et ne pas dessiner des choses infaisables dans le réel.

    Maintenant, si un PSD ne doit pas s’encombrer de tout ces détails techniques et qu’il doit rester au niveau du croquis (avancé) de l’architecte, alors on entre dans le domaine de l’interprétation totale du plan, et alors là, port du casque fortement recommandé 🙂

    #29 par Emmanuel C.

    27 Nov. 2010 à 11h59

  • @STPo Une question me vient à l’esprit : qui endosse le rôle de webdesigner alors ? La DA, le graphiste, l’intégrateur ? Il y a bien 3 métiers, même si souvent ils ne font qu’un ou deux (pour les free, peut être ?). Dans ce cas, on a bien un problème notamment sur la mise en place des grilles. Si ce n’est pas prévu par l’un ou l’autre l’intégrateur ne peut la mettre en place. Il faut donc revoir le process…

    #30 par ctito17

    27 Nov. 2010 à 20h41

  • @Emmanuelc : Amen !

    @ctito17 : Tu peux même remonter plus haut en fait, le web design commence avec le travail des ergonomes en amont de la créa… La DA pour moi c’est transversal en revanche, je te renvoie à cet excellent article d’A List Apart qui en parlera bien mieux que moi : http://www.alistapart.com/articles/art-direction-and-design/

    #31 par STPo

    28 Nov. 2010 à 17h46

  • Si vous faites un fond, par pitié, traitez le plus grand, ou faites-le répétitif. Ben oui, des fois, on est plus haut que prévu.

    Ah oui, ayez pitié pour les devs qui se retrouvent intégrateurs et qui n’ont pas photoshop. Exportez chaque page dans un PSD différent (Gimp ne gère pas les groupes de calques), et profitez-en pour décrire vos idées de cinématiques.

    Si vous faites des boutons ou d’autres zones actives avec hover graphique, faites des versions de TOUTES les versions hover.

    #32 par Da Scritch

    13 Déc. 2010 à 18h08

  • Ça, c’est pour le troll : http://www.reinegger.net/50_reasons_not_to_use_photoshop_for_webdesign.html

    (perso, je ne peux juger)

    #33 par Da Scritch

    13 Déc. 2010 à 21h13

  • @STPo : j’ai mis à jour mon article sur le brief créatif pour un site web, avec la mention de ton guideline à la fin http://www.ludovicpassamonti.com/archive/2009/03/30/rediger-bon-brief-creatif-pour-creation-site-internet.html

    #34 par Ludovic

    14 Déc. 2010 à 10h01

  • @Da Scritch : Sans les groupes de calques ça devient un peu ingérable quand-même… Le pré-requis de cette liste était tout de même de travailler avec Photoshop ! Concernant ton troll, Fireworks est effectivement un très bon outil, mieux adapté au web que Photoshop mais hélas aussi beaucoup moins utilisé… Dommage.

    @Ludovic : Merci =) Très intéressant, ton blog !

    #35 par STPo

    14 Déc. 2010 à 19h54

  • Ton billet est en bonne place dans mes favoris ! Excellente guideline 🙂

    Pour compléter, le viens de tomber sur ce site qui va dans le même sens : http://photoshopetiquette.com/

    Merci pour cette compilation de bonnes pratiques !

    #36 par Colegram

    20 Jan. 2011 à 09h43

  • @Colegram : Intéressant ! Je vais y piquer des trucs, notamment le passage sur la césure de paragraphe, que j’avais oublié…

    #37 par STPo

    20 Jan. 2011 à 12h52

  • Bonjour, il semble que la première règle de base soit aujourd’hui contredite, voici un peu de lecture… 🙂 http://www.lesintegristes.net/2011/05/06/web-resolution-72dpi/

    #38 par Clacla des Bois

    8 Mai 2011 à 21h35

  • @Clacla des Bois : Effectivement, très bon article de Florent ! Je gardais cette règle dans l’espoir secret que les printeux “convertissent en 72dpi” leurs visuels avant de les importer dans Photoshop en tant qu’objets dynamiques, réduisant ainsi tacitement (et drastiquement) leur poids.

    Du coup je supprime cette règle mais répercute l’idée derrière en complétant d’autres règles avec un avertissement. Merci à toi.

    #39 par STPo

    25 Mai 2011 à 09h38

  • Hello,

    Un truc pas mal, ça serait d’avoir les version sans JS des pages. Comment afficher le carrousel, les tooltip les messages d’erreur de formulaire etc.

    #40 par Bluety

    25 Mai 2011 à 14h28

  • @Bluety : Merci pour ta suggestion, mais on entre là dans des subtilités méticuleuses qui sortent un peu du périmètre “réaliste” que j’aimerais garder pour ces guidelines. Je ne retiens donc pas, même si dans un monde idéal évidemment ce serait bien.

    #41 par STPo

    26 Mai 2011 à 10h36

  • Magnifique !

    Un énorme merci pour cette superbe ressource.

    #42 par Aurélien

    9 Août 2012 à 09h10

  • Dans le cadre du débat sur le lissage des polices, il serait intéressant de demander aux graphiste de cesser de jouer avec les différents niveaux proposés par Photoshop pour obtenir différents niveaux de graisse. C’est insupportable et la croix de faire entendre aux clients que non, en Web, nous n’avons que les états normal/gras et non normal/gras/un chouilla plus gras/gras plus dense/etc…

    #43 par piouPiouM

    9 Août 2012 à 10h08

  • @PioumPioum : Tu mélanges deux points (lissage et graisse), mais c’est pertinent, je vais rajouter ça !

    #44 par STPo

    9 Août 2012 à 10h49

  • @STPo je ne mélange pas, sous CS5 c’est bien le sélecteur « Définir la méthode de lissage » associé à la graisse qui permet de simuler des dizaines de graisses différentes.

    PS : c’est piouPiouM, avec un seul « m » ;-p

    #45 par piouPiouM

    9 Août 2012 à 11h09

  • Un petit pas pour l’humanité, un grand pas pour les graphistes : merci pour cette liste que je ne manquerai pas de partager dès que possible !

    À propos des méthodes de lissage, la pratique m’a fait réaliser que le lissage « Gras » de Photoshop se rapproche le plus du rendu final des polices dans le navigateur, en règle générale, et ce qu’il s’agisse de polices web safe ou de polices à traiter avec @font-face.

    Sur certaines typos, il est même très important d’utiliser ce lissage et surtout pas le lissage « Net » ou « Précis » car cela peut créer un fossé entre l’aspect et la taille perçue de la police dans Photoshop, et celle rendue par le navigateur. On a eu le problème sur le site de l’ENSSIB avec Georgia, par exemple.

    L’absence totale de lissage rend super bien sur des typos comme Verdana, mais uniquement pour les petites tailles. Dès que tu pousses un peu, ça fait vite moche.

    Bien sûr, il y a des exceptions, mais dans 90% des cas, le lissage « Gras » est le moins déceptif quand on compare la maquette et le rendu navigateur.

    (NB : j’aurai l’occasion de creuser un peu le problème du rendu des polices @font-face dans un article à paraître bientôt sur le blog de Clever Age.)

    #46 par kReEsTaL

    9 Août 2012 à 11h33

  • @PiouPioum : Alors c’est l’outil qui mélange (je ne connais pas CS5, CS2 différencie bien les deux)… Cela étant, c’est ajouté !

    @Marie : Avec un outil comme Photoshop, on ne fera de toute façon jamais que singer graphiquement un rendu espéré sur navigateur… J’ai envisagé ajouter la gestion parcimonieuse des différentes méthodes de lissage offertes par Photoshop dans cette liste, mais c’est tellement aléatoire (OS, browser, fonte) et finalement pas bloquant derrière (en CSS) que j’ai abandonné l’idée. Vivement ton article, cela dit !

    #47 par STPo

    9 Août 2012 à 12h03

  • “I have a dream” 🙂 Je pense que cela reste encore utopique de voir ces règles appliquer à la lettre. Mais faut bien commencer quelque part.

    Les grilles c’est la vie !

    Sur la taille minimale j’aurais été plus dur que toi. En dessous de 14 pixels je considère que ce n’est pas adapté au média web.

    Ha et puis aussi le contraste ! “Pensez à utiliser un contraste suffisant entre le texte et son conteneur” parce que #f9f9f9 sur #f0f0f0 ça vous tue les yeux !

    #48 par William

    9 Août 2012 à 12h13

  • Hum, je suis d’accord avec la plupart des guidelines. Mis a part deux points que je trouve antiproductifs et sont un vrai frein au design :

    - D’une part les typos : oui pour le check licence, non pour se forcer a utiliser les typos safe en premier. Font-face est la pour ca, on s’en est tapé pendant des années, il est temps que ca change !

    -En ce qui concerne les chekckbox et autres radiobutton… ceux du systemes sont hideux, faire un site vitrine avec super design et se taper la vieille lsite déroulante systeme, mais non ! Et c’est pas en se contentant d’utiliser ceux systeme que ca va pousser des developpeurs à créer des solutions pour en implementer des beaux rapidement…

    Bref sinon très bon article.

    petite precision : dans les preferences de Photoshop CS6 il y a maitneant une option pour que tout ce qui est vecto se cale sur les pixels (ouioui meme pendant un pomme+T)

    //a

    #49 par Adrien

    9 Août 2012 à 13h53

  • En ce qui concerne les chekckbox et autres radiobutton… ceux du systemes sont hideux, faire un site vitrine avec super design et se taper la vieille lsite déroulante systeme, mais non ! Et c’est pas en se contentant d’utiliser ceux systeme que ca va pousser des developpeurs à créer des solutions pour en implementer des beaux rapidement

    Ils ne sont pas hideux mais propres à chaque système et les utilisateurs y sont habitués. Les éléments ainsi sont clairement et rapidement identifiés. De plus, intégrer de tels composants avec des contraintes de performances n’est pas une sinécure (CSS, sprites, JS avec lourde manipulation du DOM en sus) mais cet aspect est bien souvent négligé/oublié par les graphistes. De même, la réflexion de l’usage d’éléments de formulaires personnalisés s’arrête bien souvent aux clients desktop, alors qu’ils ruinent totalement l’expérience utilisateur sous mobile. Par exemple, n’activez pas Chosen sur Androïd ou iPhone et laissez la main au navigateur qui fera un bien meilleur travail !

    #50 par piouPiouM

    9 Août 2012 à 14h37

  • Oui je suis totalement d’accord avec toi à propos de l’aspect aléatoire de la chose !! Tellement de paramètres entrent en compte…

    Certains clients qui ne sont pas habitués au web ont du mal parfois à comprendre les différences de rendu, parfois violentes, entre une image et une interface web. Quand j’utilise le lissage « Gras », j’ai constaté que j’ai moins de remarques de ce genre au sujet des typos que d’habitude, en tout cas sous Mac ; sous Windows ou Linux, on a toujours un rendu moins lissé, quoi qu’on fasse…

    Il faut prendre son mal en patience, et miser sur les pures typos OpenType, dont les glyphes ont été dessinés récemment, pour limiter la casse ; utiliser FontSquirrel pour tout remettre d’équerre, et toujours tester abondamment.

    À propos, un point qu’il serait bon d’ajouter dans la checklist, même s’il ne me semble pas dénué d’utopie : que les graphistes testent eux-mêmes dans un échantillon d’OS et de navigateurs les typos @font-face qu’ils comptent utiliser dans leurs créas avant de faire valider par le client et de livrer les maquettes pour intégration !

    Car ça aussi, c’est une plaie : tu as un super design top moumoute qui utilise Futura (par ex.), mais le problème c’est que Futura n’est pas libre de droit, il n’existe donc pas de version OpenType re-dessinée récemment de cette typo. On ne peut donc qu’utiliser le fichier TTF de pépé en @font-face, qui donne un résultat très, très moche sous IE, même avec le meilleur FontSquirrel du monde.

    Je peux citer la même anecdote pour les typos récupérées sur DaFont, qu’on retrouve, oui, oui, dans certaines maquettes web « pro »… Inutile de dire qu’après quelques tests réalisés en inté (parce que les graphistes n’ont pas toujours les machines virtuelles qui vont bien pour faire les tests ad hoc), ces polices ont été bannies séant du royaume, pour incompatibilité totale avec le web.

    Cela a un effet immensément déceptif pour les clients qui ont adoré la maquette de base avec la typo top moumoute qui collait parfaitement… Même si les graphistes trouvent finalement toujours une police de substitution, qui rappelle le plus possible celle qui a été utilisée au tout début, le mal est fait, car le client sait à quoi aurait pu ressembler son site dans le meilleur des mondes. Il a le sentiment d’avoir droit à un lot de consolation, et je le comprends très bien !

    D’où la nécessité, selon moi, que les web designers qui souhaitent utiliser une typo @font-face testent eux-mêmes (ou demandent à un intégrateur de tester avec eux) le rendu de cette typo sous différents OS et navigateurs, avec cet outil fantastique qu’est Web Font Specimen 🙂

    Certes, ça prend un peu de temps, et c’est assez frustrant car on se rend vite compte qu’il n’y a pas tant de typos réellement conçues pour le web que ça, mais ça évite de la frustration et de la déception de tous les côtés, ainsi que du temps perdu en inté…

    #51 par kReEsTaL

    9 Août 2012 à 15h04

  • @Adrien : Les directives données ici sont évidemment à pondérer selon les contraintes du projet. Personne n’interdit à personne d’utiliser @font-face, la reco c’est « attention, ce n’est pas gratuit en termes de perfs, ne l’oubliez pas au moment du design ». Si tu arrives avec 50 graisses différentes de ta @font-face dans ta créa, tu vas de toute façon te faire envoyer bouler par les techos… alors autant anticiper. Concernant les formulaires, c’est un troll débat (coucou Yamo) qui a fait déjà couler énormément d’encre ici et ailleurs… PiouPioum a bien décrit pourquoi on n’avait encore pas trop le choix, hélas : les solutions proposées par les développeurs (bidouilles JS variées) existent, mais elles sont TOUJOURS imparfaites (d’autant plus aujourd’hui avec la multiplication des devices mobiles), et les solutions présentées par les implémenteurs (les seules véritablement pérennes) tardent à venir. Encore une fois ça ne veut pas dire « ne le faites jamais » mais « soyez conscients du problème ».

    @PiouPiouM : D’accord sur les contraintes techniques (très) fortes qui obligent les intés à faire des concessions sur les formulaires skinnés, pas d’accord sur le fait que « les gens sont habitués à leur skin OS ». Même si c’est vrai pour certains utilisateurs, j’attendrai d’avoir sous les yeux des statistiques fiables pour valider une telle affirmation, que je considère pour l’heure plutôt contre-productive. Je connais des personnes qui détestent avoir des contrôles OS dans leurs formulaires web, voire qui ne les comprennent tout simplement pas lorsqu’elles sont amenées à utiliser une bécane qui n’est pas la leur (avec un OS différent de celui auquel elles sont habituées donc). Et n’essayons pas de justifier l’injustifiable, avoir un input text totalement dépareillé du select qui le suit reste logiquement incompréhensible : soit c’est tout l’un (rien de skinnable) soit tout l’autre (tout skinnable), mais cet entre-deux qui dure depuis 15 ans est insupportable.

    @Marie : Tu as raison sur le fait qu’il faut faire valider les typos en amont, c’est ce que suggérait le point sur les licences. Et sur le fait qu’idéalement, les tester en conditions réelles avant de les utiliser en créa sur Photoshop devrait être systématique, afin de s’assurer de leur intégrité. Je rajoute ce point…

    #52 par STPo

    9 Août 2012 à 17h41

  • Je ne comprendrai jamais pourquoi les web designers utilisent Photoshop et pas Fireworks. 🙁 (hashtag coeur de frontend dev barré)

    #53 par _kud

    13 Oct. 2012 à 17h12

  • Salut à tous,

    J’aime envoyer cet excellent article à certains graphistes 🙂

    Par exemple, en ce moment, je travaille sur les PSD de quelqu’un qui semble avoir lu cet article et a du se dire : “Tiens, je vais faire tout le contraire de ce qui est dit ici!”. Cerise sur le gâteau, voici ce qu’il m’a envoyé : http://www.federici.fr/poubelle/psd-brouillon.jpg

    Inutile de dire que j’ai refusé de travailler avec des PSD aussi bordéliques…

    #54 par Eric Federici

    26 Mar. 2013 à 12h30

  • Les psd fournis le sont fréquemment par des graphistes qui ne connaissent rien au web. Une des erreurs que je rencontre le plus souvent c’est l’absence d’échelle et de contexte. Donc par-exemple on me fournit un psd dont le site semble faire 2000 pixels de large, mais en fait non, c’est juste que le graphiste était pas au courant qu’il y avait une largeur à respecter, et donc je suis censé remettre le psd “à l’échelle”. Comme si c’était un plan d’architecte ^^ Ou alors on me fournit un psd de 1000 pixels de large, mais sans rien sur les côtés, si bien que je ne sais pas si le site est censé être centré ou pas. Une bonne habitude c’est d’avoir un calque représentant la fenêtre du navigateur; ça permet de partir sur une bonne base.

    #55 par sebastien

    24 Sep. 2013 à 11h20

  • Je réveille cet article, que je cite souvent en exemple, car aujourd’hui je tombe sur un tocard qui ne veut pas me fournir de .psd, et me prétend qu’il travaille depuis 20 ans avec des intégrateurs qui acceptent ses .ai…

    s’il lit les commentaires de cet articles, il se reconnaitra.

    #56 par Eric Federici

    11 Fév. 2016 à 11h09

  • @Eric : Salut, je bosse actuellement sur des .AI sur une grosse inté, c’est rare mais ça arrive. Généralement en amont j’essaie de me caler avec le client, s’il préfère bosser sous Illustrator a priori il n’y a pas de contre-indication pour le web (au contraire même, depuis qu’on fait tout en vecto avec SVG et les icon-fonts). Au début ils voulaient me filer des fichiers Sketch, là par contre j’ai râlé parce que ce n’est pas cross-plateform et que je suis sur PC…

    #57 par STPo

    11 Fév. 2016 à 12h00

  • Excellent article, bookmarké.

    Ca m’évitera d’avoir à me répéter ^^

    #58 par Max

    11 Avr. 2016 à 08h56

  • Bonjour,

    Hé bien, j’ai encore l’occasion d’envoyer cet article, cette fois au graphiste d’Agefi, qui me fournit des PSD aplatis et refuse de faire autrement. Une incompétence crasse doublée d’une envie de mal faire les choses, un des 3 pires guignols rencontrés en 20 ans d’intégration…

    #59 par Eric Federici

    26 Mai 2017 à 08h59

J’ai fini par couper les commentaires ici. Si vous voulez me parler, allez sur Twitter !

Haut de page