web-dev-qa-db-fra.com

Combien de temps faut-il rebondir la saisie de texte

Disons que nous avons un exemple simple comme ci-dessous.

<input id="filter" type="text" />
<script>

    function reload() {
     // get data via ajax
    }

    $('#filter').change($.debounce(250,reload));
</script>

Ce que nous faisons, c'est introduire un petit délai afin de réduire le nombre d'appels à reload pendant que l'utilisateur tape du texte dans l'entrée.

Maintenant, je me rends compte que cela dépendra au cas par cas, mais existe-t-il une sagesse acceptée quant à la durée du délai de rebond, compte tenu d'une vitesse de frappe/interaction moyenne (ou peut-être le plus petit dénominateur commun)? En général, je joue avec la valeur jusqu'à ce qu'elle "se sente" bien, mais je ne représente peut-être pas un utilisateur typique. Quelqu'un a-t-il fait des études à ce sujet?

javascriptuser-interfaceuser-experience
23
Sam Shiles

Comme vous l'avez laissé entendre, la réponse dépend d'un certain nombre de facteurs - pas tous subjectifs.

En général, la raison du recours à une opération anti-rebond peut être résumée comme ayant l'un des deux objectifs suivants:

  1. Réduire le coût de la fourniture d'éléments interactifs dynamiques (où le coût peut être informatique, E/S, réseau ou latence et peut être dicté par le client ou le serveur).
  2. Réduire le "bruit" visuel pour éviter de distraire l'utilisateur avec les mises à jour de page pendant qu'il est occupé.

Temps de réaction

Un nombre important à garder à l'esprit est 250 ms - cela représente le temps de réaction (approximativement) médian d'un humain et est généralement une bonne limite supérieure dans laquelle vous devez effectuer toutes les mises à jour de l'interface utilisateur pour que votre site se sente réactif. Vous pouvez voir plus d'informations sur les temps de réaction humains ici .

Dans le premier cas, l'intervalle anti-rebond exact dépendra du coût d'une opération pour les deux parties (le client et le serveur). Si votre appel AJAX a un temps de réponse de bout en bout de 100 ms, il peut être judicieux de définir votre antirebond à 150 ms pour respecter ce seuil de réactivité de 250 ms.

D'un autre côté, si votre appel prend généralement 4000 ms pour s'exécuter, il est préférable de définir un rebond plus long sur l'appel réel et d'utiliser à la place un rebounce de première couche pour afficher un indicateur de chargement (en supposant que votre indicateur de chargement ne soit pas obscur votre saisie de texte).

$('#filter').change($.debounce(250, show_loading)); $('#filter').change($.debounce(2000, reload));

Capacité de backend

Il est également important de garder à l'esprit le coût de performance de ces demandes sur votre backend. Dans ce cas, une combinaison de vitesse de frappe moyenne (environ 44 mots par minute, soit environ 200 caractères par minute) et la connaissance de la taille de votre base d'utilisateurs et de la capacité de backend peuvent vous permettre de sélectionner une valeur de rebond qui maintient la charge du backend gérable.

Par exemple: si vous avez un seul backend capable de gérer 10 requêtes par seconde et un pic d'utilisateurs actifs de 30 (en utilisant ce service), vous devez sélectionner votre période de contre-rebond de manière à éviter de dépasser 10 requêtes par seconde (idéalement avec une marge de Erreur). Dans ce cas, nous avons 33,3% de la capacité requise pour traiter une entrée par utilisateur par seconde, donc nous devrions idéalement servir au plus une demande par utilisateur toutes les 3 secondes, ce qui nous donne notre 3000ms période anti-rebond.

Performances frontales

Le dernier aspect à garder à l'esprit est le coût du traitement côté client. Selon la quantité de données que vous déplacez et la complexité des mises à jour de votre interface utilisateur, cela peut être négligeable ou significatif. Une chose que vous voulez essayer de vous assurer est que votre interface utilisateur reste sensible aux entrées de l'utilisateur. Cela ne signifie pas nécessairement qu'il doit toujours être en mesure de réagir, mais pendant qu'un utilisateur interagit avec lui, il doit réagir rapidement à eux (60FPS est généralement l'objectif ici).

Dans ce cas, votre objectif doit être de rebondir à un rythme qui empêche l'interface utilisateur de devenir lente ou de ne pas répondre pendant que l'utilisateur interagit avec elle. Encore une fois, les statistiques sont un bon moyen de dériver ce chiffre, mais gardez à l'esprit que différents types d'entrées nécessitent différentes quantités de temps pour terminer.

Par exemple, la transcription d'une phrase de mots courts est généralement beaucoup plus rapide que la saisie d'un seul mot long et complexe. De même, si un utilisateur doit penser à ce qu'il entre, il aura tendance à taper plus lentement. Il en va de même pour l'utilisation de caractères spéciaux ou de ponctuation.

Réponse subjective

En pratique, j'ai utilisé des périodes anti-rebond allant de 100ms pour les données qui sont exceptionnellement rapides à récupérer et présentent très peu d'impact sur les performances jusqu'à 5000ms pour des choses plus coûteuses.

Dans ce dernier cas, l'association d'une courte période anti-rebond à faible coût pour présenter à l'utilisateur des commentaires et la période plus longue pour le travail de calcul réel tend à trouver un bon équilibre entre l'expérience utilisateur et le coût de performance des opérations gaspillées.

Une chose notable que j'essaie de garder à l'esprit lors de la sélection de ces valeurs est que, en tant que personne qui travaille avec un clavier tous les jours, je tape probablement plus vite que la plupart de ma base d'utilisateurs. Cela peut signifier que les choses qui me semblent lisses et naturelles sont choquantes pour quelqu'un qui tape plus lentement, c'est donc une bonne idée de faire des tests utilisateur ou (mieux encore) de rassembler des métriques et de les utiliser pour régler votre interface.

41
Benjamin Pannell