À quel moment un utilisateur perd-il confiance dans un Spinner occupé?
Le premier scénario est une action qui peut prendre environ 2 à 5 secondes à exécuter une fois que l'utilisateur a appuyé sur un bouton. Un Spinner occupé sera affiché dans le bouton jusqu'à ce que le processus soit terminé.
Une fois l'action terminée, un retour d'information est affiché pour l'utilisateur.
Le deuxième scénario est une action qui peut prendre quelques minutes. Dans ce scénario, je ne pense pas qu'il soit approprié d'afficher simplement un Spinner occupé dans le bouton. Je pense qu'un utilisateur commencerait à se demander si des progrès sont réalisés. Donc, à la place, une boîte de dialogue s'affiche:
En affichant une boîte de dialogue — avec le texte, je pense que l'utilisateur a plus de confiance que l'action est en cours d'exécution.
Ma question est - combien de temps est trop long pour un simple Busy Spinner? Autour de quel délai approximatif devrais-je commencer à introduire un dialogue qui mentionne combien de temps l'action va durer?
Jakob Nielsen a écrit un article intitulé Temps de réponse - 3 limites importantes .
Les conseils de base concernant les temps de réponse sont à peu près les mêmes depuis trente ans [Miller 1968; Card et al. 1991]. Il a écrit ceci en 1993:
- 0,1 seconde correspond à la limite permettant à l'utilisateur de sentir que le système réagit instantanément , ce qui signifie qu'aucune rétroaction spéciale n'est nécessaire, sauf pour afficher le résultat.
- 1,0 seconde correspond à la limite pour que le flux de pensée de l'utilisateur reste sans interruption, même si l'utilisateur remarquera le retard. Normalement, aucune rétroaction spéciale n'est nécessaire pendant les retards supérieurs à 0,1 mais inférieurs à 1,0 seconde, mais l'utilisateur perd la sensation de fonctionner directement sur les données.
- 10 secondes est à peu près la limite pour garder l'attention de l'utilisateur concentrée sur le dialogue. Pour des délais plus longs, les utilisateurs voudront effectuer d'autres tâches en attendant la fin de l'ordinateur, donc ils devraient recevoir des commentaires indiquant quand l'ordinateur s'attend à ce que cela soit fait. Le retour d'informations pendant le délai est particulièrement important si le temps de réponse est susceptible d'être très variable, car les utilisateurs ne sauront alors pas à quoi s'attendre.
En 2014, il a mis à jour ses directives avec ceci:
- 0,1 seconde : limite pour les utilisateurs ayant le sentiment qu'ils manipulent directement des objets dans l'interface utilisateur. Par exemple, il s'agit de la limite entre le moment où l'utilisateur sélectionne une colonne dans un tableau jusqu'à ce que cette colonne soit mise en surbrillance ou indique autrement qu'elle est sélectionnée. Idéalement, ce serait également le temps de réponse pour trier la colonne - si tel est le cas, les utilisateurs sentiront qu'ils trient la table. (Par opposition au sentiment qu'ils ordonnent à l'ordinateur de faire le tri pour eux.)
- 1 seconde : limite pour les utilisateurs ayant le sentiment qu'ils naviguent librement la commande l'espace sans avoir à attendre indûment l'ordinateur. Un délai de 0,2 à 1,0 seconde signifie que les utilisateurs remarquent le délai et sentent donc que l'ordinateur "travaille" sur la commande, par opposition à ce que la commande soit un effet direct des actions des utilisateurs. Exemple: si le tri d'un tableau en fonction de la colonne sélectionnée ne peut pas être effectué en 0,1 seconde, il doit certainement être effectué en 1 seconde, ou les utilisateurs auront le sentiment que l'interface utilisateur est lente et perdra le sens du "flux" en effectuant leur tâche. Pour les retards de plus d'une seconde, indiquez à l'utilisateur que l'ordinateur travaille sur le problème, par exemple en changeant la forme du curseur .
- 10 secondes : Limite pour les utilisateurs gardant leur attention sur la tâche. Tout ce qui est inférieur à 10 secondes nécessite un indicateur de pourcentage de réalisation ainsi qu'un moyen clairement indiqué pour l'utilisateur d'interrompre l'opération. Supposons que les utilisateurs devront se réorienter lorsqu'ils reviendront dans l'interface utilisateur après un délai de plus de 10 secondes. Les retards de plus de 10 secondes ne sont acceptables que pendant les pauses naturelles dans le travail de l'utilisateur, par exemple lors des changements de tâches.
Imaginez que vous et moi nous parlions dans la rue. Vous m'avez demandé si j'avais le temps et avec à peine aucune hésitation je regarde ma montre et je vous dis. Vous n'y réfléchissez pas. Vous me demandez ensuite si je peux vous indiquer les directions vers un café décent. Certaines options peuvent se produire:
Je commence instantanément à dévider un ensemble d'instructions
Il me semble que j'envisage quelque chose - il se peut que j'envisage le meilleur café en tenant compte de l'emplacement actuel, ou j'essaie de trouver les meilleures directions pour marcher.
Je dis que je ne sais pas, mais je rencontre quelqu'un d'autre qui sait, et je peux vous envoyer la réponse par SMS dans quelques minutes.
Je reste là à ne rien faire, presque comme si je ne t'avais pas entendu.
Vos attentes pourraient être pour l'option 1 ou 2. Vous vous rendez compte que si j'indique l'option 2 que cela peut prendre un moment et que vous êtes prêt pour une petite attente, mais cela aide certainement si je vous fais savoir que j'envisage d'abord un quelques très bons cafés avant d'en choisir un, puis de fournir les instructions.
L'option 3 vous permet de reprendre votre vie en main et d'être averti rapidement. Vous n'obtenez pas de réponse tout de suite, mais cela ne sert à rien et vous êtes reconnaissant de ne pas avoir à attendre.
L'option 4 est cependant très déconcertante. Si je continue à rester là sans donner d'autre indice que j'envisage une réponse, vous allez m'inviter avec des choses comme `` n'importe quel café fera l'affaire '' ou `` s'il n'y a pas de café près d'ici, c'est bien '', ou 'oublie ça, je vais juste me promener!'.
C'est la même chose avec les ordinateurs - cela fait toujours partie d'une conversation entre vous et l'ordinateur. Vous ne pouvez pas vous attendre à une réponse à quelque chose de complexe dans un dixième de seconde. Vous vous attendez à un indice que la demande est considérée utilement. Vous vous attendez à une indication du type de réponse dans une seconde environ, et vous êtes déconcerté si vous n'avez pas tout de cette rétroaction en quelques secondes. Et si l'attente totale est supérieure à quelques secondes, vous aimez savoir ce qui est envisagé - est-ce que je pense à quelques cafés locaux ou suis-je calculer les directions de Londres à un grand petit café indépendant à Seattle.
la règle de Scott Klemmer est la suivante:
Réponse plus courte qu'une seconde: pas de retour
Réponse entre 1 et 5 secondes: BusySpinner
Réponse de plus de 5 secondes: barre de progression
10 secondes, c'est long. Vous devez faire part de vos commentaires à l'utilisateur avant qu'il/elle se désintéresse naturellement de ce que fait votre logiciel et soit frustré que votre logiciel ait perdu son temps.
Selon cela article de NNGroup basé sur des études de psychologie cognitive:
- après 1 seconde l'utilisateur peut commencer à perdre son flux de réflexion sur le processus actuel.
- au bout de 10 secondes l'utilisateur reportera très probablement son attention sur une autre tâche
Nous ne voulons pas risquer que l'utilisateur porte son attention sur autre chose, nous devons donc afficher la boîte de dialogue avant ces 10 secondes. En outre, les études ont plus de 25 ans, les ordinateurs sont donc devenus beaucoup plus rapides et les utilisateurs s'attendent à ce que tout se charge plus rapidement.
C'est pourquoi je suggère un seuil d'environ 3 secondes où la boîte de dialogue avec les informations de retard devrait être affichée.
Fondamentalement, plus vous fournissez d'informations à l'utilisateur lors du chargement, plus il est probable qu'il n'abandonnera pas le processus. Essayez d'afficher:
- utiliser la barre de progression
- expliquer pourquoi le chargement prend du temps
- afficher l'heure approximative de chargement
Dix secondes et après cela, je commence à penser "cela ne fonctionne pas" et je m'inquiète que ma carte de crédit soit ou non traitée ou traitée deux fois si je dois recommencer.
Il est bon de changer le message après 10-15 secondes en "il est toujours en cours de chargement, pas besoin de s'inquiéter" ou tout autre message positivement rassurant.
Un exemple est d'envoyer un e-mail sur gmail sans laisser la pièce jointe à pré-télécharger. Le message passe de "envoyer" à "cela fonctionne toujours".
Veuillez noter qu'il doit y avoir une sorte de réponse du serveur pour confirmer que le processus est toujours en cours ou signaler une erreur à un utilisateur.
Désolé, vous citez tous d'anciennes recherches. Google l'a mis à jour.
125 ms, l'utilisateur attend une réponse quelconque, comme une icône de chargement apparaissant après le clic.
L'utilisateur de 250 ms commence à remarquer que l'action se produit.
500 ms, l'utilisateur s'attend à être mis à jour lors de la réponse.
1s, l'utilisateur attend que le contenu soit chargé.
10s j'abandonne.
Diapositive 12: https://docs.google.com/presentation/d/13AJe2Ip4etqA8qylrva7bEgu1_hAvsq_VQiVOAxwdcI/mobilepresent?slide=id.g1e697bbb_0_7
https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail?hl=en
Outre toutes les excellentes réponses soumises ici, je tiens à ajouter que les attentes d'un utilisateur sur une connexion Internet à faible bande passante (oui, elles existent!) Sont entièrement différentes de celles d'un utilisateur sur une connexion à fibre optique à haute vitesse .
Un défi de programmation survient lorsque l'on ne sait pas (à l'avance) la durée de la tâche est susceptible de prendre, soit parce que la tâche elle-même varie ou parce qu'elle pourrait être exécutée sur différents processeurs de vitesse. Idéalement, nous voulons rendre notre code indépendant de la taille des tâches et des limitations matérielles/OS, et fonctionner de manière cohérente dans toutes/presque toutes les situations.
Si nous montrons une barre de progression, (ou même un spinner), elle pourrait simplement scintiller à l'écran et disparaître immédiatement, ce qui déconcerte l'UX à mon avis.
Une solution loin d'être idéale (parfois mise en œuvre) consiste simplement à décider que l'utilisateur attendra un certain temps quelle que soit la vitesse à laquelle la tâche est terminée ... par exemple 1 seconde + temps de tâche, de cette façon la barre de défilement/progression reste au moins visible pendant un certain temps.
Je crois qu'une solution légèrement meilleure consiste à ajouter le délai fixe uniquement lorsque le temps pris a déjà dépassé 1 seconde provoquant l'affichage du spinner ou de la barre de progression. De cette façon, si le délai est ajouté, il est proportionnellement beaucoup moins important que le temps que l'utilisateur doit déjà attendre.