Un article sur la trouvabilité

Le magazine en ligne e-Contetn Mag nous propose aujourd’hui un article sur la trouvabilité : It’s Not Just About Searching – It’s About Findability. L’auteur de cet article dénonce les lacunes de certains sites et intranets qui se « contentent » d’implémenter un moteur de recherche sans pour autant s’assurer de la qualité du service rendu. L’auteur insiste bien sur la notion de pertinence : qu’il y ai un moteur de recherche, soit, mais est-ce qu’il aide vraiment les utilisateurs à trouver ce qu’ils cherchent ? En voilà une question qu’elle est bonne ! Mon point de vue est proche de celui de l’auteur, mieux vaut ne rein mettre que d’implémenter un moteur de recherche de base avec une indexation automatique. Soyons honnêtes, ce type de moteur ne remonte jamais rien d’utile, alors pas de fausse promesse qui risquent d’engendrer de la frustration. Mieux vaut donc se concentrer sur un système de navigation intuitif et une arborescence logique et fluide.

Une série de présentations sur l’architecture de l’information d’entreprise

Le site Atomiq nous propose aujourd’hui une série de présentations glanées à différentes conférences données par différents interlocuteurs mais traitant toutes de l’architecture de l’information d’entreprise : Enterprise IA summary. Derrière ce terme un peu barbare, se cache une pratique (vision ?) qui consiste à soigner l’architecture de l’information non plus au sein du site web d’une entreprise, mais dans l’entreprise en elle-même. En quelque sorte, il s’agit de redéfinir la politique de gestion de l’information, ou de gestion documentaire, ou de gestion du savoir faire (comme vous préférez !). Bref, à vous de vous faire une idée en visionnant ces quelques diaporamas.

Notons pour les néophytes que l’architecture de l’information est une discipline qui se situe à cheval entre deux mondes : le monde des documentalistes / bibliothécaires et le monde des ergonomes. Dans cette série de présentations, les thèmes et visions présentées relèvent plus de la gestion de l’information que de la conception d’interfaces. Si ce sujet vous intéresse, vous pourrez l’approfondir sur un site comme le Figoblog.

Evaluation heuristique pour l’architecture de l’information

Si vous vous intéressez un minimum à l’utilisabilité, vous devez forcement avoir entendu parlé des évaluations heuristiques popularisées par Jakob Nielsen dans son célèbre article : heuristic evaluation. Je vous propose aujourd’hui un principe similaire, à savoir une liste de critères permettant de faire un diagnostique rapide d’un site mais adaptée à l’architecture de l’information, ça se passe sur le blog de Lou Rosenfeld : Information Architecture Heuristics.

Architecture de l’information et CSS

Lors d’une récente conférence, deux leaders d’opinion dans leur domaine respectif (Nate Koechley, expert en développement web et Christina Wodtke, auteur du livre IA: Blueprints for the web) ont lancé un pavé dans la marre en proposant une méthode de travail où les architectes d’information et les développeurs utilisent une nomenclature commune pour concevoir un site web : First Things First: IA and CSS. Je vous recommande de visionner la présentation Powerpoint qui détaille un peu plus leur proposition, notamment sur les point suivants : utiliser un système de nommage compatible avec les feuilles de styles, hiérarchiser les blocs d’information, définir des liens de relation entre les blocs et enfin utiliser la sémantique du HTML pour décrire les différents éléments d’une interface. Le auteurs vont encore plus loin et proposent carrément de remplacer les maquettes fonctionnelles par des prototypes HTML.

J’avoue être plus que sceptique quant à cette démarche. En effet, je suis pour :

  • Utiliser des termes précis pour chacun des éléments d’une interface graphique (un menu déroulant n’est ni un select ou une combo box ou un drop down menu, c’est un menu déroulant) ;
  • Bien identifier les différents blocs d’information et leur donner des noms cohérents (pavé d’information contextuel et non bloc de gauche) ;
  • Travailler de concert avec les équipes de développement pour être sûr que l’ensemble des subtilités d’une interface définies lors de la phase de conception soient bien prise en compte.

Par contre, je suis contre :

  • Empiéter sur le travail des développeurs et décrire des éléments de l’interface à l’aide de la sémantique HTML (un menu de navigation n’est pas forcement une UL) ;
  • Remplacer les maquettes fonctionnelles par des prototypes HTML (on se rapproche plus ici du eXtreme Programming que de la conception centrée sur les besoins des utilisateurs) ;
  • Trop impliquer les équipes techniques dans les étapes de conception (lors des phases initiales d’un projet, les considérations techniques ne doivent pas polluer la formalisation des besoins du client. Des arbitrages pourront être fait lors de phases ultérieures, mais la conception devrait se faire en toute impartialité et en priorité en fonction des besoins exprimés par les utilisateurs et non en fonction de ce que les équipes techniques peuvent ou savent faire).

Vous l’aurez compris, j’ai un avis très partagé sur la question. Je vous invite encore une fois à vous pencher sur le sujet car je pense que l’on a pas fini d’en entendre parlé…