Recherche avec des filtres obligatoires
J'ai du mal à concevoir un champ de recherche avec deux filtres/catégories obligatoires avant que l'utilisateur n'appuie sur le bouton "OK".
Jusqu'à présent, la meilleure solution que j'ai pu trouver était celle-ci:
J'ai présenté la solution suivante à mon client, mais ils insistent sur le fait que ce n'est pas idéal une fois que l'utilisateur devrait ouvrir le bouton de partage et changer l'axe de son curseur et tout cela, mais je ne vois pas vraiment comment cela peut avoir un impact important sur la navigation. Si tout dépendait de moi, je serais d'accord avec celui-ci, mais ils insistent sur le fait que ce n'est pas le format qu'ils veulent, alors oubliez-le.
Eh bien ... des idées?
Je me souviens que GitHub avait quelque chose comme ce que Mike M a suggéré pour leur recherche. Je viens de remarquer que cela a changé, et ce qu'ils font maintenant, c'est que la sélection fasse partie de leur menu de type saisie semi-automatique: 
J'imagine que la sélection par défaut en haut est ce qu'ils croient être le plus courant, ce qui est logique de rechercher dans le référentiel actuel par défaut. Un avantage que je note dans ceci est qu'il vous permet de passer sans tracas. Si je voulais rechercher "Rails" dans "All GitHub" (ce qui est plus logique), tout ce que je dois faire est d'appuyer sur ↓ avant de frapper Enter. Cela signifie que la commutation du filtre n'est qu'une simple pression de touche supplémentaire.
En comparant cela avec d'autres solutions:
- entrée déroulante à gauche signifie que je dois Shift+Tab et frapper ↓ soit une ou deux fois (j'ai l'impression que certaines listes déroulantes ne modifient pas la sélection au premier coup et n'ouvrent le menu qu'avec la sélection inchangée, ce qui me donne une incertitude sur les listes déroulantes en général).
- 2 boutons à droite avec le défaut à gauche signifie que je dois frapper Tab deux fois.
- 2 boutons à droite avec le défaut à droite signifie que je dois seulement frapper Tab une fois pour commuter, mais il n'est peut-être pas intuitif que la valeur par défaut ne soit pas la plus proche de l'entrée.
- entrée radio est comme une liste déroulante mais au moins je peux être sûr que frapper la touche fléchée entraînera un changement de sélection.
Toutes ces autres solutions souffrent également en ce qu'elles ont plus de bruit visuel, lorsque l'entrée n'est pas utilisée. Un avantage qu'ils ont tous, cependant, est qu'ils ne nécessitent pas de javascript (si nous parlons de sites Web ici), ce qui est agréable à la fois pour le développeur et les utilisateurs.
Si le filtre est obligatoire, choisissez la recherche la plus fréquente par défaut.
Vous pouvez essayer une liste déroulante de recherche étendue avant le champ de saisie de recherche. De cette façon, le bouton de recherche est actif depuis le début.
Indiquez en fonction de vos statistiques que la majorité des utilisateurs voudront effectuer une recherche et ne les obligez pas à faire une pause pour choisir un filtre.
Le compromis
Si vous avez des mesures qui justifient la recherche la plus probable, les utilisateurs qui ne voient pas le filtre, et juste la recherche, seront récompensés.
Ceux qui rechercheraient des "fragments" (disons que c'est la moindre des recherches), pourraient ne pas voir la liste déroulante et rechercher immédiatement.
Comme il s'agit d'une tâche obligatoire avant d'interagir avec la recherche, envisagez une recherche comme l'appel à l'action, comme enregistrer ou soumettre. Avant de pouvoir accomplir ces actions, vous devez remplir un formulaire.
Dans ce cas, votre formulaire est un groupe radial et un champ de saisie de texte.
Si ce sont les deux seules options et sont susceptibles de le rester, j'irais avec quelque chose comme ceci:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Avez-vous envisagé une recherche de suggestion automatique pour les deux catégories?
De cette façon, vous fournissez à l'utilisateur une valeur immédiate avant de le forcer à faire un autre choix.
Ce n'est probablement pas une décision de conception idéale - je veux dire I ne ferait certainement pas cela, mais puisque le client semble être un peu tenace, je suis le jeter juste comme une idée.
Deux barres de recherche, une pour chaque catégorie, lorsque l'utilisateur se concentre sur l'une, désactivent l'autre.
Comme je l'ai dit, pas une bonne idée, mais je ne vois rien de mal avec les autres solutions que vous avez déjà présentées au client, donc il me semble que le client ne veut pas vraiment certains qui ont du sens. Au lieu de cela, ils veulent juste ce que ils veulent, et ils veulent juste que vous compreniez ce que c'est.
Peut-être qu'ils veulent quelque chose de stupide comme ça ...?!
Une bonne alternative: recherchez les deux à chaque fois (si les considérations de performances le permettent) et présentez les résultats dans deux onglets "documentos" et "fragmentos". Mettez en avant l'onglet qui est connu pour être sur la recherche la plus fréquente (peut être défini globalement ou un paramètre par utilisateur). Si les performances posent problème ici, exécutez la recherche en remplissant l'onglet d'arrière-plan uniquement si vous cliquez dessus.
Vous pouvez vous demander à quel point le choix est vraiment obligatoire et simplement rechercher dans les deux catégories par défaut. Vous pouvez ensuite proposer des filtres sur la page de résultats pour affiner la recherche.
Si, comme vous le dites, les termes de recherche sont de toute façon longs, les résultats peuvent déjà être suffisamment uniques pour produire ce que les utilisateurs recherchent.
Si vous souhaitez toujours donner toutes les options depuis le début, masquez les filtres sous un tiroir de recherche avancée ou quelque chose de similaire.