À quel moment une application doit-elle changer le curseur en sablier ou afficher une barre de progression?
Notre WPF application de bureau exécutera diverses tâches. En général, la durée moyenne de chaque tâche va de pratiquement instantanée à quelques secondes ou plus (éventuellement des minutes).
Nous essayons d'établir une norme pour déterminer quand changer le curseur en un sablier pour indiquer le traitement et pour les tâches plus longues afficher une barre de progression dans l'interface.
Où sont ces seuils en quelques secondes? À quel moment un utilisateur pense-t-il que rien ne se passe-t-il et commence-t-il à être frustré qu'aucun progrès ne soit signalé (ce que nous voulons éviter)?
Rappelles toi 0.1, 1.0, et 10 secondes ...
Vous avez environ 1 seconde pour montrer quelque chose que ce soit le résultat final ou un indicateur que l'ordinateur fonctionne (généralement un certain type de spinner)
Ne rien faire pendant 1 seconde entière après le lancement d'une action par un utilisateur peut encore ralentir une application (comme indiqué dans les commentaires ci-dessous), j'aime donc fournir une rétroaction immédiate à mes utilisateurs en montrant immédiatement le spinner tout en le fondant lentement.
Démo d'un spinner qui s'estompe
Les Spinners ne fonctionnent que pendant si longtemps, cependant, et toute opération qui pourrait prendre plus de 10 secondes devrait avoir un mécanisme plus avancé pour faire savoir à l'utilisateur quand la tâche qu'il a lancée sera terminée (comme une barre de progression)
Voici les données qui soutiennent cela ...
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]:
- 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 concerne la limite pour que le flux de pensée de l'utilisateur reste ininterrompu, 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 maintenir 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.
source: Neilson Norman Group
La réponse de DaveAlger semble couvrir à peu près la question, mais je dirais que si un processus est câblé pour afficher une barre de progression, vous pourriez aussi bien l'afficher immédiatement dans tous les cas.
Un sablier dit "quelque chose prend beaucoup de temps alors que nous ne nous y attendions pas". Une barre de progression - même la fausse barre de barbier - indique "cela prend un certain temps, mais nous savions que cela pourrait arriver". Si la barre de progression disparaît après une demi-seconde, c'est bien sûr encore mieux.
1 seconde, c'est long au travail. 400 ms pourrait être mieux. plus longtemps que cela est souvent identifié comme "lent" et remet en question la performance. L'une des applications sur lesquelles j'ai travaillé il y a environ 20 ans attendait des données transactionnelles d'un serveur qui mettaient généralement 15 à 25 secondes pour arriver dans des cas extrêmes (ligne à plusieurs gouttes à 9600 b/s). Sur la fenêtre concernée, le programmeur n'a pas du tout posé le sablier (c'était un cadran animé). Nous avons constaté que pour les transactions plus longues, certains des utilisateurs étaient redémarrage après avoir attendu 10 secondes car ils supposaient que le PC était bloqué. Le mettre en place instantanément a considérablement réduit l'angoisse de l'utilisateur.
Cela ne pourrait-il pas être un choix plus simple?
Un sablier tournant ou tournant, comme vous le dites, pour des opérations où la durée de l'opération n'est pas définie par des facteurs hors de votre contrôle, la latence du réseau, etc.
Une barre de progression pour une opération définie, c'est-à-dire que nous savons que nous devons lire 480 enregistrements dans une base de données et que nous pouvons facilement les convertir en pourcentage de lecture.
Les filateurs sont un peu plus laineux et j'hésiterais à recommander leur utilisation sans fournir de rétroaction pour une rétroaction de fonctionnement longue et la possibilité d'annuler si cela prend plus de temps que prévu.
Tout est relatif. S'il s'agit d'une application de base de données avec des millions d'enregistrements, un utilisateur aura (devrait) avoir une attente différente.
Mon approche consiste pour tout ce qui peut prendre plus de 1 seconde à afficher un sablier APRÈS 1 seconde. J'aime réduire l'encombrement visuel.
Si c'est une tâche qui peut prendre plus de 10 secondes et que vous pouvez afficher la progression réelle (par exemple 50%), montrez-leur une véritable barre de progression.
Il y a des conditions de recherche qui, je le sais, vont être difficiles (longues) et je préviens l'utilisateur que ce sera une recherche plus longue.
Si c'est une tâche qui peut prendre plus de 10 secondes, donnez-leur une chance d'annuler. Ils ont peut-être mal saisi la recherche et cela prend beaucoup de temps à cause d'une recherche étrange. S'il est probable que cela prenne plus de 10 secondes et qu'il n'y ait pas d'option pour annuler, donnez-leur un avertissement.
Donnez à l'utilisateur l'option d'annuler automatiquement après X secondes. Dans ma candidature, si la recherche va être difficile, ils viendront souvent d'une autre direction.
Pouvez-vous diviser la tâche pour retourner d'abord un décompte. Comme si j'avais des opérations en bloc et que je retournerais d'abord un nombre et si c'est> 1000, je dis à l'utilisateur que vous êtes sûr de vouloir traiter les enregistrements X? Cela va prendre du temps. Dans une démo, j'ai vu une personne gâcher et créer un flux de travail pour l'ensemble de la bibliothèque de plus de 1000000 enregistrements et cela s'est terminé en 10 minutes, ce qui est rapide pour autant d'enregistrements, mais cela ressemblait à une heure pendant la démo.
J'ai une opération commune qui prend 2-3 secondes à chaque fois. Pour cela, je n'affiche pas un sablier.