Ergonomie, Rails et Architecture de l'information web (2.0)

Quel est le plus court chemin transformant la visite hasardeuse en acte d’achat ? Malgré plus de 10 ans de web, la problématique du mode d’accès aux données revient fréquemment dans la conception d’un site ou d’une application web. C’est justement à ce problème que s’attaque Patricia Gallot-Lavallée dans son ouvrage édité à compte d’auteur, et préfacé par Frédéric Cavazza, disponible à partir du 5 septembre prochain.

À travers 60 fiches méthodologiques, le lecteur explore pas moins de 60 modèles de navigation, du plus classique au plus innovant, dans une optique alliant systématiquement ergonomie, accessibilité et référencement.

Chaque fiche est présentée sur une double page, et s’accompagne d’exemples glanés sur le web. Une évaluation visuelle permet de noter le modèle sur 3 points : appréciation globale, coût en termes de temps et de budget (les deux étant le plus souvent liés), et accessibilité. Un paragraphe intitulé “pour qui” décrit succinctement le genre de site auquel se destine le modèle étudé. Un avertissement portant souvent sur l’accessibilité ou un conseil complètent cette première colonne qui permet de se faire une idée rapide de la pertinence du modèle.

Le coeur de la fiche consiste en une série de conseils méthodologiques et de bonnes pratiques visant à une mise en place de qualité du modèle. L’approche est technique, mais accessible, et une explication accompagne chaque point abordé. La démarche donne systématiquement la place la plus importante à l’utilisateur dont la satisfaction complète constitue le coeur véritable du livre.

La fiche se termine sur une étude de cas accompagnée d’une interview mettant en avant les avantages, les inconvénients et les limites du modèle étudié.

Mon avis

Je viens de passer la moitié de la nuit et de la journée à dévorer ce livre que j’attendais depuis plusieurs mois jusqu’à la dernière page, et j’ai vraiment adoré. Le livre explore de nombreux éléments d’une page web faisant partie de la navigation sur lesquels je ne m’étais jamais vraiment penché. L’orientation pratique et les conseils très pertinents permettent de se mettre au travail sans attendre, et les bénéfices sur la navigation sont immédiats. On ne regrettera qu’une seule chose : les fiches sont beaucoup trop courtes, et on aimerait pouvoir en lire plus, la limitation venant de la seule double page allouée aux fiches.

Je recommande cet ouvrage aussi bien aux directeurs artistiques et aux designers qu’aux chefs de projets chargés de la conception ou de la refonte d’un site. Conçu comme un livre de recette, Internet, donne moi ce que je veux est un must have dont la place se trouve sur le bureau de tout architectes de l’information.

[edit]
Afin de répondre à une question plusieurs fois posée, il n’y a pas d’erreur dans l’article, la date de sortie du livre est effectivement prévue pour le 5 septembre. Je fais simplement partie des heureux privilégiés à en avoir eu une édition spéciale pré release (et y’a même pas de dédicace, Patricia, prochaine fois qu’on se voit en soirée, tu n’y coupes pas).

À force de travailler sur des problématique d’utilisabilité sur le web, j’en suis venu à remarquer les initiatives destinées à nous faciliter la vie hors-ligne.

La palme de l’été revient à l’hypermarché Carrefour d’Arcachon, qui a eu l’excellente idée de placer dos à dos les rayons pizza et glaces. Mais surtout, ils ont placé un distributeur de bouteilles de 2 litres de Coca-Cola juste au dessus du congélateur des pizzas. Voilà une excellente initiative qui doit considérablement accélérer les préparatifs de bien des soirées entre geeks, sans nécessairement pousser à la consommation d’un produit qui accompagne de toute façon naturellement une bonne pizza.

Dans son article Reviving Anorexic Web Writing publié sur A List Apart et dont je vous recommande chaudement la lecture en entier, Amber Simmons s’intéresse au pied de page, ce parent pauvre, mal aimé, du design web. Elle y dénoncer le peu d’attention qui leur est accordé avant de terminer sur la qualité de l’expérience utilisateur connue avec le “big footer”.

Les pieds de page sont une insulte au visiteur. La grande majorité d’entre eux est totalement inutile : ils contiennent généralement quelques liens en vrac, parfois des mentions légales, ou des informations de contact, mais rien d’autre. Personne ne les lit jamais pour la simple raison qu’il n’y a rien à y lire.

[…]

Un de mes pieds de pages favori est celui du blog d’Emily Gordon, un vrai pied de page d’écrivain. Il contient des informations vraiment intéressantes. Elle y parle d’elle-même, de ce qu’elle écrit et de ce qu’elle a écrit. Elle s’adresse directement à son lecteur. Quand j’arrive sur son pied de page et que je vois tout ce qu’elle y offre, j’ai le sentiment qu’elle s’attendait à ce que je vienne jusque là, et qu’elle y approuve ma visite. J’adore le fait qu’elle ait choisi de m’offrir bien plus d’informations que je n’imaginais à priori en trouver, à un endroit généralement laissé pour mort. Je me sens récompensée chaque fois que je finis de lire son blog, et je trouve que c’est une merveilleuse expérience utilisateur.

Je suis un grand adepte du “big footer” depuis la première fois que je l’ai vu, à l’époque où je servais de cobaye au thème Hemingway, et j’ai tendance à le placer dès que son utilisation semble s’imposer. Contrairement à ce qu’on pourrait croire, il n’est pas réservé aux seuls blogs, puisque le journal Le Monde l’utilise également.

En termes d’usages, le “big footer” introduit deux choses particulièrement intéressantes.

Comme le fait remarquer Amber Simmons, il redonne ses lettres de noblesse au pied de page, en y introduisant, enfin, des informations utiles. Après la lecture de son article, ou de sa page, l’utilisateur ne tombe plus sur un mur de liens qui ne lui seront d’aucune utilité. Je ne veux pas dire par là que ces liens sont inutiles, au contraire, mais plutôt qu’ils ne sont pas utiles à l’utilisateur, à qui est véritablement destiné le site.

Il permet surtout de regrouper en un seul lieu un nombre important d’informations pertinentes, autrefois placées dans le menu avec les éléments de navigation, tout en n’en faisant pas partie. Dans un monde idéal (sic), on trouverait en effet :

• Sur un layout à 2 colonnes : une colonne pour le contenu, et une colonne pour les éléments de navigation, et uniquement de la navigation. À titre d’exemple, la liste des catégories d’un site fait partie des éléments de navigation, pas les derniers commentaires ou les billets les plus populaires.
• Sur un layout à 3 colonnes : une colonne pour la navigation, une colonne pour le contenu et une colonne pour du contenu contextuel au contenu affiché.

Des variantes de ces deux principes existent bien sûr, et ils ne sont pas exhaustifs, évidemment. Ils permettent cependant de comprendre l’intérêt d’un “big footer”, ainsi que la typologie des éléments qu’on peut y trouver.

Et vous, qu’en pensez-vous ? Pour ou contre le big footer sur les sites qui le justifient ?

À mesure que le haut débit se démocratise et que les machines disposent de suffisamment de RAM pour faire tourner de grosses quantité de Javascript, nombreuses sont les sociétés décidant de migrer qui une partie de leurs applications métier, qui une partie de leurs applications éditées, sur une plate-forme web. Difficile de ne pas être tentés par le Saint Graal des applications instantanément déployées sur des milliers de postes pour les premières, et des applications impossibles à pirater pour les secondes. Encore faut-il faire les choses correctement : bien que le web ne soit finalement qu’un vecteur de transmission et de présentation des informations, les applications web sont très différente des applications de bureau, et le portage ne manque pas de pièges.

L’envie d’écrire un billet sur le sujet me travaille depuis mon expérience sur le projet Optimia / Niveau 1 en 2003. Optimia était l’outil de gestion des dossiers clients d’EDF/GDF. J’avais rejoint l’équipe de développement au moment où ils passaient d’un outil client lourd développé en Power Builder connecté à une base Sybase vers une plate-forme web en J2EE. Toute la difficulté résidait dans une contrainte de 99% d’isométrie ergonomique et fonctionnelle avec la version précédente. Ces contraintes étaient dictées par des impératifs économiques et pratiques – difficile de former des milliers d’utilisateurs en un temps record – et un contexte politique et social hyper tendu avec l’ouverture des marchés de l’énergie à la concurrence dans lequel les changements devaient être limités au maximum. Incidemment, cela coïncidait avec les premières utilisations sérieuses d’AJAX et un regain d’intérêt de ma part pour le web après des années de dédain.

Ce billet tente de mettre l’accent sur des erreurs à éviter et des points clés du portage. Il ne cherche en aucun cas à être exhaustif, bien qu’il ne soit pas exclu que j’aborde un certain nombre d’autres points dans des articles à venir. Les difficultés envisagées sont d’ordre techniques et humaines :

1. La bande passante.
2. Les habitudes des utilisateurs du web.
3. Les habitudes des utilisateurs d’applications desktop.
4. La résistance au changement.

Tout le monde ne dispose pas d’une bande passante illimitée

Bien qu’en France, le haut débit se soit très largement démocratisé, la majorité de la planète utilise encore de vieux modems 56k, et de très nombreuses entreprises utilisent encore en interne des liaisons RNIS 128k.

Afin de permettre à tous de pouvoir utiliser les applications, tâchez de ne rafraîchir que le minimum d’une page tant qu’il ne s’agit pas de valider des informations. L’AJAX est maintenant une technologie éprouvée, disponible par défaut de manière simple dans la plupart des framework web, et son utilisation à bon escient permet d’éviter bien du trafic inutile.

Cependant, afin de rester accessible au plus grand nombre, n’oubliez pas de développer en progressive enhancement, qui veut que l’on développe des applications fonctionnant de la manière la plus simple possible – c’est à dire sur des navigateurs ne disposant pas de Javascript – avant d’ajouter les améliorations clica convi. Les aveugles et les déficients visuels vous en remercieront.

Dans les esprits, une application web doit se comporter comme un site web

Il y a 3 ans maintenant, j’ai été amené à assurer la formation des futurs utilisateurs d’une application utilisant massivement de l’AJAX afin d’utiliser au minimum une liaison RNIS ridicule et par ailleurs déjà saturée. S’agissant du premier portage d’une application desktop sur un environnement de ce type, le retour des testeurs était très important afin d’assurer le portage d’un grand nombre d’autres applications du même genre. Le retour avait été unanime : quand on valide un formulaire et que la page ne se recharge pas, on n’a pas l’impression que les données ont été effectivement transmises au serveur.

Les utilisateurs s’attendent naturellement à ce qu’une application web agisse comme un site web traditionnel. Cela implique particulièrement que tout changement d’état des données manipulées à l’écran doit passer par un rechargement complet de la page, quand bien mêmes les données seraient-elles envoyées en AJAX. Ce point représentait plus qu’une gène pour les utilisateurs qui cliquaient frénétiquement sur leur souris tout en remplissant fiches de bugs sur fiches de bugs, se plaignant qu’aucune des pages ne marchait.

Afin de pallier ce problème, nous avons du provoquer artificiellement le rechargement de la page à chaque validation de formulaire, quand bien même ce rechargement n’entraînait systématiquement aucun changement sur les données manipulées.

Le clic droit n’est pas une fatalité

Une des problématiques auxquelles vous devrez faire face lors du portage d’une application vers le web portera sur l’utilisation du clic droit sur l’application d’origine. En effet, nombreuses sont les applications qui l’utilisent afin de proposer des actions contextuelles qu’il faudra reproduire d’une manière ou d’une autre.

Il est certes possible de récupérer le clic droit en javascript, et de déclencher une action, par exemple l’affichage d’un petit menu déroulant, mais ce n’est clairement pas une bonne idée :

1. Ce n’est absolument pas accessible.
2. Ce n’est pas “web”.
3. Cela supprime des fonctionnalités utiles du navigateur.

Il est donc nécessaire de repenser l’accès aux fonctionnalités contextuelles apportées par le clic droit à l’aune du médium web. Pour cela, plusieurs méthodes existent. La plus simple est encore de créer une barre d’icônes, toujours au même endroit, donnant accès aux fonctionnalités contextuelles généralement offertes par le clic droit. N’oubliez pas de reproduire les raccourcis clavier de l’application originale en récupérant les séquences de touches. Si le portage ne diffère pas trop de l’originale, ses utilisateurs habituels vous remercieront largement de les avoir conservés.

Une refonte ergonomique n’est pas toujours un mal

J’aime à croire que tout n’est pas immuable en ce bas monde, et la conduite du changement est une chose aussi risquée qu’excitante. Tenter un portage à l’identique de l’existant afin de ne pas dépayser l’utilisateur n’est pas toujours une bonne idée. Bien souvent, la refonte ergonomique de l’existant et la formation des utilisateurs vous coûteront moins cher et vous fera perdre moins de temps que de tenter de plaquer un existant sur un média pour lequel il n’est pas fait. Ajoutez-y les économies réalisées par le gain de productivité engendré par l’optimisation des processus au sein de la nouvelle application, et la nécessité d’une réflexion de fond s’impose d’elle-même. Aussi, avant d’exiger une application 100% isométrique à l’existant, penchez vous sur l’équation suivante :

Coût du portage iso - (coût de la refonte ergonomique + communication sur le changement + formation des utilisateurs - économies après la hausse de productivité due à la refonte étalée sur 3 ans)

Si le résultat vous semble largement supérieur à 0, n’hésitez plus : repartez de zéro, ou presque, et à vos utilisateurs une application neuve, mieux adaptée à l’environnement web, plus belle et plus facilement utilisable. Ils vous en remercieront.

Une refonte de processus non plus d’ailleurs

On oublie trop souvent qu’une refonte ergonomique ne se limite pas à inscrire des interfaces à Relooking Extrême. Les applications web, et plus généralement les applications centralisant les données sur une unique plate-forme déportée – serveur de fichiers, serveur de base de données – et non sur le poste client permettent de dématérialiser et d’optimiser de nombreux processus.

Toute la difficulté réside alors dans une très bonne conduite du changement : évangéliser afin de créer une dynamique de groupe qui entraînera l’adoption des nouveaux processus par l’ensemble des acteurs concernés. Mais ceci est une autre histoire.

Google Map ne cesse de me surprendre de jour en jours, aussi bien par sa richesse fonctionnelle que par la rapidité de ses algorithmes qu’une gigantesque ferme de calcul ne suffit pas à expliquer.

Dernière fonctionnalité de malade en date, le “click and drag” proposé sur leur outil de calcul des itinéraires.

Mettons que je veuille me rendre de Lisieux à Hermival les Vaux…

Mais que je m’aperçoive soudain que j’ai oublié d’acheter un pot de beurre au supermarché de Glatigny (et puis la route de Glatigny est bien meilleure pour remonter à Hermival). Il me suffit de cliquer sur un point de la route et de déplacer celui-ci à Glatigny pour que mon itinéraire soit automatiquement recalculé en temps réel.

Cette vidéo est d’ailleurs beaucoup plus parlante que ces captures d’écran.

Au delà de la prouesse technique qui n’est pas sans me rappeler le jeu Click and Play de l’éditeur Maxis (Sim City) en son temps, je me demande si, malgré son extrême simplicité – je clique, je déplace et ça marche – ce genre d’interface super intuitive est aujourd’hui réellement à la portée d’utilisateurs grand public habitués à des outils beaucoup plus austères, complexes et directifs.
Aujourd’hui, l’ensemble des applications de calcul d’itinéraires existantes nécessitent un nombre important d’étapes bien délimitées : adresse, code postal, ville, pays de départ, d’arrivée et pour chaque étape. Ces dernières sont à préciser en amont de la recherche, et ne peuvent pas être changées sans effectuer une nouvelle recherche, là où Google Map demande simplement une ligne de départ, une d’arrivée, et suggère des alternatives quand il ne trouve pas directement ce qu’il cherche.

Comme rien ne vaut les retours d’expériences, je viens de faire essayer le service de calculs d’itinéraires de Google à une habituée de Mappy. Elle devait se rendre de Rouffiac (17) à Saint Sauveur d’Aunis (17) en passant par Parançay (17). Sa première réaction fut : “c’est nul, on ne peut pas indiquer par où on veut passer”.

Le changement d’usages est là évident : à une habitude consistant à indiquer par où l’on souhaite transiter en amont de la recherche vient se substituer le calcul d’un itinéraire idéal (se prendre les embouteillages à Tonnay-Charente n’est clairement pas ce que j’appelle un itinéraire idéal) que l’utilisateur peut altérer de manière visuelle, simple et avec le calcul du nouvel itinéraire en temps réel, en fonction de ses goûts ou de ses besoins. Sauf qu’aujourd’hui, l’utilisateur ne le sait pas encore, et qu’il n’est pas forcément prêt à une telle mutation.

Et vous, qu’en pensez-vous ? Croyez-vous que ces nouveaux usages pourront facilement convertir une masse d’utilisateurs non geeks, ou sont-ils destinés pour un temps au moins à une communauté d’early adopters ?

Via Ogle Earth et Nicolas

Durant les 7 jours précédant la mise en ligne de ce nouveau thème – qui ne passe toujours pas sous Internet Explorer 6 par flemme de ma part – Feedburner m’annonçait un nombre moyen de 541 abonnés à mon flux RSS. Trois semaines jours après l’arrivée de ce gros bouton orange, le nombre moyen d’abonnés sur les 7 derniers jours est passé à 679, soit une progression en valeur absolue de 25% en 20 jours.

Il me reste maintenant à travailler sur mon référencement. J’ai déjà commencé en changeant la structure du contenu et en rapatriant le site en France (merci Otto pour les conseil, si tu en as d’autres, je prends), mais il me reste encore pas mal de travail de ce côté là.

À titre de comparaison, cela représente ma progression totale entre le 15 février et le 5 mai 2007.

Bien que la loi oblige les fabricants à traduire les notices de traduction en 8 à 11 langues différentes, selon le type de produit, on peut légitimement se demander à quoi elles servent tant les utilisateurs les ignorent royalement. On fera cependant une exception pour les notices de montage des meubles de la marque suédoise Ikéa, dont la simplicité est connue dans le monde entier. Il n’en est semble-t-il pas de même avec l’informatique, comme le montre cette tranche d’histoire de l’Internet français dans laquelle on voit un opérateur se battre pour faire comprendre le bon fonctionnement de ses équipements à des clients pourtant supposés technophiles.

Au milieu des années 90, lorsque apparurent les tous premiers modem ADSL USB, la notice d’utilisation de ces derniers spécifiait en toutes lettres que l’installation des outils fournis sur un CDROM était le préalable obligatoire au branchement du modem. Dans le cas contraire, une corruption de la base de registre Windows invitait le contrevenant à réinstaller son poste, avec la perte des données qui résultait.

Après une période de plusieurs mois durant lesquels son service d’assistance technique croulait sous les appels de clients enragés – et on les comprend – un opérateur de l’époque décida de pallier au problème. Dans ce but, il ajouta sur le dessus du carton contenant le kit de connexion un papier sur lequel était écrit en rouge sur fond blanc : “installez les outils présents sur le CDROM avant de brancher le modem”. Le nombre d’appels pour cause de réinstallation forcée diminua d’environ 5%, ce qui est bien, mais pas top.

Afin de faire passer l’information, il fut décidé de placer un autocollant affichant le message d’avertissement en blanc sur fond rouge sur le corps même du modem USB. Il fallait forcer les utilisateurs à prendre connaissance du message au moment du déballage de l’engin. Peine perdu, le nombre d’appels quotidien chuta à nouveau de 5%.

Puisque la notice, la partie supérieure de l’emballage et le modem ne suffisaient pas, il fallait aller au devant des utilisateurs les plus bornés. L’opérateur fit donc appel au bon sens de sa R&D, qui, une fois n’est pas coutume, n’en manquait pas. Il fut donc décidé de mettre un cache sur les prises USB du modem, scellé par l’autocollant sus-cité, pour voir enfin les utilisateurs prendre connaissance des consignes d’utilisation. La quatrième tentative fut la bonne, et les appels à la hotline pour ce motif diminuèrent de plus de 80%.

En guise de conclusion, je rappellerai deux points fondamentaux pour tout concepteur de site web – et concepteur tout court d’ailleurs :

1. N’imaginez pas un seul instant que votre application puisse être un jour utilisée de la manière dont vous l’avez conçue.
2. Si vous devez placer un garde-fou quelque-part, faites le toujours le plus tard possible, et de la manière la plus bloquante possible.

Sur ce, je vous souhaite une bonne nuit. Si vous êtes sages, demain, nous parlerons des manières de concevoir une application web idiotproof.

Intéressante discussion la semaine dernière avec le responsable du service clientèle d’un fournisseur de télécommunications sur l’emploi fait par les utilisateurs des formulaires web de demande d’aide à la hotline.

En substance, il s’avère que, concernant les menus déroulants servant à qualifier les problèmes rencontrés par ses clients, cet opérateur m’a fourni les chiffres suivants :

• 90% choisissent la première option, quelle qu’elle soit.
• 5% choisissent l’option autres si elle est présente.
• 5% choisissent une option plus ou moins en rapport avec leur problème.

Cette constatation introduit deux problèmes évidents :

Les problèmes étant répartis entre les différentes équipes en fonction de leur typologie, un travail de requalification de l’affaire doit être effectué systématiquement avant traitement, avec une retransmission à l’équipe concernée. Outre l’allongement des délais de traitement, cela implique aussi une charge de travail supplémentaire, qui passe par l’analyse de diatribes rédigées dans un français généralement douteux par Madame Michu, dont je vous reparlerai très bientôt.

Vus ces chiffres, quel crédit accorder aux données émises via un menu déroulant, et par extension, par toute zone de formulaire à choix multiples ? Dès lors, on doit classer ces données en trois catégories :

• Celles qui impliquent une dépense ou un investissement du client, par exemple la durée d’un abonnement. On peut raisonnablement tabler sur la fiabilité d’une telle donnée puisqu’elle implique une variation du paiement à l’arrivée.
• Celles qui sont absolument indispensables au traitement du formulaire et qu’une intervention humaine ne peut permettre de recouper à partir d’autres renseignements.
• Les données purement statistiques.

Quant à notre opérateur, afin de mieux répartir le travail entre les équipes chargées des différentes typologies de problèmes, il a tout simplement décidé de générer ses menus déroulants dans un ordre aléatoire.

Ensemble d’éléments me permettant de savoir d’un coup d’oeil où je me trouve, où je suis allé, où je peux aller et comment m’y rendre, la navigation est une composante majeure d’un site web qu’il ne faut en aucun cas négliger. D’une navigation adéquate dépendent aussi bien la fidélisation de vos visiteurs que la transformation d’une visite en vente. Car ne vous y trompez pas, qu’il s’agisse d’un billet sur votre blog, du remplissage d’un formulaire de contact par un futur prospect ou d’un troupeau de zébus malgaches, si vous exposez sur le web, c’est que vous avez forcément quelque-chose à vendre.

Quelques principes simples

Comme vous l’avez vu plus haut, la navigation est :

Un ensemble d’éléments : la navigation ne se compose pas uniquement du menu, mais de tous les éléments permettant de… naviguer et de se retrouver sur le site. Nous reverrons cela en détails plus loin, mais on peut citer des éléments aussi divers que :

• Le menu.
• Le chemin de fer.
• Les liens d’évitement.
• Les titres de parties et sous parties dans un texte.
• Les éléments contextuels.
• Le pied de page.
• Le plan du site (bien qu’on ne puisse pas vraiment parler de navigation à proprement parler).
• Le titre de la page.

Me permettant de savoir où je me trouve : idéalement, l’arrivée sur une page d’un site devrait immédiatement me permettre de savoir où je me trouve, sans rien connaître du site, et surtout sans jamais avoir à réfléchir. Idéalement, si je me suis profondément enfoncé dans l’arborescence du site, je dois également pouvoir en visualiser les différentes étapes.

Me permettant de savoir où je suis allé : lorsque je tombe sur des éléments de navigation, je dois pouvoir reconnaître d’un seul coup d’oeil si je m’y suis déjà rendu ou non, et évidemment sans réfléchir. Pratiquement, cela passe le plus souvent par de la mise en forme. On pourra choisir de modifier la couleur de la police de caractères, traditionnellement en la rendant plus foncée. Pour des raisons d’accessibilité, il n’est cependant pas recommandé de supprimer le soulignement des liens afin de toujours les reconnaître pour ce qu’ils sont. En fonction de la typologie du site, on pourra également afficher la liste des derniers produits visualisés ou des derniers billets lus dans un encart contextuel.

Me permettant de savoir où je peux aller : l’ensemble des grandes rubriques du site doivent être clairement affichées, et cela passe notamment par :

• Montrer de manière explicite qu’il s’agit d’un élément de navigation. En 1996, le menu de mon premier site web arborait crânement la mention “menu”. Quelques semaines plus tard, je me rendais compte à quel point c’était évident, et j’éliminais la mention menu au profit d’indications quant aux rubriques : Cyberpunk, Jeux de Rôles, Roller, Contact.
• Séparer clairement la navigation du contenu.
• Utiliser une nomenclature claire, unifiée et adéquate. Des deux listes suivantes, l’une est bien, l’autre moins :
  • Écrire, Gestion, Discussion, Personnaliser, Configuration.
  • Écrire, Gérer, Discuter, Personnaliser, Configurer.

Les niveaux de navigation

On distingue deux niveaux de navigation : la navigation globale et la navigation contextuelle.

Navigation globale

La navigation globale est présente sur l’ensemble du site. Elle ne change pas quel que soit la page du site sur laquelle l’utilisateur se trouve, qu’il soit authentifié ou non.

En ce qui concerne ce dernier point, j’avais la semaine dernière le cas de la conception d’un site dont la partie “espace authentifié” devait être particulièrement mise en avant, et notamment apparaître dans la navigation global. Afin de résoudre ce point, nous avons placé le formulaire d’inscription et d’authentification derrière l’onglet “mon espace personnel” quand l’utilisateur n’est pas authentifié. Cela nous a permis de libérer de l’espace dans la têtière en n’ajoutant pas de lien “identification” / “inscription”

On trouvera habituellement la navigation dite “globale” sur la têtière, à gauche, ou à droite, et sur le pied de page qui regroupe généralement l’ensemble des liens utilitaires :

• Mentions légales.
• Licence sous laquelle est publiée le contenu.
• Contact.
• Plan du site.

Navigation contextuelle

On voit souvent la confusion entre navigation contextuelle et contenus contextuels, l’un et l’autre étant relativement semblables.

La navigation contextuelle, comme son nom l’indique, se compose d’éléments de navigation contextuels à la partie du site visitée. Le contenu contextuel, lui, est un ensemble de contenus en rapport avec le contenu affiché.

Dans le contenu contextuel, on trouvera notamment :

• Articles de la même famille que celui visité.
• Articles achetés par les visiteurs ayant acheté l’article en cours de consultation.
• Articles complémentaires de l’article consulté (des chaussettes si je regarde une paire de bottes en caoutchouc…).
• …

Nomenclature

La nomenclature, aussi appelée wording est fondamentale en termes de navigation. Elle est d’autant plus délicate à mettre en place que celui qui la choisit est généralement profondément immergée dans le site. Ce qui lui semblera limpide comme de l’eau de roche pourra sembler parfaitement obscure pour le visiteur. Une fois le problème de clarté des libellés bien compris, reste le problème de l’efficacité. La navigation doit en effet inciter le visiteur à acheter cliquer, et pour cela, une seule solution : lui donner envie. Autre point à prendre en compte, les codes et standards généralement admis sur le web. Ces codes peuvent être aussi bien écrits que visuels (oui, je sais, on parle de nomenclature). Si ces codes peuvent sembler clairs pour les spécialistes, il n’en est pas forcément de même pour le grand public.

Exemple :

1. Syndiquer ce site.
2. 
3. Fil RSS.

Ces trois libellés veulent dire exactement la même chose, mais ne seront pas perçus du tout de la même manière par un non spécialiste :

1. Syndicat ? Syndicat ? Qu’est-ce que ça vient faire là, j’ai déjà ma carte à la CGT moi.
2. …
3. Fil RSS, j’ai lu ça dans le dernier Vieille et Moche, ça sert à suivre un blog sans avoir à revenir dessus tous les jours.

Ce site étant destiné à des spécialistes, le choix d’une icône colorée et mise en valeur, reconnue par les gens du sérail, s’imposait d’elle-même.

Pour résumer, le nomenclature de la navigation doit être :

• Très claire : je dois comprendre où je me trouve, et où je peux aller.
• Incitative : je dois avoir envie de cliquer.
• Adaptée aux us et coutumes du public auquel mon site est destiné.

Typologie des sites étudiés

Bien qu’il existe un très grand nombre de sites différents, nous étudierons dans la seconde partie de cet article des mode de navigations en rapport avec 5 typologies de site qui m’ont semblé les plus pertinents :

1. Le site portail institutionnel.
2. Le site marchand.
3. Le site marketing produit.
4. Le blog.
5. L’application web.

À suivre…

À l’occasion de la refonte de son blog, David se pose 16 questions sur la manière d’agencer son site afin d’offrir à ses visiteurs une ergonomie optimale. Ses interrogations pouvant s’appliquer à n’importe quel site, j’ai décidé d’y consacrer un billet, plutôt que répondre dans les commentaires comme il invite ses visiteurs à le faire.

Découverte d’un blog

1. Quelle est la porte d’entrée d’un nouveau blog ? Arrivez-vous le plus souvent sur la page d’accueil ou via un lien direct/une recherche ou autre ?

J’arrive généralement sur un nouveau blog via un médium externe : billet sur un blog déjà lu, ou résultat de recherche. J’arrive donc très rarement sur la page d’accueil. Cependant, quel que soit mon point de chute, je m’attends à y voir un certain nombre d’éléments bien précis (que l’on retrouve – oh surprise – sur celui-ci) :

• Un titre.
• Un descriptif de ce dont traite le blog (autrement appelé tagline).
• Un ou plusieurs billets.
• L’endroit où je me trouve (un chemin de fer est parfois un plus, mais pas toujours adapté).
• Une navigation générale simple et concise, comprenant un lien vers le flux RSS visible et standard.
• Une navigation thématique claire, complète et très facilement accessible (typiquement en première position de la sidebar).

2. Quelle est la page suivante, celle que vous visitez juste après avoir lu celle que vous venez de découvrir ? Les liens généralement fournis sont-ils adaptés ?

Je ne lis généralement pas d’autre page que celle sur laquelle je suis tombé, puisque mon arrivée sur ce blog répond à un besoin précis. Je peux cependant faire une entorse à la règle si la page visitée réunit des conditions précises :

• Que tous les titres des billets soient parfaitement pertinents.
• Que les billets disposent de liens “précédent” et “suivant” affichés en haut de page et affichant le titre des articles vers lesquels ils pointent.
• Ou, mieux, que sous chaque billet se trouve un encadré comprenant un ou plusieurs liens pointant vers des billets connexes.

3. Lorsque vous découvrez un blog intéressant, quel est votre type d’exploration ? Via les tags, les favoris, les archives ?

Quand je ne passe pas par les média explicités ci-dessus, j’utilise généralement la navigation thématique large, autrement appelée catégories, à moins que je ne cherche que des billets traitant d’un sujet vraiment particulier pouvant se définir par un simple mot clé.

Souscription à son flux RSS

4. Quel est le facteur déclenchant la souscription ? Quels sont vos critères de sélection ?

Le premier facteur, c’est la visibilité du flux RSS. Le bouton RSS fait partie des premières choses que je m’attends à voir sur un blog, avec le titre et la tagline. Si je dois me demander où chercher la souscription ne serait-ce qu’une seconde, je n’irai pas plus loin.

Il faut ensuite que le contenu soit vraiment intéressant pour que je rajoute un flux aux quelques centaines qui encombrent déjà mon agrégateur, et là aussi, cela implique des critères tout à fait subjectifs :

• Si c’est un blog personnel, il faut impérativement que je connaisse la personne au moins en ligne.
• Il faut qu’il soit en bon français.
• S’il s’agit d’un blog professionnel ou technique, il faut que sa ligne éditoriale aille dans le sens de mes centres d’intérêt (elle doit donc être clairement définie, notamment à travers la navigation thématique simplifiées).
• Les contenus doivent être pertinents, de qualité, et ne pas être de simple relais des billets à la mode sur les autres blogs. J’ai les favoris populaires de Delicious pour ça.

5. Vous abonnez-vous au flux général ou à une sous-partie (lorsque c’est possible) ?

Le flux général, toujours, mais je ne lis que ce qui m’intéresse (d’où l’utilité de donner des titres pertinents à ses billets).

6. Qu’est ce qui vous pousse à supprimer un fil RSS de votre agrégateur ?

Cette question rejoint celle du facteur déclencheur de la souscription, mais dans le sens inverse :

• Perte de la qualité rédactionnelle.
• Perte durable d’intérêt des billets.
• Transformation du blog en relais de Digg.

Recherche d’un billet particulier

7. Passez-vous par une recherche externe ? interne ?

Arrivant le plus souvent sur un blog par un moteur de recherche, je passe assez peu par la recherche interne. Je m’attends cependant à en trouver une accessible immédiatement à un endroit pertinent : à droite de l’en-tête, ou bien placée dans la sidebar. Il faudra d’ailleurs que je la remette ici quand j’aurai refait la CSS des résultats.

8. Utilisez-vous les archives d’un blog ?

Je n’utilise pas les archives temporelles, qui ne valent finalement que dans le cadre du diarisme (journal intime pas intime). J’utilise en revanche beaucoup les catégories, qui sont une méthode d’archivage thématique.

9. Pour vous rappeler d’un billet, le titre est-il primordial ? Faut-il qu’il soit choquant/spécial ?

Pourquoi me rappeler le titre d’un billet si je sais de quoi il parle et que je dispose d’une recherche locale ? En revanche, utilisant un agrégateur RSS particulièrement peuplé, je m’attends à ce que les titres soient pertinents, sinon je ne lis pas le contenu.

Contenu et disposition

10. Préférez-vous le classique deux colonnes ou le nouveau big footer pour tout ce qui est « annexe » (liens, archives, derniers *, etc) ? ou autre (par exemple ici c’est un peu hybride) ?

Je préfère une solution hybride qui me permette de :

• Embrasser d’un seul coup d’oeil navigation thématique et contenu du billet sur lequel j’arrive.
• Affiche le reste des éléments de navigation à part, de manière bien détachée, claire, et surtout sans interférer avec le contenu, donc de préférence en dessous.

11. Un bon billet de blog, c’est le point de départ vers de nombreuses pages intéressantes à lire ou une impasse car vous n’avez bien souvent pas le temps de lire d’autres ressources ?

Un bon billet de blog, c’est généralement un aller simple dans mes bookmarks Delicious, avec très peu de chances pour que je lise autre chose, à moins que les options de navigation décrites plus haut ne me soient offertes.

12. Quelle importance accordez-vous à la régularité de publication d’un blog ?

La généralisation des agrégateurs RSS a profondément changé notre mode de consultation d’un contenu web : d’actifs – nous allions vers l’information – nous sommes devenus passifs – l’information vient à nous. Dès lors, la fréquence de publication n’a plus grand intérêt : nous ne nous lassons plus à force de nous heurter quotidiennement à un mur de non nouveauté tous les matins à l’heure du petit déjeuner.

Commentaires

13. Souhaitez-vous être tenu au courant des réponses à votre commentaire ? Si oui, comment ?

Il existe deux manières de se tenir au courant des réponses à un commentaire :

• Par courrier électronique.
• Par un flux RSS associé à la discussion.

Pour moi, le premier médium n’est pas envisageable. La plupart des gens ne ferment pas leurs commentaires au bout d’une durée déterminée, et recevoir des mails à propos d’une discussion vieille de deux ans, totalement dépassée et sortie de son contexte est relativement fatiguant.

Le flux RSS, au contraire, me semble présenter des avantages indéniables. Il évite de sortir de l’agrégateur (pour rejoindre le client mail), il se fait oublier tant qu’il n’y a plus de réponse, et il ne vient pas polluer ma boite à lettres.

14. Préférez-vous que la réponse soit incluse à votre propre commentaire ou dans un commentaire suivant ?

Un commentaire suivant.

15. Quelle importance accordez-vous à la qualité de vos commentaires ?

Idéalement, tout blog modérerait les commentaires à priori. Bien que plus contraignante pour l’auteur, cette solution présenterait au moins un avantage : prévenus des risques de modération, les commentateurs ne publieraient que des commentaires pertinents, et éviteraient les missives du genre “ouah, j’adore ce que tu fais, kikooolol”.

16. Avez-vous déjà hésité à répondre après avoir identifié les liens sortants en « nofollow » ?

J’ai une double position vis à vis des liens sortants en « nofollow » :

• Dans les commentaires, ils ne posent pas de problèmes, car ils ne risquent pas d’empêcher les moteurs de recherche de perdre le fil de la discussion.
• Dans les pingbacks ou trackbacks, il me semble qu’ils arrêtent la discussion, au moins virtuellement.

Ma réponse à la question sera “non”, car je ne fais pas attention à la politique du blog avant de poster un commentaire, et je ne le fais pas pour profiter du pagerank de l’auteur du billet mais parce que j’ai quelque chose à dire.

Remarque :

En rédigeant ce billet, je me suis rendu compte que de nombreuses réponses aux questions de David étaient redondantes, et je vous prie de m’en excuser.

Cela révèle un premier problème : en rédigeant son questionnaire, David a pensé de manière thématique, en mettant en avant les éléments que l’on s’attend à trouver sur un blog, et non transverse en isolant les problèmes posés. J’ai songé un moment à reformuler mes réponses afin de supprimer l’ensemble des répétitions, mais cela impliquait de ne plus suivre le jeu des questions réponses (un peu comme, en milieu de troisième, le jour où j’ai regroupé les questions posées autour d’un texte en trois thématiques et rédigé mon premier commentaire composé un an trop tôt au lieu de répondre bêtement comme on me l’avait demandé).

Mon conseil à David serait donc : lorsque tu t’occuperas de ta refonte effective, essaie de réfléchir de manière transverse de manière à ne pas imposer d’éléments redondants à ton visiteur afin de lui offrir un parcours agréable sur un blog par ailleurs de qualité.

[edit]

David a mis en ligne l’ensemble des réponses et un résumé de celles-ci sur son blog.