Retard sur la frappe lors de la recherche pendant la frappe
Je déploie une recherche instantanée sur mon application Windows. Lors de la première implémentation, lorsque l'utilisateur tape une clé, le moteur de recherche effectue une requête et renvoie les résultats. Je pensais que ce n'était pas trop efficace, car lorsque l'utilisateur veut rechercher un long mot, chaque caractère fait une requête, j'ai donc fait démarrer la recherche un peu retardée, pour permettre à l'utilisateur d'écrire le mot complet avant qu'il ne commence à interroger et charger les résultats dans le tableau. Plus efficace, moins de pépins lorsque les lignes sont rechargées.
Est-ce une bonne pratique de toute façon? Y a-t-il une convention à ce sujet? Je cherche une étude de cas sur combien de millisecondes ce délai devrait être, mais je n'ai rien trouvé. Un court et l'application fera beaucoup de requêtes lorsque l'utilisateur tape lentement. Un long, et l'utilisateur percevra l'application comme lente dans le chargement des données.
Oui, c'est une excellente pratique. Cela peut même améliorer la réactivité de votre application, car effectuer la recherche réelle à chaque pression de touche peut entraîner des retards en soi.
J'ai construit un composant (que nous utilisons partout pour cela et à des fins similaires) qui définit essentiellement deux fois: un temps minimum pour attendre plus d'entrée et un temps maximum à partir de la première entrée pour commencer à exécuter l'action. La minuterie minimale est réinitialisée à chaque modification de l'entrée, la durée maximale n'est réinitialisée qu'au déclenchement de l'action (la recherche, dans votre cas.) De cette façon, vous évitez la situation que vous décrivez. La réponse à cette configuration dans les applications que j'ai construites a été très bonne.
Je suppose que le timing idéal dépend du cas d'utilisation exact et du public, mais j'utilise des valeurs dans la plage de 0,1 s pour l'attente minimale et de 0,8 s pour le maximum.
Je n'ai pas d'études sur la saisie semi-automatique en particulier, mais la latence perceptible pour une interface utilisateur est estimée à 100 millisecondes . À ce stade, l'utilisateur sent qu'il a le contrôle et l'interface est réactive.
Dans cet esprit, il y a quelques facteurs à considérer.
- À quelle vitesse votre requête reviendra-t-elle sur des connexions Internet lentes/des ordinateurs plus lents?
- Comment optimisez-vous la livraison des données? Est-il compressé? JSON? HTML?
- Quelle puissance de traitement est nécessaire pour déballer les données retournées?
- Combien de connexions simultanées votre base de données/serveur peut-elle gérer si plusieurs utilisateurs sont en jeu?
- Les données peuvent-elles être mises en cache sans toucher la base de données?
- Les résultats sont-ils suffisamment finis pour être même stockés sur la page?
En général, je retarderais la recherche jusqu'à ce qu'au moins 2 caractères aient été tapés, faire de la recherche une demande asynchrone, mettre en cache les requêtes populaires pour éviter un hit de base de données, et utiliser un format JSON et le compresser. Et, comme Mervin l'a mentionné, s'il y a un retard pour une raison quelconque, utilisez une icône de chargement pour informer l'utilisateur que quelque chose se produit. Je n'ai jamais expérimenté avec un délai de recherche intentionnel au-delà de la limite de deux caractères, mais je soupçonne que quoi que ce soit au-delà de 100 millisecondes aller-retour ne passerait pas le test "il se sent réactif".
Mise à jour : En relisant votre question, je constate que j'ai raté qu'il s'agit d'une application Windows plutôt que d'une application Web. Cependant, la plupart des conseils s'appliquent toujours.
Je ne suis pas sûr de comprendre la logique qui sous-tend le retard de l'affichage de la frappe. N'oubliez pas que votre frappe est l'action principale que l'utilisateur effectue (les résultats de recherche résultants sont secondaires) et l'utilisateur s'attend à une réponse immédiate à l'action principale qu'il a effectuée. Un retard dans la réponse ne ferait que le confondre.
Cependant, en ce qui concerne le retard dans l'affichage des résultats de recherche, je recommande d'utiliser l'une ou l'autre de ces approches:
- Vos réponses ne doivent pas être immédiates. Jquery Token Input (un plugin de saisie semi-automatique recommande lui-même un délai de 300 millisecondes). Un court délai ne va donc pas frustrer l'utilisateur. Cependant, je recommande d'afficher un indicateur en cours qui informe l'utilisateur que les résultats de la recherche sont en cours de récupération. Pour citer ceci article de magazine fracassant
Idéalement, les résultats seront affichés immédiatement, mais un indicateur de progression (recherche…) devrait être utilisé pour les commentaires du système. Fidelity (ci-dessous) en affiche un où les résultats seront éventuellement affichés.
- Étant donné que l'un de vos défis est qu'il y a de la place pour beaucoup de résultats avec chaque personnage ajouté, je recommande de permettre à l'utilisateur d'étendre ses résultats afin que les résultats soient à la fois spécifiques à ce qu'il recherche et que vous envoyez également un moins de requêtes. Voici un exemple de Google et photobucket le font
Modèles d'interface utilisateur pour les applications mobiles: recherche, tri et filtrage
Je ne connais aucune étude de cas, mais voici ce que j'ai fait quand j'ai fait une "recherche instantanée" dans ma webapp et pourquoi.
Je ne lance jamais de requêtes automatiquement après avoir tapé quelques caractères. À mon avis, les zones de recherche qui y sont assez compliquées et ennuyeuses. Au lieu de cela, je ne soumets la requête qu'une fois que l'utilisateur arrive.
Pour ceux qui ne savent peut-être pas que vous pouvez appuyer sur Entrée pour soumettre, j'ai ajouté une petite icône de recherche (loupe) dans la zone de recherche, qui s'affiche également si vous cliquez dessus. Certains utilisateurs moins expérimentés recherchent toujours un bouton "soumettre la recherche" pour cliquer et peuvent être un peu confus s'ils n'en trouvent pas.
Vous pouvez adapter votre champ de saisie à l'utilisateur. Autrement dit, lorsque l'utilisateur tape les premiers caractères, vous mesurez la vitesse à laquelle ils l'ont fait. Pendant que l'utilisateur continue de taper, attendez qu'il ralentisse par rapport à sa vitesse initiale (ce qui indique une demande terminée ou au moins une pause dans la réflexion) et soumettez votre demande de recherche instantanée. Cela vous permettra de fournir la meilleure expérience aux dactylographes rapides et lents.
Le principal problème des retards est qu'ils ne s'adaptent pas à l'environnement (dans ce cas aux différences d'utilisateurs).
C'est pourquoi j'ai une règle "Utiliser les délais pour contrôler quelque chose est toujours mauvais."
La solution la plus appropriée dans ce cas est simplement de faire une demande à chaque frappe.
Si vos demandes ne sont pas assez rapides - je veux dire garanties 20..50 demandes par seconde, vous devez organiser les demandes de manière asynchrone - je veux dire dans un fil séparé et rafraîchir la fenêtre de proposition lorsque la demande revient , permettant à l'utilisateur de taper en même temps. De cette façon, le retard sera introduit automatiquement et dépendra de l'environnement, pas des constantes prédéfinies.
Une astuce courante dans une telle situation consiste à ne demander que plusieurs premières correspondances de la requête et à demander les autres uniquement si l'utilisateur fait défiler la fenêtre de proposition.
Si l'algorithme de correspondance est suffisamment bon, l'utilisateur choisira l'une des premières propositions dans la plupart des cas.