- Christophe Andrieu, freelance à Paris
- Tél : 07 81 18 24 44
- chris[AT]stpo[DOT]fr
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.
Quelques règles de base et rappels simples pour préparer un document web-safe :
Quelques règles à garder en tête au moment de la phase de création :
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
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.
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…
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 …
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 :
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.
“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 !”
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 !
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
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)
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)
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
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 😀
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)
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… =)
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.
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 🙂
@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 !
«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…
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 😉
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 !
À 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
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 =)
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 :/
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 !
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.
@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 !
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…
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 ?
@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…
@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é 🙂
@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…
@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/
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.
Ça, c’est pour le troll : http://www.reinegger.net/50_reasons_not_to_use_photoshop_for_webdesign.html
(perso, je ne peux juger)
@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
@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 !
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 !
@Colegram : Intéressant ! Je vais y piquer des trucs, notamment le passage sur la césure de paragraphe, que j’avais oublié…
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/
@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.
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.
@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.
Magnifique !
Un énorme merci pour cette superbe ressource.
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…
@PioumPioum : Tu mélanges deux points (lissage et graisse), mais c’est pertinent, je vais rajouter ça !
@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
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.)
@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 !
“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 !
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
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 rapidementIls 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 !
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é…
@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
trolldé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…
Je ne comprendrai jamais pourquoi les web designers utilisent Photoshop et pas Fireworks. 🙁 (hashtag coeur de frontend dev barré)
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…
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.
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.
@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…
Excellent article, bookmarké.
Ca m’évitera d’avoir à me répéter ^^
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…
