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

Un peu d’histoire

Le live search, ou recherche dynamique dans la langue de Molière est une méthode consistant à afficher la liste des résultats à mesure que l’utilisateur tape sa requête au clavier sans pour autant devoir recharger la page en cours.

Le premier exemple de live search dont je me souvienne se trouvait sur une variation du thème Kubrick pour Wordpress, et sa systématisation sur une grande partie des templates de la plate-formes de blogs à héberger la plus populaire au monde a probablement fait beaucoup pour sa diffusion. Il donnait en plus à ceux qui l’utilisaient une certaine “classe” à l’époque où le “clica convi” était plus qu’une mode : une religion.

J’ai pour la première fois eu l’occasion d’en mettre un en place dans le cadre professionnel à l’occasion d’une mission de développement d’applications web à la BNP en 2005. Cette solution avait été choisie afin de pallier le déficit en bande passante des agences bancaires toujours en RNIS 64k. En évitant de recharger la page au moment de la validation du formulaire, nous économisions de la bande passante. La requête elle-même était envoyée lorsque tous les 5 caractères, lorsque l’utilisateur appuyait sur la touche “espace”, ou au moment de la validation du formulaire. On associait ainsi le caractère convivial de la chose à une salutaire économie de bande passante.

Malheureusement, dans la majorité des cas, le live search pose plus de problèmes qu’il n’en résout. Cela vient en grande partie d’erreurs d’implémentation, mais également du fait que le live search n’a pas sa place partout.

Plus de problèmes que de solutions

S’il y a un problème, c’est qu’il y a une solution. Et s’il n’y a pas de solution, c’est qu’il n’y a pas de problèmes affirme un vieux proverbe Shaddock. Si le live search permet de résoudre certains problèmes, il a cependant l’inconvénient d’en soulever d’autres, et pas des moindres.

Des usages pas encore assez répandus

Malgré les presque 3 ans d’existence d’AJAX, l’obtention de résultats de formulaire sans validation n’est toujours pas rentré dans les moeurs de Josiane Michu, votre utilisatrice type favorite, et celle-ci peut être assez déroutée par plusieurs éléments.

• Le redesign permanent de la page, à mesure qu’elle tape ses critères de recherche, avec un possible effet “yoyo” très perturbant, particulièrement quand le nombre de résultats de recherche est important.
• L’impossibilité de faire du “pogo sticking” d’un résultat de recherche à l’autre, puisqu’il n’existe pas de page de résultats à proprement dit sur laquelle revenir.
• Concomitante au problème précédent, le live search rend impossible l’ajout de la page de résultats aux bookmarks du navigateur. Cela peut sembler curieux, mais l’expérience m’a montré que Josiane Michu l’utilisait particulièrement pour étudier les différents résultats d’une session de navigation à l’autre.

Un modèle de recherche gourmand en ressources

Le live search est particulièrement gourmand en ressources, puisqu’il nécessite de faire de très nombreuses requêtes sur la base de données, potentiellement une (grosse) chaque fois que l’utilisateur appuie sur une touche du clavier. Il existe toutefois des méthodes permettant de limiter cette dernière, dérivées de la navigation par facettes à laquelle je consacrerai plus particulièrement un billet.

Il est également gourmand en ressource coté client, puisqu’il nécessite de redesigner constamment la page à grands coups de javascript.

Les erreurs à ne pas commettre

Aux problèmes posés par le live search en lui-même viennent s’ajouter les erreurs d’implémentation qui le rendent facilement inutilisables. Comme d’habitude, les cordonniers sont les plus mal chaussés, et vous trouverez sur ce site la majorité des choses à éviter. On dira avec une parfaite mauvaise foi que c’est en guise de proof of concept de cet article.

Oublier le bouton de validation

La question qui revient souvent quand je parle du live search à des néophytes concerne le bouton de validation du formulaire. Après tout, s’il n’y a pas besoin de validation, pourquoi proposer un bouton “Chercher” ?

On en revient là à un problème d’usages hérités à la fois de l’industrie du software et des 10 premières années du web. Un formulaire quel qu’il soit doit être validé pour être pris en compte. Au point de simuler un rechargement de la page malgré des données envoyées en AJAX afin de ne pas dérouter l’utilisateur, comme il m’est arrivé de le voir.

Ne pas proposer de système de recherche traditionnel

Corollaire du précédent, il est particulièrement important de proposer à l’utilisateur un système de recherche traditionnel. D’abord pour ne pas dérouter Josiane Michu qui souhaite pouvoir revenir à volonté sur ses résultats de recherche, mais surtout pour des raisons évidentes d’accessibilité.

En fait, penser à proposer un système de recherche traditionnel revient un peu à construire une maison en commençant par poser le papier peint du salon. Commencez par proposer une application fonctionnant par tous temps et sous n’importe quel navigateur, puis rajoutez-y de l’eye candy.

Réserver trop peu de place aux résultats de la recherche

Trop souvent, le résultat des live search se retrouvent confinés dans la barre latérale du site, exactement comme sur celui-ci d’ailleurs.

Cela n’est pas sans poser de problèmes d’ailleurs, parmi lesquels on retiendra surtout :

• Des titres de résultats quasiment systématiquement sur deux lignes, pour un affichage global qui prendra à coup sûr 2 à 3 écrans.
• Une perte de repères par rapport au formulaire traditionnel cité précédemment.

Quand vous mettez en place un système de recherche traditionnel, ce dernier prend toute la place allouée au contenu du site afin de proposer un espace maximum pour l’affichage des résultats. Alors, pourquoi ne pas faire de même avec votre live search ?

• Vous facilitez la lecture des résultats de recherche, qui sont plus facilement mis en valeur que dans une sidebar. En fonction du nombre de résultats retournés, ces derniers peuvent se limiter à un écran, facilitant la lisibilité, surtout quand on pense à la volatilité du contenu.
• En reproduisant une expérience utilisateur connue et maîtrisée, vous facilite l’adoption du live search par les utilisateurs en ayant l’utilité, mais pas l’habitude.

Ne pas limiter le nombre de résultats par page

Un des gros problèmes du live search réside dans le nombre de résultats retournés pour une recherche simple, sans possibilité de paginer, forcément. Utilisez le formulaire afin de chercher la chaîne test utilisateur, vous verrez que le résultat est inexploitable.

Il faut donc pouvoir limiter le nombre de résultats remontés, et pour cela, il faut les filtrer autrement que par ordre de publication ou ordre alphabétique. Tout dépend de ce que vous souhaitez faire, mais on pourra :

• Faire ressortir les billets les moins lus ou les plus anciens, afin de les mettre en valeur.
• Faire au contraire ressortir le contenu récent, ou le plus populaire.
• Croiser la recherche purement syntaxique avec votre taxonomie pour une plus grande pertinence.
• …

Ne pas trier les résultats

Faire remonter des résultats de recherche, c’est une chose, mais les trier, et communiquer sur cet ordonnancement en est une autre, trop souvent oubliée.

À cet égard, la sortie de Spotlight sous Mac OS X est un exemple du genre : les résultats de recherche sont classés par catégorie, celle-ci étant matérialisée à la fois par le nom du type de résultat (document, vidéo, contact, mail, événement de calendrier…), et par une icône claire et facilement associée au type de résultat concerné. Ce modèle d’affichage a d’ailleurs été repris de manière très réussie sur le live search du site web d’Apple.

Ne pas donner la description des résultats

Et puisqu’on parle de clarifier les résultats de la recherche, je ne crois pas avoir jamais vu de live search sur un site qui affiche autre chose que le titre de la page remontée. Si ce dernier est on ne peut plus clair, ce n’est pas encore trop grave, mais si vous utilisez des titres particulièrement abscons, ou que les contenus remontés sont relativement proches, on cours à la catastrophe.

Là encore, on peut, si on accorde à la sortie du live search suffisamment de place dans l’architecture de la page, reprendre les éléments d’affichage des outils de recherche traditionnels, l’idéal étant d’afficher la chaîne recherchée dans son contexte, si cela est possible, tout en la mettant en valeur en gras.

Conclusion

Comme nous l’avons vu dans ce billet, les contraintes pour rendre un live search vraiment utilisable sont telles qu’on réfléchira souvent à deux fois avant de le mettre en place.

On pourra cependant en utiliser un dérivé qui est la saisie prédictive des informations de recherche, à laquelle je consacrerai le second volet de cette série d’articles.