Zoning vs. Wireframes, par Sylvie Daumal

Lorsque j’ai commencé à travailler dans le web, on parlait de zoning quand on évoquait les schémas de pages qui servaient de base au travail des graphistes. Aujourd’hui, les architectes d’information dessinent des wireframes pour formaliser leur travail. Bon, on serait tenté de dire que zoning et wireframes, c’est la même chose sous deux vocables différents, une simple affaire de synonymie. Je pense pour ma part que ce serait une erreur…

Le zoning, contrairement à ce que son nom – qui n’a rien d’anglais, soit dit en passant – pourrait suggérer, a peu de rapport avec la question des zones et des emplacements. C’est même le contraire, puisqu’il était – est toujours, j’imagine – explicitement admis que ce schéma n’a pour seule fonction que d’indiquer les éléments présents dans la page et leur importance relative. Toute liberté était laissée au directeur artistique auquel il était destiné de placer, dans sa création, en haut de page un élément figurant en bas dans le schéma, ou à droite un élément figurant à gauche.

Avec le recul, on ne peut que mesurer l’étrangeté de cette méthode qui faisait peser sur le directeur artistique des décisions d’ergonomie assez éloignées du cœur de métier d’un graphiste. Certes, individuellement, certains pionniers de l’époque parvenaient non seulement à se plier à l’exercice, mais aussi à le réussir, en apportant des changements justifiés et pertinents. Mais était-ce bien là leur rôle ?

De la brochure à l’applicatif

Depuis les années 1990, le web a changé de visage, en s’affranchissant en grande partie d’une conception « brochure-like » pour s’approcher, voire rejoindre, le monde de l’applicatif en permettant à l’utilisateur non plus de lire, mais d’effectuer diverses opérations (écrire, sauvegarder, retoucher des images, commenter des photos, noter des vidéos, etc.). De ce fait, le design des grands sites d’aujourd’hui tend à se rapprocher de celui des outils logiciels. Pourquoi ? Pour quelques raisons simples et évidentes. Aucun utilisateur ne va accepter de lire un mode d’emploi avant de consulter et d’interagir avec un site. On accepte éventuellement de passer du temps à se former sur un logiciel qu’on va utiliser quotidiennement, mais pas pour un site web qu’on utilise occasionnellement, voire rarement. Il est donc impératif, pour garantir la qualité de l’expérience utilisateur, de créer des interfaces intuitives. Oui, mais… qu’est-ce que c’est, une interface intuitive ?

C’est une interface familière (j’emprunte ici les termes de Jenifer Tidwell, cf. Designing Interfaces), donc une interface qui se fonde sur la connaissance préexistante de l’utilisateur et utilise, voire exploite, ses repères. Cette connaissance, c’est évidemment celle des logiciels les plus répandus et les plus utilisés : Word, Excel, Photoshop, pour ne citer que les premiers. Ce faisant, l’ensemble des sites web a fini par établir un certain nombre de conventions, en particulier sur l’emplacement des différents outils, à l’instar et sur le modèle des applications logicielles.

Ainsi, une barre de navigation principale d’un site web trouvera naturellement sa place en haut de l’écran, comme tout logiciel affiche, presque invariablement, une barre grise portant Fichier | Edition | Affichage | etc. La barre d’outils sera en pied, de la même manière. Et, ainsi de suite pour quasiment tous les éléments, la nature de chacun dictant son emplacement.

Les outils se posent à droite

Ce système a été tellement généralisé que la place d’un élément sur un site web est désormais un indicateur de sa nature. Un débat m’a révélé l’ampleur du phénomène. Une question animait courant 2007 la communauté des architectes d’information. Un dispositif de navigation secondaire pouvait-il se placer à droite de l’écran ? Fallait-il le placer à gauche ? Une remarque a émergé lors la discussion, soulignant que trois grands sites actuels (flickr.com, del.icio.us et digg.com) avaient effectivement des éléments de navigation à droite de l’écran, la zone centrale ferrée à gauche étant réservée au contenu.

Pourquoi, dans ces trois cas-là, l’emplacement de droite était-il si efficace, alors que la plupart des sites qui disposent leur barre de navigation secondaire à droite sont plutôt dérangeants ? Je crois que la réponse se situe dans la différence de nature de ces dispositifs : en regardant de plus près flickr.com, del.icio.us et digg.com, on réalise que leurs moyens d’accès au contenu ne sont pas, en réalité, des barres de navigation (i.e. des listes de liens), mais que ce sont des outils. Observez quiconque travailler sur Photoshop, Word, Excel ou OmniGraffle : il placera systématiquement les inspecteurs et les palettes flottantes sur sa droite, plutôt en haut de l’écran. Pourquoi ? Je crois pour ma part que c’est parce que la plupart sont des droitiers et tous les droitiers posent leurs instruments (règles, stylo, etc.) à droite de la feuille sur laquelle ils travaillent. Sur le bureau virtuel de l’application, ils font la même chose, ils posent les outils pour en disposer en épargnant leurs mouvements. On rejoint là des principes d’ergonomie physique.

Cette petite anecdote me ramène à la question des wireframes et l’illustre bien. A la différence d’un zoning, un wireframe définit précisément l’emplacement des éléments dans la page, en fonction de la nature, de l’importance et de la fonction de chacun. Le travail du graphiste ne consiste pas à les déplacer, mais à les habiller graphiquement. Cela fait évidemment porter sur l’architecte d’information la charge de définir le sens de chaque élément du site. Mais ça tombe plutôt bien, puisque la question du sens, c’est le cœur même de l’architecture d’information…

Image issue de l’article Redesigning the ExpressionEngine Site, par Jesse Bennett-Chamberlain.

Cet article a été publié dans une version antérieure sur genius of the AND — vous y trouverez un demi-douzaine d’autres de mes articles.