La mise en place d’un formulaire de recherche avancée est une étape très délicate, et pas forcément indispensable de la vie d’une application. Particulièrement spécifique au produit, il est par définition très difficile d’en donner un modèle générique sous peine de le rendre totalement inutile. C’est d’ailleurs une des raisons pour lesquelles la grande majorité des formulaires de recherche avancée sont totalement inutilisables, et inutilisés. l’autre étant la victoire de la recherche simple avec des algorithmes de plus en plus efficaces.

Après le live search, la recherche prédictive et la recherche par facettes, je vous propose de nous intéresser à ce rejeton du casse-tête chinois et de l’usine à gaz qu’est souvent le formulaire de recherche avancée.

Un peu d’Histoire

L’origine du formulaire de recherche avancée se perd dans la nuit des temps. On estime son apparition à longtemps avant Jésus Christ aux premiers essais de stockage de données. Il fallait retrouver les données saisies, sans disposer de SQL apparu seulement en 1974.

Chaque progiciel disposait du sien. Ce dernier relevait de la maladroite tentative de mapping du modèle de données plus que d’une véritable recherche fonctionnelle. Bon an, mal an, cela fonctionnait pourtant, car les données à chercher étaient bien définies. Les plus vieux d’entre-vous ont certainement un jour ou l’autre créé une application d’indexation de leur bibliothèque ou de leurs disques à partir d’Access premier du nom ou de DBase II ou III.

Capture d'écran de DBase III

Avec l’arrivée du web, les formulaires de recherche avancée sont doucement tombés en désuétude. Les premiers moteurs de recherche publics comme Infoseek ou Altavista proposaient des formulaires simples. Durant la première bulle Internet, France Télécom mettait cette fameuse simplicité d’emploi avec son slogan Faites un voeu et puis voilà !, diffusé sur toutes les radios de France.

Outre cette volonté de simplicité, les formulaires de recherche avancée étaient difficilement applicables au web. Par définition, on savait ce que l’on cherchait, mais pas où. Il devenait donc impossible de définir des critères de recherche vraiment pertinents, sans compter l’approximation des recherches texte elles-mêmes à l’époque. Nous étions alors en 1997.

En 2002, les formulaires de recherche avancées n’avaient décidément plus la cote, puisque seulement 1.08% des utilisateurs les utilisaient sur le web.

On voit pourtant depuis quelques années les formulaires de recherche avancée revenir sur le devant de la scène. Ce retour en grâce est du à la spécialisation des sites et à l’explosion des applications web. Les premiers bénéficiaires ont d’ailleurs été les sites de rencontre dans lesquels l’affinage de la recherche sur des critères spécifiques est particulièrement important.

Qu’est-ce qu’un formulaire de recherche avancée ?

Un formulaire de recherche avancée est le contraire d’un formulaire de recherche simple. Étonnant non ?

Un formulaire de recherche avancée permet d’effectuer une recherche sur plusieurs critères simultanément. Ces critères peuvent être inclusifs ou exclusifs. Ils peuvent correspondre à des valeurs libres ou prédéfinies.

Dans la grande majorité des formulaires de recherche, vous effectuera le filtrage, si besoin est, sur le critère le plus discriminant. Sur un site de vente de produits culturel, par exemple, vous choisirez le type d’articles en vente.

Recherche basique

Dans un formulaire de recherche avancé, on va au contraire effectuer le filtrage sur les détails ; des détails significatifs, certes, mais des détails quand même : nom de l’auteur, titre, éditeur…

Pourquoi mettre en place un formulaire de recherche avancée ?

J’en vois deux, mais peut-être y en a-t-il plus, et dans ce cas, n’hésitez pas à me les signaler dans les commentaires, j’augmenterai ce billet en conséquence si je les trouve pertinentes.

Dans un site ou application au périmètre clairement défini, mettre un formulaire de recherche avancée est opportun, et même indispensable. On choisira les critères en fonction de l’usage que font les utilisateurs de votre application, ou au moins les usages prévus, quitte à les modifier par la suite. Il ne faut pas rêver : vous concevez une application en imaginant la manière dont les utilisateurs s’en serviront, mais ils n’en tiendront pas compte. C’est la différence entre une logique produit et une logique utilisateur. Figer le formulaire de recherche avancée dès le début de la conception revient un peu à jouer à la roulette russe avec 5 balles dans le chargeur.

Formulaire de recherche de profil de Facebook

Le formulaire de recherche de profils de Facebook est un très bon exemple du genre, que nous étudierons d’ailleurs en détail un peu plus loin.

Google permet d’effectuer des requêtes très complexes, qui vont bien au delà d’une recherche sur “Frédéric de Villamil”. Par exemple, taper intitle:”index.of” (mp3) papillon.de.lumière -html -htm -php -asp -cf -jsp vous permettra de trouver le MP3 de Cindy Sander en téléchargement direct sur Google. Évidemment, ce genre de requête est à réserver aux pirates spécialistes. C’est la raison pour laquelle Google contourne la difficulté en proposant un formulaire de recherche avancée qui générera ces requêtes pour vous. Étonnant non ?

Formulaire de recherche avancé de Google

À quels critères étendre la recherche ?

C’est une très bonne question, et je ne vous remercie pas de me l’avoir posée. J’aurais envie de vous dire aux plus pertinents. C’est évident comme la mort, et ça ne vous avancera pas plus loin.

Tous les formulaires de recherche avancée n’ont pas besoin d’être aussi complets que celui de Facebook. Ce dernier est très intéressant à étudier à plus d’un titre, et il est – à mon avis – remarquablement bien conçu.

Les champs à rechercher sont séparés en 5 sections principales :

  1. Basic info
  2. Contact info
  3. Personal info
  4. Education info
  5. Work info

Facebook était à l’origine un réseau social réservé aux étudiants des universités américaines. Les champs de recherche education info et work info sont pourtant passés en bas de page. Cela traduit bien la mutation de Facebook en réseau social généraliste.

Les thématiques utilisées correspondent aux 5 parties du profil que je vais vouloir remplir en m’inscrivant sur Facebook, selon ce que je vais vouloir en faire. Incidemment, elles correspondent aussi à la manière dont je vais l’utiliser afin de rencontrer mes contacts : personnels ou professionnels, façon Linkedin ou Copains d’avant ? Il est donc très important de savoir comment ses utilisateurs quotidiens se servent de votre application. Tout comme l’existence précède l’essence, l’usage détermine la fonction.

Le formulaire de recherche de profils de Facebook est extrêmement bien conçu. En 1000 pixels de haut, il me permet d’accéder à 30 critères répartis en 5 sections. L’ensemble est compact, mais très lisible, et on comprend facilement où l’on est et où l’on va. J’avais dans un premier temps déploré l’absence de fieldset et de boutons à la fin de chaque section, mais le formulaire reste en fait particulièrement utilisable comme cela, et ces derniers auraient certainement fait perdre de la place sans apporter de gain remarquable.

Mise en place d’un formulaire de recherche avancée

Dans la seconde partie de cet article, je vous propose d’étudier la mise en place d’un formulaire de recherche, en nous appuyant sur celui que l’on pourrait mettre en place sur un système de gestion de contenus particulièrement fourni.

Sélection des données sur lesquelles portent la recherche

Étudiez les sources d’entrées vers vos contenus. Comment vos utilisateurs vont-ils vouloir y accéder ? Quelles meta données souhaitez-vous leur mettre à disposition ? Une fois en possession de ces éléments, mettez de côté le plus discriminant d’entre-eux. Puis, classez les autres par catégories communes.

Critère discriminant

Le critère discriminant doit permettre aux utilisateurs de votre formulaire d’éliminer la très grande majorité des résultats possibles. Idéalement, il ne proposera que deux alternatives, pour ne pas devenir un critère de recherche élargi comme les autres.

J’ai choisi très arbitrairement l’appartenance des contenus :

  • Chercher dans tous les contenus
  • Ne chercher que dans mes contenus

Ce n’était évidemment pas le seul critère possible, et j’ai hésité un moment avec deux autres :

  • État du contenu : en ligne / hors ligne
  • Média

Critère discriminant

Se baser sur les médias permet d’éliminer immédiatement la plus grande partie des contenus disponibles. Malheureusement, le nombre de médias possible était trop grand pour offrir une option simple et rapide à choisir.

Choix des catégories et tri des éléments

Les catégories doivent faciliter la compréhension et l’utilisation de votre formulaire de recherche avancée en les plaçant dans leur contexte. Si vous vous rendez compte qu’elles vous servent de fourre tout, recommencez depuis le départ, vous vous êtes trompé quelque part, très probablement dans le choix de vos champs de recherche.

Catégorie 1 : contenus

  • Recherche sur le contenu
  • Rechercher dans : tout, titre, document, auteurs, meta données…
  • Catégorie(s) : liste à choix multiples
  • Thématique(s) : recherche libre

Catégorie 2 : meta données

  • Recherche sur le média (tous, texte, image, vidéo, son…)
  • Auteur : menu déroulant
  • Langue : menu déroulant
  • Statut : publié, non publié, en attente de publication, modéré, hors-ligne, supprimé…

Catégorie 3 : dates

  • Date de création : intervalle de dates
  • Date de validation : intervalle de dates
  • Date de mise en ligne : intervalle de dates
  • Date de retrait : intervalle de dates

Placez chaque catégorie dans un fieldset, c’est à cela que ça sert, surmonté de la légende adéquate. Quel que soit le style que vous lui donnerez, le fieldset facilite la lecture des éléments en les séparant de manière propre.

Pour les zones définies à l’avance, vous choisirez les éléments suivants :

  • Listes déroulantes pour les critères d’inclusion simples.
  • Listes déroulantes à choix multiples ou liste de cases à cocher pour les critères d’inclusion multiples.
  • Boutons radio pour les critères discriminants.
  • Champs texte pour les recherches libres.

Pour les champs de recherche libre portant sur un nombre relativement fini d’éléments, comme les mots clés, n’hésitez pas à utiliser un peu d’auto complétion, cela facilite grandement l’utilisation et permet de voir comment ils ont été utilisés (masculin / féminin / singulier / pluriel notamment). J’avoue par exemple avoir un faible pour la zone de sélection des stations de départ et d’arrivée sur site de la sncf.

Voilà, c’est tout pour ce soir. Le dernier volet de cette série d’articles sur les formulaires de recherche concernera la mise en forme des résultats de recherche.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: