Depuis longtemps je me dit qu'un jour je saurai faire une maquette complète d'un design web dans Photoshop. Pourtant, je lance Illustrator à chaque fois, et dès les principes graphique 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 fors intérieur, j'ai toujours trouvé que paufiner une maquette dans les moindres détails dans Photoshop était souvent chronophage : 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étence en graphisme, elle ne dit rien sur votre talent 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 :
- 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.
- 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 !
- 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.
- 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.
- 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.
- 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 outils, 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...
- 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 ergonomique 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 ;)
PS : cet article étant programmé depuis une semaine, il se peut qu'en mon absence du web, certains commentaires passent à la trappe à cause d'un Akismet trop sensible : depuis mon changement de design, j'ai réinstallé totalement la base de donnée, ce qui fait que l'anti-spam semble devoir tout réapprendre...
Que celà ne vous empêche pas de laisser vos impressions et d'excuser mon absence de la zone des commentaires, mais que voulez-vous, avec 40° à l'ombre... :D
A bientôt !
Articles en relation:
- Worth1000 — le paradis pour Photoshop ? Si vous êtes un adepte de Photoshop, venez vous mesurer aux meilleurs sur Worth1000 !...
- Détourer les cheveux avec Photoshop Le web design est aussi fait de photo, et Photoshop est un logiciel fascinant....
- Drawter : dessinez, c’est intégré ! (WYSYWYG Powa!) Drawter est un générateur de code HTML et CSS en ligne qui vous permet de...
- Design de formulaire HTML avec CSS Depuis longtemps, l’intégrateur web pressé d’aller manger, dresse la table pour mettre en forme ses...
- Exercice de style CSS et HTML : table vs div L’utilisation des CSS à la place des tableaux pour concevoir une page web fait sa...
Je te conseille de lire la réponse de Jeff Croft que je trouve très pertinente :
http://jeffcroft.com/blog/2008/jun/04/why-we-dont-skip-photoshop/
Il ne faut pas confondre ergonomie et design, les deux ont leur part de créativité mais elles sont bien distinctes à mon avis et ont chacune leur place dans le processus.
je procède sans photoshop intuitivement depuis pas mal de temps. Je m’en sert uniquement gérer la bannière et le fond par exemple, mais quand il s’agit de police, ou d’emplacement, c’est effectivement bien plus rapide de faire ses tests en HMLT/CSS.
N’ayant pas trop l’habitude de Photoshop (ou plutôt GIMP), j’ai essayé une fois de faire une maquette web avec. Je suis revenu vite fait au papier/crayon. Je définis les zones principales (header, footer, sidebar(s), content par exemple) puis des sous-zones (menu, espace pub, etc…). Je code le HTML d’abord, puis le CSS et enfin je m’occupe de la déco graphique. Et après, j’adapte par petite touche le CSS et (rarement) le HTML. Je trouve que ça fait perdre moins de temps que toutes les opérations que tu as décrit pour un logiciel de graphisme. La visualisation après le changement du code, lui, est presque instantané (hop, je change un width, un color,.…).
J’avais trouvé cet article vraiment nul, voir mon commentaire :P et peu fondé.
Ok, cette étape rallonge la création du site (quoique, au final), mais c’est une étape indispensable pour définir de nombreuses choses et pour obtenir un beau résultat.
Tu pourras surement créer un template de la page en html/css basique sans passer par Photoshop, mais arrivé au moment des détails (découpe des images non peut être ?…) tu seras obligé d’ouvrir Photoshop ^^
Sans vouloir rentrer dans le troll (loin de moi l’idée de traiter l’explication d’une méthode de travail dans un workflow précis de nul, surtout pas celui de 37signals), cette approche est totalement logique pour une société comme celle-là. Ils ont mis sur pied Ruby on Rails dont l’un des principes forts est le fameux DRY.
Hors, faire des croquis papiers, transposer ces croquis dans photoshop et/ou illustrator puis découper le tout et le re-transposer en xhtml/css, à part se répéter, ça ne fait pas grand chose. C’est donc complètement contraire à la philosophie de 37signals. D’ailleurs je pense que les arguments les plus pertinents pour eux (je ne veux pas penser à leur place mais si je transpose les principes de RoR à leur démarche pour le webdesign, c’est ce qui me vient à l’esprit) sont le 5 et le 6 .
@Rémi: ils ne parlent pas de ne pas utiliser du tout photoshop mais de pas l’utiliser pour la maquette, donc ta remarque sur les détails et les images est totalement hors de propos en fait ;)
D’ailleurs la conclusion de l’article original est bien là pour mettre les pendules à l’heure.
J’aime beaucoup la réponse de Jeff Croft qui est tout aussi valable à mon humble avis. Bref, deux approches très différentes qui peuvent très bien trouver leur place dans les workflow de chacun suivant les cas, les cibles, etc. Ce qui est aussi très bien exprimé dans la conclusion de cette réponse.
Point très intéressant. Nous avons commencé dans mon agence par travailler comme tu le préconises : les IT nous fournissaient une application “à blanc” que nous devions habiller directement dans Eclipse. Résultat ? beau code html qui fait plaisir aux développeurs, mais qui fait passer nos capacités en graphisme auprès de nos clients comme insuffisantes.
Ce que l’on fait maintenant : un crayonné rapide (de 1/2 heure à une heure suivant la finesse), validation du client, maquette Fireworks (plus rapide que Photoshop), validation, et intégration html (par un intégrateur html justement, et non pas par un webdesigner, chacun sa spécialité).
Parce que, crois-moi, coder de l’xhtml+css dans Eclipse directement en mode page dynamique et passer de temps à autre dans un éditeur graphique pour les “fioritures”, faut vraiment, mais alors là vraiment être balèze pour arriver à un bon résultat.
En plus, dans un éditeur graphique, tu déplaces un élément, puis un autre, ça va très vite. Tandis qu’en html : “ah flûte, j’ai déplacé mon div de 15 px, donc ça pose un problème de float par rapport au div d’à côté, tiens au fait du coup mon footer est décalé, etc).
Bonjour, Je ne suis pas vraiment séduit par cet article… J’ai l’impression qu’il a été rédigé par une personne pas très à laise avec photoshop et qui melange webdesign et intégration web. pas besoin d’ouvrir photoshop a chaque modif, déplacement, basculement… du site
Je pense que photoshop est très utile pour donner une identité et un caractère… à un site.
quelque points important avec de découper dans photoshop :
1) enlever les calques où vous avez du texte avant de découper 2) ne pas intégrer de texte dans des images (possible avec le css) 3) pas de probleme de police d’écriture (possible avec le css) 4) ne récupérer de la maquette (photoshop)que les données graphiques 5) les couleurs unie seront developpé en css pas besoin de poluer le site avec des tonnes d’images..
bref pour ne pas perdre de temps avec photoshop (comme vous dite) il faut faire les bonnes découpes dans photoshop et ne pas intégrer la totalité de la maquette en images ! !!! lol
si votre site est bien découpé et developpé en css : vous pourrez tout modifier en css (largeur, hauteur, position des modules…)
Thomas
Effectivement, je ne suis pas super convaincu de l’approche «tout HTML» du design Web… Photoshop (et son grand ami Illustrator, qui est, pour moi, mon outil préféré en début de conception — après le papier) permet de mettre la couche visuelle, la couleur, rendre le concept graphique réel.
Et puis, c’est bien beau des CSS, mais ça ne fait pas du découpage d’image ;-)
Dans les faits, je crois que la réponse de Jeffrey Croft résume bien ma pensée. Tout est contextuel. Pour certains projets, ou clients, oui, le passage du papier au code se fait relativement bien, mais lorsqu’il y a un besoin de conception graphique plus poussée, PS (ou tout autre outil de traitement d’image) a sa place.
Finalement, une approche ou l’autre n’est pas le problème. C’est au bon jugement du designer!
Si je suis d’accord sur le fignolage (je dis souvent aux clients que les modifs demandées sont du fignolage justement et que ça prendre moins de temps à faire à l’étape de proto qu’à celle de maquette), je pense qu’il est illusoire de pouvoir se lancer à l’aveugle dans le design sans faire une maquette toshop/illustrator/gimp ou je ne sais quoi.
Ok tu peux avoir un zoning très bien fait qui te permettra de monter le HTML correctement sans avoir le design et peut-être même un début de CSS. Et après ? Tu vas montrer le squelette vide du proto au client ? Tu dois sortir l’artillerie lourde et donc photoshop pour t’atteler au graphisme.
Je crois que ça dépend aussi clairement des sites. Je ne sais pas ce que produit 37signals mais le design de leur site peut se passer de maquette parce que je le trouve graphiquement pauvre bien que travaillé au niveau typographique. Si je vais faire un tour sur coté de http://www.vistaicons.com/ ou http://www.flowersbyalice.com.au/ ou http://www.narfstuff.co.uk/ ça me semble nettement plus difficile.
Il existe un bon compromis entre Photoshop et l’intégration HTML/CSS : le prototypage avec Fireworks. Au lieu de faire du full HTML/CSS, on peut employer certains éléments du prototypage Fireworks pour gagner du temps : exemple pour les barres de navigation.
Mouiais… Je pense qu’il est difficile de se passer de photoshop si on veut faire une maquette riche graphiquement. Comme le dit très bien gou : . Photoshop sert pour le “paraître” : si on veut faire un site qui claque un peu, il faut bien passer du temps à faire de la recherche graphique afin de trouver des éléments qui vont donner sa personnalité au site. Et ça, à mon avis, on ne peut pas le faire autrement que dans photoshop.
Cceci dit, il est vrai que arrivé au stade du alors là, photoshop devient contre productif (et là — digression — je loue feu fireworks qui permettait de faire un rechercher / remplacer des polices ou des couleurs directement dans la maquette graphique)
Depuis quelques mois j’ai adpoté un autre process de production : – je réalisé une ou 2 maquette dans photoshop, – je découpe les éléments graphiques récurrents – et je fais tout le reste de mes templates en html / css.
Et quand on me dit : , là, je prends mon éditeur préféré (texmate pour moi :), je modifie une ligne de ma css et zou, les 15 templates sont impactés par la modification.
Bé moi je ne pourrais pas me passer de Photoshop… ni d’Illustrator d’ailleurs… et Fireworks ?? ;-) Maintenant, je rejoins David, il ne faut pas confondre ergonomie et design. Les petits trucs dans le coin peuvent être importants. Et puis, tout ça ce sont des coups d’épée dans l’eau. Chacun à sa propre méthode de travail et fait comme il l’entend. Si on va jusqu’à rentrer dans Photoshop, tu vas toujours avoir un gus qui fait la même chose que toi, mais différemment. Et bé pour moi ici c’est pareil… sauf que…
…sauf que pour toute une partie du design, comme la création d’images, d’icônes, de fonds d’écran et encore pas mal de choses, tu ne pourras pas te passer de Photoshop…
vivement que Bruno passe dans le coin pour dé-modérer mon dernier commentaire (me demande bien pourquoi il est resté coincé :s) :D
Plusieurs choses : J’ai pu voir en agence des maquettes graphiques superbes faites par des gens qui n’avaient pas vraiment passé des heures à tripatouiller du HTML (des graphistes quoi). Le résultat passait la validation des clients et on se tapait un enfer pour le découpage HTML. Ca m’arrivait déjà en 1999 et après une discussion avec un HTML man qui bosse en agence, c’est toujours le cas.
La présentation des maquettes Photoshop au client, souvent faire sur papier tourne régulièrement à la galère car ils se focalisent alors totalement sur l’image et oublient qu’ils ne font pas le site pour eux. Le pire, c’est quand ce sont les gens de la com qui prennent les décisions. Ils vont passer des heures à critiquer un picto ou une nuance de couleur et passer totalement à côté de l’interactivité et de la satisfaction des attentes de leurs visiteurs. Je pense qu’en présentant des maquettes HTML on irait effectivement plus vite avec eux.
Une agence où j’ai travaillé faisait carrément des maquettes en Flash avec des éléments d’interactivité (menus, etc…), le tout pour des compétitions! Inutile de dire que le site final étant en HTML, il était souvent très différent de la version présentée lors du pitch. Mais c’était vendeur.
Pour ma part, je tente de faire le maximum de travail en amont et je finis en général par faire un storyboard détaillé de chaque template pour voir les emplacements de tous les éléments des pages. Je fais ensuite une maquette sous Photoshop pour les éléments communs et le layout d’une page. Quand je suis satisfait du résultat, je découpe en HTML et je fais souvent des modifs après coup, ce qui fait que le résultat final diffère parfois de la maquette. Et quand je travaille avec un graphiste qui fait la maquette Photoshop, je lui fournit le storyboard en amont et j’échange beaucoup avec lui pour que le montage soit faisable dans de bonnes conditions.
Je suis assez d’accord. J’ai l’habitude de fonctionner comme ça, et de démarrer très rapidement l’intégration. Je ne sais plus qui m’avait assez justement signalé, cependant, que ce n’était pas une façon de faire très appropriée aux gros projets et au travail en équipe.
[…] Zapper la maquette Photoshop, un billet très intéressant de Css 4 Design avec lequel je ne suis absolument pas d’accord puisqu’il a tendance à confondre l’ergonomie et le design qui sont deux choses distinctes bien qu’elles soit indéniablement liées mais à lire. […]
Je pense qu’il y a deux dimensions dans cette question : 1. la question du prototype web : aujourd’hui, malgré son bien fondé (voir l’article d’Ala : http://www.alistapart.com/articles/sketchingincode ) nous (en tant que webdesigner) n’avons pas encore d’outil exploitable à part le produit final. 2. la question de l’architecture de l’information : se servir de la maquette (sous photoshop ou autre) à la fois pour déterminer les éléments de structuration de l’information ET les questions graphiques ne me viendrait plus aujourd’hui à l’esprit. Dissocier les deux phases permet d’utiliser des outils dédiés (comme Omnigraffle pour Mac), mais aussi de faire une séparation stricte entre architecture de l’information et habillage graphique. C’est évidemment très imparfait, notamment pour les interfaces où il y a beaucoup d’interactions (ce n’est pas un hasard si l’article vient de 37signals) mais cela a de grands avantages : permettre d’avoir des maquettes compréhensible du client au développeur (on évite les cahiers des charges que personne ne lit), permettre de faire appel à des compétences dédiées (DA, intégrateur, développeur).
Nicolas »
Concernant la phase d’architecturation de l’information : Tout à fait d’accord avec toi : celle-ci doit se faire en amont de l’utilisation de photoshop. Pour ma part j’utilise un outil très ancien mais qui a su prouver son efficacité : un papier et un crayon. On se réunit à plusieurs, on prend un paperboard et on dessine ce que nous souhaitons voir apparaître sur les différents gabarits de page. C’est plutôt efficace et cela fait gagner pas mal de temps. Il me serait impensable aujourd’hui de faire cette phase là directement dans photoshop.
Malgré cette étape préalable de zoning, je garde toujours une certaine souplesse au cours du processus de réalisation des maquettes car malheureusement, aussi efficace que puisse être l’outil papier, celui-ci ne permet pas de représenter correctement les éléments interactifs dans une maquette (menu déroulant, éléments de formulaires, javascripts…).
Dans le mot Webdesigner, il y a le mot designer non ? L’ergonomie ce n’est pas du design. Le code ce n’est pas de la créativité. Photoshop est la 1ére étape de la création d’un site web. On ne distribue pas une identité visuelle au pif en bossant sa feuille de style.
J’ai fait un cheminement identique. Pour la refonte de mon blog, j’avais déjà les contenus et je voulais seulement les réorganiser (passant de deux à trois colonnes). J’ai d’abord maquetté sur papier avant de tenter dans Photoshop. Devant la complexité de la chose (recouler tout mon texte existant, etc., retrouver les typos), j’ai “designé” en CSS directement avec la Web Developer Toolbar. Photoshop est venu à la fin pour les couleurs et les effets visuels.
Pour commencer, je tiens à présenter mes excuses pour les commentaires qui sont restés bloqués par l’anti-spam. Je tiens aussi à préciser que j’ai écris cet article très rapidement avant de fermer l’ordi il y a 15 jours et je n’ai donc pas pris de recul ni lu la réponse que jeff croft. j’ajouterais pour finir que je ne suis pas forcément d’accord avec tous les points présentés par 37 signals mais que je reste sensible à l’argumentation générale.
Comme je viens de rentrer, j’ai un peu la flemme de répondre point par point à chacun d’entre vous, bien que la richesse des contributions m’y invite… je vais plutôt essayer de répondre globalement. Merci d’avance pour votre indulgence ;)
Difficile de parler de webdesign sans que celà renvoie à nos propres pratiques, à nos habitudes de travail, à notre conception de ce qu’est un bon travail graphique, etc.
Il est évident que pour ce qui est de la “patte graphique”, c’est souvent le client qui choisit en fonction de l’idée qu’il se fait de lui-même, de son projet, de son public, etc. indépendamment des différentes réponses graphiques que différentes agences pourraient proposer : dans les appels d’offres, les dés sont souvent pipés ;)
A partir de là, une multitude d’options est possible : charge graphique très forte avec moult pixels vs design léger qui joue sur les contrastes, les typos, les couleurs, etc.
De ce point de vue, il est illusoire de proposer une méthode de travail, avec ou sans photoshop : l’essentiel n’est pas là, à mon humble avis.
J’ai le sentiment que 37 signals pointe de la souris le fait que la sacro-sainte maquette Photoshop validée par le client qui sert de point de départ à l’intégration web est souvent chargée d’affects qui nuisent plus au projet qu’autre chose… Pas la peine d’avoir un psd de 300 mégas et 50 calques pour découper quelques ko d’images (ok, je me moque un peu…) !
A part ça, je partage les idées de jeff Croft : sans le passage dans Photoshop (ou autre Gimp, etc.) le risque est grand de ne pas avancer graphiquement et de proposer la même grille de mise en page à des clients différents, ça c’est sûr !
D’un autre côté, j’ai remarqué que le passage dans un logiciel graphique est souvent prétexte à des fioritures graphiques qui flattent le produit (quand ce n’est pas le client…) un certain temps, mais qui ne résiste pas à l’épreuve du temps (on change tout ou presque au bout de quelques semaines…)
Bref, pour ma part, j’ai trouvé l’article de 37 signals assez frais et intéressant et j’ai voulu le partager avec vous en ajoutant mon grain de sel ^_^v
Oui à la liberté de créer (côtés clients ou webdesigner), cependant je ne comprends pas qu’on puisse faire le “procès” de Photoshop alors qu’il n’y a pas lieu d’être.
Une maquette “designé” sous Photoshop n’est-elle pas issue d’une réflexion en amont et donc liée aux contraintes HTML/CSS? Même si celle-ci doit subir des refontes de la part du client, ne devrait-elle pas respecter les contraintes techniques du développement?
Cela implique que le Graphiste et encore plus, le Webdesigner doivent connaitre ces impératifs.
Il est vrai que cela peut freiner la créativité de certaines ou certains mais au final, si la réalisation diverge de la maquette, on peut se poser la question de l’utilité de celle-ci. Cependant, il ne fait aucun doute que la maquette offre un appui visuel dans la construction de la page lors du développement : donc indispensable, à mon sens.
Je voudrais rebondir sur l’affirmation de Bibox concernant l’état de non-créativité lié au code. Je ne suis pas tout à fait d’accord : le code intrinsèquement n’a rien de créatif cependant l’assemblage du code dans un “style” judicieux pour amener à un résultat original et inattendu, c’est à cela qu’on peut affirmer que le code: c’est de la créativité.
+1 Bruno, je me retrouve plutôt bien dans ton commentaire (enfin pas sur la partie vacances hein, les miennes commencent seulement demain soir). Et c’était bien ces vacances ?
Dis, rien à voir mais tu pourrais pas changer ton “nom à afficher publiquement” sur ton user WordPress ? Parce que bon, “admin”, ça fait un peu bof bof tu ne trouves pas ? ;)
Pour ma part ce billet est très intéressant et aussi trop rare car il a le mérite d’appuyer là où ça fait mal et ceux sans méchanceté.
En effet je crois qu’un grand nombre de webdesigner serait bien embêté si on enlevait de la circulation le sacro-saint photoshop. “Chronophage” est bien le mot pour designer certaines pratiques entre l’homme et le logiciel. Et si certains dans leurs commentaires prétendre que dans webdesigner il y a “designer” il me semblerait alors bon de rappeler que dans webdesigner il y a aussi et avant tout “web”, sans lui et sans le connaître (oh que le chemin est long) cela ne sert à rien de s’initier au design.
Photoshop et le web c’est une malédiction, des wagons de webdesigner doivent aujourd’hui réapprendre leurs métiers, j’ai même vu des profs former des élèves sur le logiciel et puis “hop” une découpe aux ciseaux, les sites à l’arrivée ne possédés pas de scroll.
En fait, faire une maquette suit une démarche tout à fait classique qui consiste à :
Le problème est que cette méthode a de nombreux inconvénients, dont celui que le client change d’avis en permanence, par exemple. Mais en devenant rigide sur cette manière de faire (signature d’un devis/cahier des charges, validation formelles de chaque étape), on peut faire payer le client facilement le moindre changement, ou du moins négocier chaque modification. Oui, on peut jouer aux cons.
L’avantage est que l’on sait où on va… quitte à aller dans l’erreur.
Depuis quelques années se démocratisent les méthodes de développement dites “agiles”, dont 37 Signals a fait son gagne-pain, pas étonnant alors qu’ils se passent de maquette ! L’idée est de ne pas faire du développement par étapes successives “comme avant”, mais plutôt de faire du développement “itératif”, à savoir que l’on part d’une version basique et que l’on améliore petit bout par petit bout.
J’avoue que si j’ai beaucoup utilisé la méthode classique (avec de très jolis diagrammes de Gantt de 500–600 tâches réparties entre 5 à 15 développeurs sur 6 à 18 mois), j’avoue m’orienter vers des méthodes agiles, désormais, qui permettent une meilleure souplesse au projet, même si du coup, on perd en visibilité à terme. On a cependant l’avantage d’avoir un projet qui tourne assez rapidement, ce qui permet de l’interrompre assez rapidement sans en compromettre les fonctionnalités de base, quitte à ne pas inclure toutes les fonctionnalités secondaires ou se contenter de certains défauts.
@ThVi > Il n’est pas question de faire le procès de Photoshop.
Parfois, mais pas toujours. Ce n’est pas une généralité, mais j’ai constaté que de nombreux webdesigners ont d’abord fait des études en arts graphiques pour travailler là où l’on a besoin de graphistes.
C’est plus tard qu’une partie d’entre eux s’aperçoit qu’il lui manque une formation pour travailler sur le web. (les Arts graphiques sont globalement orientés print même si le web fait peu à peu sa place)
Ces formations n’expliquent généralement pas grand chose des contraintes du XHTML ou des CSS puisque on y apprend souvent à découper un
.psdavec ImageReady…J’exagère un peu, mais ça reflète une grande partie de la réalité.
Je partage tout à fait ton point de vue sur le côté créatif du code ;)
@burningHat > Ca y est, c’est changé. C’est vrai que Admin, ça le faisait pas trop ;)
@Jérôme >
tout à fait, ça rejoint par ailleurs ce que je dis plus haut dans ce commentaire.
@Martin > Je suis assez adepte du développement agile y compris pour présenter une maquette à un client. Par exemple, il est souvent inutile de décliner dans Photoshop la charte graphique de toutes les pages d’un site.
Je me contente de présenter le design global (souvent la page d’accueil) et à moi de décliner au mieux cette charte pour toutes les pages intérieures. Sauf, bien sûr, s’il y a des spécificités fortes sur ces pages, auquel cas, il est nécessaire que le client visualise ce qu’on faire de son projet :)
Mais l’idée est de présenter l’univers graphique que l’on va décliner sur l’ensemble des pages, et non de dessiner chaque page au pixel près et passer des heures à corriger des pétouilles que l’on aura tout le temps de modifier pendant la phase de maintenance chaude, c’est-à-dire pendant les quelques jours qui suivent la mise en ligne du site ;))
Très intéressant ce débat. Il faut dire que les moeurs évoluent et les types de sites également. Franchement, plus j’avance dans mon travail et plus je dissocie le mockup de la première maquette html. Je veux dire par là que je fais mon croquis, je fais une première version html où je positionne mes éléments, je fais ma maquette Photoshop et j’insère ensuite ces mêmes éléments.
La maquette complète Photoshop n’est plus trop parlante pour le client. C’est marrant parce que je le fais pour mes sites mais pas pour ceux d’un client ! :D Photoshop reste essentiel pour ce qui est de créer le design, l’apparence, l’habillage mais n’est pas adapté au web dans le sens que parfois tu fais des trucs fantastiques sur ton mockup et qu’une fois arrivé sur ta page web, tu te dis “merde, c’était peut-être un peu trop recherché mon truc…” :mrgreen:
Finalement, je me tourne vers Fireworks ces derniers temps. Je ne l’ai pas encore vraiment utilisé mais j’ai parcouru la CS4 et ça a un très bon potentiel, justement pour créer des maquettes intéressantes aux yeux d’un client…
@Francis > Je plussoie : je pense aussi qu’un croquis avec le zoning globale de la page et la présentation au client de l’intégration HTML de permet de se concentrer sur l’essentiel : l’emplacement de cette zone est-il optimale, ne devrait-on pas déplacer cette encart ici ou là, etc.
Tous ces ajustements sont presque impossibles à anticiper quand on regarde une maquette Photoshop imprimée, et restent difficile à prévoir quand on regarde cette même maquette à l’écran.
Seule la mise en situation réelle permet au client de se rendre compte, que décidément, il a eu une mauvaise idée en insistant pour placer son menu en bas à gauche de la page ;))
Après, bien sûr, le webdesign (et le graphisme en général) sont des métiers ont on a coutume de dire que chaque client est unique, qu’il lui faut des solutions originales, qu’il faut une identité graphique forte, etc.
Mais bon, j’ai remarqué que lorsqu’on dédramatise tout ça, on finit par garder le meilleur et se débarrasser du superflu.
La communication n’aime pas le brouillage, aussi faible soit-il.
Mais n’oublions pas que bien souvent le client veut un visuel et qu’il faut trouver le meilleur compromis pour lui fournir un truc un minimum fonctionnel mais qui ressemble fort à ce qu’on va lui livrer…
Il faut dire que personnellement, n’étant en rien artiste, je me promène sur le web pour trouver l’inspiration. Cependant, pour une mise en page originale, un papier et un crayon s’imposent, et une maquette sur un outil tel que Photoshop peut aider, effectivement, à donner une impression.
Cependant, j’ai vu des clients qui changeaient d’avis à tout bout de champ, en validant une maquette, puis en réclamant des changements quand elle est implémentée, puis en rajoutant des fonctionnalités sans queue ni tête qui prennent un temps fou à développer, n’avaient jamais été prévus (pas même par le client, ou alors il l’avait bien caché lors des entretiens, validations et j’en passe) et… bref.
Du coup, j’abandonne l’idée de travailler avec des clients humains, leur préférant des robots, avec lesquels je m’entends beaucoup mieux, car ils parlent un langage logique, celui de la rentabilité et de la performance économique plutôt que “et si on ajoutait des menus ? j’aime bien les menus, ce serait bien ! oh, et maintenant, si on faisait des menus horizontaux ? oh, ça ne va pas rentrer ? alors on va réduire les titres ! oh, l’allemand a des mots beaucoup plus longs qu’en anglais ? on va réduire d’autant plus ! on ne pourra pas ajouter autant d’entrées ? ce n’est pas grave, on se limitera !” auxquels j’ai eu droit avec un client particulièrement irrationnel et désorganisé.
Ah, oui, donc, j’oubliais : comme je me base autant que se peut sur mon travail précédent, adapter un design global nouveau est relativement facile (tout est relatif), et il n’est pas utile de tout faire fonctionner d’un coup pour voir les progrès ou retours en arrière. Bref, je m’oriente petit à petit vers du développement agile, d’autant que je suis à la fois mon donneur d’ordre et mon exécutant, ce qui facilite d’autant plus la communication. :-)
@Martin >
Ca aide, c’est sûr. C’est toute la différence avec le travail en agence où la culture d’entreprise parfois ancienne (même lorsque l’entreprise vient de se créer) empêche l’innovation.
Combien de fois, j’ai entendu le discours suivant de la part des commerciaux :
Alors que dans les faits, bien expliquée, la proposition en question serait passée comme une lettre à la poste.
D’ailleurs comme on a eu l’occasion de bosser en free-lance en étant en relation directe avec les clients, on se rend compte que la plupart des commerciaux sont souvent mal formés ; ils connaissent finalement assez peu les produits qu’ils vendent.
C’est pour ça, que très souvent la maquette Photoshop en dur rassure les équipes qui sont chargée de défendre les orientations graphiques ou ergonomiques auprès du client.
Pour ma part, je milite pour une implication des équipes techniques dans l’avant-vente pour désamorcer dès le départ les bombes qui ne manqueront pas d’exploser au plus mauvais moment du projet (Murphy oblige).
Ou alors, il faut que la culture d’entreprise pousse l’ensemble des services à discuter beaucoup autour des projets et de la machine à café. Mais les 35h sont passées par là, et le temps est devenu de l’argent…
Lorsque les budgets le permettent, dans d’autres domaines de l’informatique, certaines entreprises envoient chez le client un technico-commercial, d’une part, qui présente le discours commercial et arrondit les angles face à un client parfois un peu pénible, et un technicien/ingénieur, d’autre part, qui sait répondre aux questions pointues sur le produit vendu, sans discours commercial, mais sans que l’un ou l’autre ne se contredisent l’un l’autre (interdiction absolue). Cependant, pour vendre du site à moins de 10.000 € HT, voire moins de 5.000 € HT, c’est un peu difficile, d’où parfois des difficultés à satisfaire le client, voire même de le convaincre de bosser avec soi.
Je suis d’accord avec toi que la culture d’entreprise, si elle n’est pas assez renouvelée, peut être un frein à l’innovation. D’où l’intérêt, dans cette culture, d’impliquer les cadres et les employés dans cette innovation, que ce soit en les envoyant aux salons, aux conférences, en formation. Mine de rien, on apprend beaucoup sur les attentes des clients lorsqu’on présente les avantages de son produit ou de ses services dans un salon quand des décideurs sans compétence technique posent des questions dont on a pas l’habitude quand on est nourri du matin au soir de jargon spécifique à son métier, voire à son entreprise ou même équipe.
Enfin, j’ai noté que j’étais un très mauvais commercial, car j’éprouvais parfois des difficultés à faire prendre la bonne direction aux clients qui n’avaient pas toujours envie de performance, ce qui m’intéressait (atteindre des objectifs de visibilité, de notoriété, de vente, etc.), mais de se faire plaisir, ce qui les intéressait eux à titre personnel, aux dépends parfois de l’intérêt pour l’entreprise.
Martin, ton dernier paragraphe est très intéressant (le reste aussi d’ailleurs ^^). Pour avoir travaillé dans une grande SSII pendant plusieurs années, et pour y avoir vendu des projets, je peux te dire qu’on se moquait bien des besoins du client tant qu’on pouvait refourguer nos solutions. Parfois, c’était flagrant et je me vois encore dire à mon boss que par rapport à ce que le client voulait, il existait une autre solution bien adaptée. Et lui, ne voyait que tunes, budget et jours de facturation.
Le pire, c’est qu’en suite, on partait en projet et il fallait intégrer la chose qu’on avait vendu !! :mrgreen: Et là, c’était parfois la misère… Et on voyait des petites boîtes équipées avec des softs ou des ERP de folie… Et l’utilisateur sur le terrain, qui lui, n’intervient pas dans le choix du soft, était complètement paumé, dégoûté et parfois il fallait faire de la psychologie pour le réconforter… ^^ Bref, des années inoubliables !! ;-)
[…] un débat très intéressant chez Bruno de css4design sur le process de design des pages web [1]. Bruno lance le débat avec la traduction d’un article de 37signals, une agence web réputée, à l’origine […]
[…] un débat très intéressant chez Bruno de css4design sur le process de design des pages web [1]. Bruno lance le débat avec la traduction d’un article de 37signals, une agence web réputée, à l’origine […]
Oui, je trouve aussi que la réalisation d’une maquette graphique via Photoshop est une perte de temps que l’on pourrait s’épargner. L’idéal serait de réaliser la maquette directement en HTML/CSS, — en faisant bien sûr des aller-retour avec un logiciel graphique pour traiter des éléments purement visuels. Mais ce n’est malheureusement pas la méthode de travail que je connais actuellement, où un document graphique (PSD) est nécessaire, pour valider l’étape, avant l’intégration.