Recherche basée sur plusieurs champs - convivialité
Nous avons un scénario de recherche dans lequel l'utilisateur devrait pouvoir effectuer une recherche basée sur quatre entrées, trois étant des entrées de texte 'facultatif' et la quatrième étant une case de sélection
Nous sommes venus avec ci-dessous trois approches pour cette
approche 1: seules les entrées et les résultats sont affichés dans l'ordre le plus pertinent, c'est-à-dire si l'utilisateur entre un, deux et trois -
les résultats correspondant (un ET deux ET trois) sont affichés en premier, ensuite ( un ET deux), ensuite (deux ET trois), puis les résultats correspondant un seul, deux, trois et ainsi de suite ...
approche 2: donnez une entrée supplémentaire à l'utilisateur qui demande une préférence de recherche - si les résultats doivent être basés sur AND ou OR - donc si l'utilisateur a des valeurs entrées dans un et deux, fourni une option en quatre et si ET est sélectionné - les résultats correspondront sur (un ET deux ET quatre)
si OR est sélectionné - les résultats correspondront sur (un OU deux OU quatre)
Approche: Recherche plus avancée - où AND ou OR critères peuvent être fournis pour chaque entrée
Les utilisateurs finaux de l'application sont des consultants commerciaux sans formation en mathématiques et nous voulons rendre l'application utilisable sans aucune formation spéciale.
Mon choix personnel est l'approche 1 - qui est bien plus propre et les résultats les plus pertinents sont affichés en premier - sans avoir besoin d'expliquer beaucoup à l'utilisateur final ...
Étant donné qu'il n'y a aucun impact sur les performances de recherche quelle que soit l'approche que nous adoptons, quelle est la meilleure approche parmi ces trois? ou existe-t-il une autre façon de faire mieux?
Ce n'est pas une réponse directe, mais êtes-vous absolument sûr que vos utilisateurs souhaitent réellement plusieurs boîtes dans lesquelles ils tapent un terme de recherche? Donc, souvent, les gens créent des zones de recherche qui correspondent aux champs de la table de base de données, quelque chose comme ceci:
(SELECT * FROM Users
Email: [ ] WHERE Email LIKE '%email%' AND
First: [ ] First LIKE '%first%' AND
Last: [ ] Last LIKE '%last%')
Mais c'est une complication inutile qui a peu de pertinence pour l'utilisateur. Ils veulent juste chasser quelqu'un et laisser l'ordinateur s'en occuper. Quelque chose comme ça fonctionne mieux:
(SELECT * FROM Users
Name: [ ] WHERE Email LIKE '%name%' OR
First LIKE '%name%' OR
Last LIKE '%name%')
Sur une note connexe, il est beaucoup plus facile d'avoir une seule boîte et de permettre aux utilisateurs d'utiliser des mots clés que de demander aux utilisateurs de construire une requête à partir de plusieurs boîtes. Plutôt que votre interface, pourriez-vous utiliser l'analyse comme [alpha AND beta OR gamma], et le fractionner après le soumettre en une demande plus conviviale pour la base de données?
En conclusion, dans la mesure du possible, recherchez chaque champ probable pour leur demande en utilisant OR. Pour les demandes entre différents champs, utilisez AND. Le nombre de cas d'utilisation où cela ne sera pas suffisant pour les besoins des utilisateurs est extrêmement faible, et j'ai réussi à rechercher des milliers d'utilisateurs avec cette méthode. Voici une maquette de l'interface de recherche que j'ai conçue lors de mon travail précédent:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Si vous avez recherché 'john smith' dans le nom, en arrière-plan la recherche construite est devenue similaire à 'où premier, dernier ou email LIKE'% john% 'ET premier, dernier ou email LIKE'% smith% '. 99 fois sur cent, ils ont obtenu exactement ce qu'ils attendaient.
La ponctuation a été supprimée, ce qui signifie également que des recherches comme celle-ci dans l'adresse ont également fonctionné parfaitement: "123 Main Street, 53225" dans l'adresse. J'ai optimisé légèrement et je n'ai pas cherché dans le champ "code postal" des jetons non numériques. Ce n'est que très rarement dans des conditions réelles que cela produit des résultats inattendus. Un exemple pourrait être: 54901 Wisconsin Ave. Cela entraînerait un utilisateur très spécifique, mais il obtiendrait également des dizaines ou des centaines de résultats du code postal 54901 (qui se trouve être dans le wisconsin). Mais l'interprétation ambiguë se produit beaucoup moins dans le monde réel que vous ne le pensez, et la facilité d'utilisation que ce type de recherche flexible vous offre est excellente.
Le résultat final est que les requêtes font plus de travail (beaucoup de recherche par rapport aux champs non pertinents) afin d'économiser beaucoup de temps et de réflexion à l'utilisateur. C'est presque toujours le bon compromis à faire, sauf si votre base de données ou votre volume de recherche est énorme.
Je pense que l'approche 1 et l'approche 2 peuvent être déroutantes pour un utilisateur car il peut ne pas être en mesure de comprendre l'interaction/la relation entre chaque champ.
Je pense que l'approche 3 est la plus simple, mais je ferais un changement: puisque le choix est binaire ('OU' ou 'ET'), vous devriez utiliser des boutons radio plutôt qu'une liste déroulante.
L'interface utilisateur est trop encombrée. Je suis donc censé lire chaque champ et décider ce que je veux entrer?
Pourquoi ne pas consolider tous les champs de recherche, exécuter la requête en tant que recherche "ET" et effectuer des tests pour déterminer votre niveau de confort avec les résultats renvoyés?
Gardez à l'esprit l'approche "orientée recherche" que nous voyons dans Google, iOs et Android UIs, TOUT est consultable, vous tapez dans UNE BOÎTE et la recherche est exécutée sur plusieurs facettes.
Vous voulez que votre interface utilisateur soit aussi efficace et économique que possible, alors pourquoi s'écarter de ce qu'ils connaissent déjà?
Avez-vous besoin d'aller aussi loin et de proposer des choix en fonction de chaque champ de saisie? Sinon, approche # 2 est ce que je choisirais.
Compte tenu de l'arrière-plan de votre public, il serait préférable de choisir quelque chose de différent de AND/OR. Que diriez-vous de quelque chose comme
(o) All of these terms' vs. ( ) 'Any of these terms'
Que diriez-vous de quelque chose comme ceci: adoptez l'approche probabiliste impliquée dans l'approche 1 (plus il y a de correspondance entre les termes, mieux c'est), et contraignez-la éventuellement en exigeant que certains termes soient présents. Cela peut éviter d'avoir à expliquer à l'utilisateur à quoi servent AND et OR sont pour.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
