Zapper la maquette Photoshop et passer directement à l’intégration HTML/CSS ?

Depuis longtemps, je me dis qu’un jour je saurai faire la maquette complète d’un design web dans Photoshop. Pourtant, je lance Illustrator à chaque fois, et dès les principes graphiques en place, je lance mon éditeur web préféré (en ce moment, c’est Aptana Studio) pour commencer l’intégration tout de go ! Dans mon for intérieur, j’ai toujours trouvé que peaufiner une maquette dans les moindres détails dans Photoshop était souvent plus chronophage qu’efficace. On se focalise sur les détails graphiques (le bidule, un peu plus à droite, c’est possible ?) au lieu de privilégier la bonne distribution des informations dans l’espace.

Et puis, en lançant mon aggrégateur, je suis tombé sur ce billet de Gou où il est question d’un article de 37 signals qui envisage de se passer de la traditionnelle maquette sous Photoshop pour se coltiner directement avec le code. Si Gou n’est pas vraiment convaincu par cette approche, je suis pour ma part rassuré sur ma façon de voir les choses 🙂 En effet, si la maquette Photoshop (ou Illustrator) rassure le client sur vos compétences en graphisme, elle ne dit rien sur vos talents de webdesigner, c’est-à-dire d’organisateur d’espace sur le web en vue de favoriser le clic et la navigation !

Pour vous faire une opinion sur cette question, voici une « craduction » rapide des arguments avancés par 37 signals :

Pourquoi nous zappons Photoshop

Voici quelques raisons qui expliquent pourquoi nous devrions nous passer de Photoshop :

1. On ne peut pas cliquer sur une maquette. C’est probablement la première raison qui fait que nous avons abandonné les maquettes statiques. Elles ne sont pas réelles. Le papier ne l’est pas plus, mais il ne provoque pas les mêmes attentes. La présentation à l’écran d’une maquette réalisée sous Photoshop devrait fonctionner. Mais vous ne pouvez pas faire défiler les menus déroulants, ni saisir du texte dans un champs dessiné. Vous ne pouvez pas non plus cliquer sur un lien. A l’inverse, un prototype HTML/CSS est une vraie expérience.
2. Photoshop fournit trop d’outils qui nous scotchent sur les détails. Lorsqu’on utilise Photoshop, on ne peut pas s’empêcher d’accorder de l’attention aux alignements, aux couleurs, aux formes, etc. Tout ces petits détails qui auront certainement leur importance… mais plus tard. L’essentiel est invisible pour Photoshop !
3. Dans Photoshop, le texte n’est pas le même que sur le web. Quand on regarde une maquette réalisée sous Photoshop, on ne peut pas modifier le texte sans retourner dans le logiciel pour changer le texte, enregistrer le fichier, l’exporter au format gif/png/jpg, etc. On ne peut pas le mettre en ligne et demander à quelqu’un de recharger la page dans cinq secondes comme il est possible de le faire en éditant rapidement un fichier HTML. On doit dire : Donnez-moi quelques minutes… Par ailleurs, les polices de caractères n’ont jamais le même aspect ni la même taille qu’en HTML. Ce n’est pas la même expérience.
4. Photoshop met l’accent sur la production, pas sur la productivité. Photoshop sert à construire quelque chose qui doit « paraitre », pas quelque chose qu’on peut utiliser. Lorsqu’on s’inquiète seulement de l’apparence des choses, on passe trop de temps en « fignolage ». HTML/CSS permet d’être productif en permettant d’aller de l’avant après chaque modification.
5. On refait souvent les mêmes choses dans Photoshop. D’accord, vous avez passé trois jours sur une maquette. Et après ? Maintenant, il faut tout transformer en HTML/CSS. C’est du temps perdu. On peut prendre ce temps pour faire l’intégration HTML/CSS et passer plutôt du temps à l’améliorer, au lieu de tout construire/déconstruire. Si l’on est pas assez rapide en HTML/CSS, on peut passer plus de temps à apprendre à travailler plus vite.
6. Photoshop n’est pas un logiciel très collaboratif. J’ai déjà touché du doigt cet aspect plus haut, mais laissez-moi enfoncer le clou : HTML/CSS vous permet de faire des changements, d’enregistrer et de voir le résultat. C’est le flux de collaboration que nous avons mis en place : laissez-moi changer ça, ça y est, faites F5 ! Ces changements prennent quelques secondes. Attendez, je vais placer cet élément à gauche plutôt qu’à droite. F5 ! Toujours quelques secondes. Pas besoin de sélectionner un outil, de modifier quelques éléments manuellement, d’enregistrer, d’exporter, de télécharger, de donner au client le nouveau nom de fichier, etc. HTML/CSS est idéal pour faire des prototypes itératifs ; ce n’est pas le cas de Photoshop…
7. Phostoshop est lourdingue. Même après 10 ans de pratique intensive de ce logiciel, je trouve toujours que l’utilisation d’un crayon et du papier est plus naturelle que de faire des aller-retours dans la barre d’outils. Un crayon peut dessiner n’importe quoi, tandis que dans Photoshop, vous devez utiliser l’outil texte pour saisir du texte, l’outil forme pour dessiner une forme, la barre d’option pour ajuster tout ça, etc.

Rien de tout ce qui précède n’est là pour dénigrer Photoshop, mais nous avons trouvé que plonger les mains dans le code HTML et CSS apporte une meilleure expérience créative. La voie du code est vraie comme Photoshop ne le sera jamais.

Quelques mots pour finir

Bon, j’espère que cette « craduction » ne comporte pas trop d’erreurs d’interprétation… J’imagine que beaucoup trouveront cette prise de position un peu extrême et se demanderont ce que l’on peut bien intégrer en HTML/CSS si on a pas fait de maquette avant…

En gros, on peut très bien dessiner une maquette sur le papier en commençant par le zoning global et en donnant des indications graphiques plus ou moins précises en fonction de la nature de la commande. Par exemple, dans la plupart des cas, il n’est pas nécessaire que la maquette soit exacte au pixel près, tant que le résultat final tient compte des détails.

L’avantage ? Selon, les méthodes de travail il sera ainsi possible de lancer Illustrator (ou de prendre son crayon) pour « dessiner » quelque chose sans se préoccuper de la largeur de la page ou de l’espace entre les colonnes. Ces éléments pourront trouver une réponse plus tard.

Je suis convaincu que même pour pour des projets ayant une charge graphique forte, il est possible de proposer l’univers graphique d’un côté pour s’assurer que la cible est prise en compte, et le prototype fonctionnel de l’autre pour valider les grands principes ergonomiques et « navigationnels ». Sachant que le premier influe sur le second et vice-versa ! Tiens, j’ai bien envie de relire Transcender CSS sous cet angle.