Quand devez-vous commencer la saisie semi-automatique d'une recherche dans le champ de recherche de saisie semi-automatique?
Nous mettons en œuvre un champ de recherche de saisie semi-automatique sur un site Web sur lequel nous travaillons. Cependant la question se pose:
À quel moment devez-vous commencer à afficher les résultats de la saisie semi-automatique?
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Nous avons quelques options:
- Commencez à afficher les résultats immédiatement lorsque l'utilisateur commence à taper (pourrait gêner si les gens tapent accidentellement, et il y a peut-être un coup de serveur pour le faire ici)
- Attendez jusqu'à ce que deux caractères aient été saisis pour être plus sûrs que les gens tapent intentionnellement dans ce champ (risque de ne pas retourner les réponses de saisie semi-automatique pour les requêtes à deux chiffres comme C #)
- Ajoutez un délai de x ms avant de retourner les résultats (si oui, quel est le délai idéal?)
Existe-t-il une façon idéale de procéder? Je crains que l'affichage trop rapide des résultats n'ennuie les gens (tout comme les menus avec survol et autres), mais ne pas présenter les résultats assez rapidement annule le but de la saisie semi-automatique en premier lieu.
Peut-être qu'une approche hybride aurait du sens. Ce que je pense serait de lier le délai au nombre de caractères déjà saisis, avec un délai plus long pour moins de caractères.
Si un utilisateur n'a tapé que `` K '', il va probablement taper beaucoup plus, donc une suggestion instantanée retournerait plus de résultats (moins susceptible d'avoir sa cible en haut), risquerait plus de scintillement (car il continue de taper) et augmenter les accès au serveur (car ils sont plus susceptibles de continuer à taper quoi que ce soit. Si c'est tout ce qu'ils vont taper, ils s'arrêteront et la saisie semi-automatique à laquelle ils s'attendaient déjà se déclencherait.
Au moment où ils ont tapé 'Kittens on Skat', l'inverse de tout ce qui précède est vrai, donc un retard plus court à zéro serait plus approprié.
Généralement, la saisie automatique/la saisie semi-automatique est instantanée , et pour éviter toute confusion, je recommande de s'en tenir à la norme de saisie semi-automatique instantanément après un seul caractère.
Pour aucune autre raison que la convention, je suggère de conserver un instant, la saisie semi-automatique d'un caractère; chaque barre de recherche à ma portée agit de cette façon, y compris Google.com, Google Chrome, iTunes, Visual Studio, SQL Server Management Studio, Google Search sur Android ... et si Microsoft, Apple et Google sont tous d'accord sur quelque chose, ils ont souvent une raison. Non pas que vous devriez suivre aveuglément la convention, mais les conventions sont confortables et à faible friction vous avez donc généralement besoin de bonnes raisons pour commencer à les briser.
Tout retard que vous ajoutez risque de pousser les utilisateurs à se demander si cela fonctionne; est-ce vraiment un champ autocompelte? Il s'est terminé automatiquement avant, pourquoi n'est-il pas maintenant?.
Selon le fonctionnement (et la qualité) de votre saisie semi-automatique, les utilisateurs peuvent s'attendre à ce que les résultats soient instantanés ou viennent après une lettre; après des mois de travail avec Chrome j'ai appris quel site Web il affichera lorsque je tape "t" (Twitter) "g" (gmail) ou u (ux.stackexchange). Si je a dû attendre ou taper une lettre supplémentaire, cela ralentirait le flux de travail. Tant que les résultats de la saisie semi-automatique ne sont pas automatiquement insérés, ce qui signifie que vous devez les effacer manuellement, il y a peu de danger à être un peu trop zélé.
Cependant, si vous avez quelque chose de plus que la saisie semi-automatique, comme la recherche de Google Instant, vous pouvez insérer un peu de retard pour éviter d'échanger de grandes zones de l'écran (ou d'effectuer des opérations lentes/gourmandes en données) à plusieurs reprises pendant les recherches ordinaires. Google Instant attend peut-être quelques centaines de millisecondes avant d'afficher des résultats "instantanés", et l'historique de recherche Google enregistre uniquement les événements où vous avez arrêté de taper pendant trois secondes. Trois secondes est probablement trop conservateur dans la plupart des cas, mais il est intéressant de noter que les événements les plus "importants" (saisie semi-automatique, puis affichage des résultats, puis enregistrement en tant qu'historique) prennent chacun beaucoup plus de temps. La saisie semi-automatique n'est pas aussi ennuyeuse et a peu d'inconvénients, elle s'affiche donc instantanément. L'affichage des résultats nécessite plus de rafraîchissement d'écran et plus de trafic réseau, donc c'est un peu plus lent. L'enregistrement de l'historique est plus "permanent", donc pour éviter les résultats encombrants/trompeurs, la minuterie est assez conservatrice.
Je suggère de fixer une limite de caractères.
Vous devez décider du nombre de caractères approprié dans votre cas. La fonctionnalité de saisie semi-automatique devrait limiter la liste à un certain nombre de résultats sélectionnables, et si un utilisateur se voit présenter une liste, disons 100 éléments, alors elle n'est pas utilisable du tout.
Par exemple, s'il y a 400 éléments à partir de "a", afficher la liste complète des 400 éléments est inutile, car l'utilisateur devrait - littéralement - se frayer un chemin à travers eux. Si la deuxième lettre la limite à environ 20, vous pouvez penser à utiliser cette limite.
Bien sûr, l'ajustement lettre par lettre n'est pas recommandé, sauf dans les situations où il y aurait un nombre d'options totalement différent à partir d'une lettre que à partir d'une autre lettre - mais je pense que ces situations sont rares (par exemple, si vous avez une liste d'ingrédients, y compris noms d'ingrédients et symboles E-123). Je pense que le nombre rationnel des options à afficher serait jusqu'à 10, peut-être 15.
Bien sûr, vous pouvez utiliser une autre approche et utiliser des informations statistiques pour que les éléments apparaissent sur la liste, de sorte que lorsque quelqu'un tape "a" seuls certains éléments commençant par "a" apparaissent (ceci est utilisé par Google par exemple - l'algorithme est plus compliqué, mais en général c'est comme ça - lorsque vous tapez plus de lettres, différentes suggestions apparaissent). Cette méthode, cependant, peut être utilisée pour rechercher à travers un grand nombre de données qui (de par sa nature) est assez chaotique, et il ne sert à rien de l'organiser. Chaque fois que les utilisateurs attendent les données à organiser, l'approche statistique peut conduire à la confusion (par exemple, les utilisateurs peuvent s'attendre à ce que "Smits" apparaissent avec "Smith" alors qu'il n'est pas autorisé à être affiché en raison de l'algorithme statistique) .
Tout comme l'a dit Ben Brocka, je dirais aussi instantanément. Pour ajouter à cela, je dirais également que si vous avez déjà utilisé Intellisense dans Visual Studio ou un produit similaire, vous remarquerez qu'il est également instantané - en fonction du premier caractère que vous entrez. Ceci est très utile car en tant qu'utilisateur, je voudrais savoir ce qui est disponible en fonction du premier caractère que j'entre. Si, par hasard, je ne sais pas comment "mettre des mots" dans ce que je recherche, la recherche instantanée par le premier caractère est pratique pour m'aider à formuler mes mots.
Comme pour toutes les questions de conception, cela dépend du contexte et du domaine.
Avec une boîte de saisie semi-automatique, ce que vous essayez de faire est de distraire l'utilisateur (dans le bon sens) en lui montrant un `` court-circuit '' à sa tâche planifiée. Si vous le faites correctement, l'utilisateur trouvera l'élément qu'il souhaite et terminera rapidement sa soumission. Si vous vous trompez, vous faites essayer à l'utilisateur de reprendre sa tâche, alors qu'il continue de chercher entre la zone de texte et les correspondances de recherche jusqu'à ce que quelque chose se produise. C'est toujours mieux que pas de saisie semi-automatique, mais c'est légèrement sous-optimal.
La question est alors "quand puis-je deviner ce que veut dire un utilisateur?". Cela dépend de votre domaine - à quel moment pouvez-vous commencer à deviner de manière fiable? Dans certains domaines, certains termes peuvent apparaître avec une régularité disproportionnée, vous pouvez donc être à peu près certain que lorsqu'un utilisateur saisit la première lettre de l'un de ces termes, ils sont susceptibles d'être mis en correspondance. De même, si l'utilisateur a déjà un historique de recherches, vous pouvez être sûr qu'il cherche à effectuer à nouveau la recherche (en supposant qu'il est utile de répéter les recherches - encore une fois, cela dépend de votre contexte).
Cela étant dit, j'ai observé des tests utilisateur avec des remplissages automatiques qui apparaissent immédiatement, même lorsqu'ils donnent des suggestions qui ne sont pas appropriées, et je n'ai vu aucune conséquence majeure de cela. Cela suggère que toutes choses étant égales par ailleurs, pécher par excès de vitesse.
En plus de ce que d'autres ont dit, je décrirai un comportement d'interface utilisateur souvent ennuyeux dans ce contexte: Parfois, au fur et à mesure qu'une personne tape, la saisie automatique continue de changer pour presque toutes les lettres tapées. Re-flasher de cette façon ajoute quelque chose comme un scintillement que les utilisateurs ont signalé comme extrêmement ennuyeux.
Je ne sais pas quelle est la bonne solution, mais quelque chose à garder à l'esprit. Peut-être une limite sur la fréquence de rafraîchissement?
Quelque chose que je considère très important avant de finaliser une approche. Qui/quel est le (plus grand) groupe d'utilisateurs finaux de votre application?
Il est stupide, à mon humble avis, de retarder une auto-complétion de "temps". Je tape des sites Web extrêmement rapides et je déteste qui pensent que ma frappe est lente et l'auto-complétion automatique après avoir saisi le terme. Là encore, j'adore ces sites Web de voyage spécifiques, qui feront apparaître Birmingham dès que j'aurai tapé B dans la zone de recherche.
Une autre chose à garder à l'esprit est la latence du réseau. Allez-vous traiter avec des utilisateurs finaux à des vitesses Internet extrêmement lentes? J'éviterais complètement cela si cette application était destinée à un endroit qui avait des connexions extrêmement lentes.
J'ai fait une application web pour un assembleur automobile et ils ont utilisé beaucoup de joints dans leurs composants. Étant donné que les opérateurs de saisie de données étaient extrêmement efficaces, j'avais écrit un algorithme pour trouver de vrais `` mots '' tapés dans des champs (vraiment simple à faire en Java), puis compléter automatiquement Ex SealABC SealXYZ, etc. YMMV.