Sur l'ajout de faux délais, à, des retards réseau
Considérez une application, où il y a une fonction (peut-être un bouton, ou, lorsque vous appuyez sur Retour pour envoyer du texte, par exemple).
Il en résulte une connexion réseau et il y aura un petit retard pendant la connexion.
Pendant le retard, il y aura un spinner (ou un autre indicateur) indiquant que la connexion réseau "se produit" ...
... en effet cet indicateur vous montre que quelque chose "s'est réellement passé".
En ce qui concerne ce spinner apparaissant lors de la connexion réseau: de nos jours, il est souvent à peu près instantané, vous voyez à peine le spinner ou peut-être même ne le voyez pas.
Pensée: en fait, faites délibérément un temps minimum pour que le spinner apparaisse (disons, 1/3 seconde). C'est-à-dire que même si la connexion est quasi-instantanée, ajoutez un "faux délai" (peut-être 1/3 de seconde).
De cette façon, comme il est dit ci-dessus, l'utilisateur sait définitivement que quelque chose s'est produit.
Bonne idée? Mauvaise idée? Déjà utilisé?
- radicalement simplifié la question ici
Mes 2 cents:
Du point de vue d'un développeur, c'est "tout simplement stupide",
Mais comme décision commerciale, c'est "Genius!".
Considérez cette situation hypothétique:
Vous allez chez une diseuse de bonne aventure,
Demandez: "Quand vais-je mourir?"
Il répond instantanément: "5 juin 2049"
Pas de boule de cristal, pas de bourdonnement, quoi que ce soit ...
? qu'en pensez-vous ?
Exemple d'une instance de retard intentionnel:
Je connais un produit commercial (que j'ai écrit) qui a introduit un faux délai, même aussi longtemps que 5 [sec]. et je vais vous expliquer:
Le produit que j'écrivais était un outil d'ingénierie conçu comme un module complémentaire pour un logiciel de création de diagrammes bien connu largement utilisé dans l'industrie,
Mais il était vaste et ajoutait beaucoup de fonctionnalités qui "pouvaient" vivre seules ...
lorsque vous démarrez l'add-on, vous pouviez à peine voir que vous étiez hors du logiciel de création de diagrammes et dans mon produit: la conception suivait le même schéma et le temps de chargement était quelque peu instantané.
Notre équipe voulait s'assurer que l'utilisateur sait où est "notre contribution" à son travail, et non le logiciel "parent"!
Alors ... Nous avons présenté "The Splash Screen":
Qui était Nice, contenant le nom du produit, le nom de l'entreprise et la version du produit.
Mais ... Le Splash-Screen apparaissait très brièvement, nous avons donc introduit un retard sur le Splash-Screen, une barre de progression parfaite, et plus tard, quelques conseils sur l'utilisation de l'outil.
Note sur votre implémentation:
Quoi qu'il en soit, je vous suggère d'exécuter d'abord l'opération, et ensuite seulement (si nécessaire) d'introduire le retard ... et non l'inverse, encore plus, si l'opération échoue, abandonnez le délai et laissez l'utilisateur le sait tout de suite.
Note2:
Au lieu d'une note modale indiquant "l'opération s'est terminée avec succès! [OK]".
vous pouvez utiliser un cadre d'alerte tel que "l'e-mail de G-Mail envoyé avec succès! [X - ignorer]".
Mais bien sûr, chaque cas a ses propres considérations.
Avez-vous vu cela dans des applications de production? (C'est-à-dire, je suppose que vous auriez fait partie de l'équipe de développement - comme vous ne le sauriez pas nécessairement, je suppose, en tant qu'utilisateur!)
Oui, je pense que la plupart d'entre nous l'ont probablement fait aussi parce qu'ils aiment voir leur petit chargeur intelligent ... mais ensuite continuer. Un chargeur ne doit être utilisé par IMO que lorsque quelque chose prend plus longtemps que prévu. Disons qu'après 300 ms, aucune réponse n'a été notée, que l'on devrait montrer le spinner.
Cela a-t-il déjà été abordé dans la littérature? (Je n'ai rien trouvé.) At-il déjà un nom sympa?
Je ne suppose pas que quiconque ait donné un nom officiel à faire que , cependant, ce dont on a parlé, c'est que l'utilisateur a besoin de commentaires sur son action. C'est une heuristique pour l'utilisabilité. Cependant, il existe de meilleures façons de dire à l'utilisateur quel est l'état réel du système. Pour votre transaction commerciale, je supprimerais simplement le bouton et mettrais une étiquette affichant "transaction acceptée" ... ou quelque chose, peut-être même le griser ... de toute façon, ne laissez pas le bouton tel quel. J'ai eu une fois le même problème concernant une page de configuration, quand on clique sur le bouton, rien ne se passait ... alors j'ai simplement activé le bouton dès que quelque chose avait changé dans le formulaire de paramètres et après avoir appuyé sur le bouton, j'ai simplement désactivé le bouton à nouveau.
La forme la plus élémentaire de rétroaction est bien sûr le bouton différent indique lui-même:
- sur presse: changer de couleur (par exemple bleu)
- à la sortie: changer la couleur de retour à la couleur régulière (par exemple gris)
- en survol: changez la couleur en quelque chose entre les deux (par exemple bleu clair)
À défaut, et surtout, quelle est l'opinion de vous tous ici
... Je n'aime pas vraiment les opinions autant que les faits, cependant, cela semble une mauvaise pratique de le faire. Si vous voulez vraiment qu'un utilisateur attendez et n'aillez nulle part ailleurs, il vaut mieux simplement superposer tout l'écran et y placer un gros spinner jusqu'à ce que cette étape de blocage soit terminée ... cependant, si la transaction est presque instantanée (par exemple <300 ms) ... ne le faites pas, vous ennuierez et confondrez plus que vous n'aiderez votre cas.
Bonne idée, en effet.
L'idée d'un Spinner est de faire savoir à l'utilisateur qu'il se passe quelque chose en arrière-plan, il devra donc attendre qu'il soit terminé.
En particulier dans le cas d'une connexion réseau, les Spinners ont été nécessaires car la réception du réseau ainsi que la vitesse ne peuvent pas être déterminées et sont sujettes à changement. Les réseaux ont également des temps d'arrêt.
Cependant, le problème avec les filateurs est que les développeurs en placent généralement un au centre de l'écran au premier plan et atténuent le contenu sur l'écran lui-même. C'est contre-productif si l'utilisateur souhaite modifier quelque chose entre les deux et que le réseau est lent.
Une bonne façon de le faire est de permettre au spinner d'être sur le côté droit du bouton que vous venez d'appuyer, de taille plus petite que le bouton et il commence à tourner tandis que le bouton reste décoloré, pour éviter le transfert de données en double.
Si la connexion réseau réussit et que les données sont transférées + qu'une opération est effectuée, le spinner s'anime en une vérification.
Sinon, en croix.
De cette façon, il devient plus facile de savoir quand l'opération a réussi et quand elle n'a pas éliminé également les doublons.
À mon avis, dès que l'utilisateur fait une action, il attend une réponse. Autrement dit, l'application l'informant que son action a été traitée. Une image de chargement pendant 3-4 secondes donnera à l'utilisateur une idée claire que son entrée a été reçue et travaillée. Maintenant, si la connexion utilisateur est super rapide et que le chargement du spinner apparaît à l'écran pendant une demi-seconde, puis disparaît. Cela provoquera un scintillement, qui sera distrayant (ou disons dérangeant) plutôt qu'informatif. Mais en même temps, l'application doit informer l'utilisateur de son action. Pour ce faire, l'application doit lui donner des indications visuelles, quelque chose comme passer à la forme suivante en effet glissant. Un autre pourrait être les entrées/boutons sur lesquels l'utilisateur a pris des mesures pour lisser le fondu et les données sont présentées à l'utilisateur. Ces indications visuelles doivent être plus intuitives que de simplement afficher/masquer le gif de chargement pendant 0,2 seconde que les yeux de l'utilisateur ne peuvent pas identifier.
Le spinner, les barres de chargement ou d'autres modèles de conception de ce type sont utilisés pour fournir une rétroaction à l'utilisateur lorsqu'un système ne peut pas répondre suffisamment rapidement pour fournir la rétroaction nécessaire à l'action de l'utilisateur. Si le système peut répondre assez rapidement, cela fournirait la rétroaction nécessaire et vous n'avez pas besoin d'un spinner. Dans ce cas, il n'y a aucune raison de retarder délibérément l'achèvement des tâches de l'utilisateur simplement pour retarder l'achèvement des tâches d'un utilisateur.
Je n'aime pas charger les indicateurs. L'utilisateur peut supposer que quelque chose est cassé.
Cependant, plusieurs fois, si l'utilisateur est informé, il peut être plus patient.
Je pense que c'est une bonne idée de donner aux utilisateurs quelque chose à faire, à lire en ce moment. La plupart des sites ont pris ce temps d'attente pour mettre en évidence quelque chose.
Il existe de nombreuses preuves d'interactions pour donner un retour aux utilisateurs. Tout comme chaque fois que vous minimisez une fenêtre sur votre PC, etc. ce sont toutes des animations qui décrivent l'action en cours mais elles ne sont pas nécessaires du point de vue informatique. Une alternative au forçage d'un spinner dans une situation inutile consiste à faire apparaître un message de "réussite" afin que les utilisateurs sachent que l'action effectuée a été effectuée. Vous pouvez faire disparaître cet ensemble après quelques secondes ou avoir la possibilité pour les utilisateurs de le fermer.
Une note de prudence: soyez prudent lorsque vous commencez à faire des suppositions sur ce que vous pouvez et ne pouvez pas mentir aux utilisateurs, par exemple UBER récemment en train de se faire prendre pour avoir de fausses voitures sur ses cartes. Il y a une très bonne publication sur la tromperie dans la conception d'interaction récemment publiée que vous pouvez voir ici: http://www.cond.org/benevolent.html (il y a un petit lien vers le pdf de la page)
Donc, j'évoque le spinner, et j'attends simplement, oh, 0,6, 0,65, disons, et seulement ensuite, j'appelle réellement 1 pour la connexion - ce qui, en effet, ne prend généralement presque pas de temps.
À quoi ça sert? Vous ne mentionnez même aucune raison (sauf si je l'ai manquée), ce qui me fait supposer que vous le faites parce que l'appel de connexion peut être très rapide.
Contrairement à l'exemple coinstar lié ci-dessus, 99,99% de vos utilisateurs n'auront pas d'opinion forte sur la vitesse à laquelle les connexions à la base de données devraient prendre (même plus lorsqu'ils ne savent même pas où sont les serveurs). Ainsi, votre retard artificiel n'ajoute rien de plus que plus de temps à votre utilisateur pour développer des sentiments de gêne à devoir attendre.
Alors, faites ce que vous devez faire pour montrer que quelque chose se passe qui est si important, il interdit d'autres actions. Estompez l'arrière-plan, placez un .gif ou autre chose - mais ne le prolongez pas au-delà du temps nécessaire.
Si vous utilisiez un service, en particulier celui que vous deviez utiliser FRÉQUEMMENT, à quoi seriez-vous plus ennuyé:
- Avoir à attendre 0,8 seconde à chaque redémarrage de l'application mais voir une belle animation,
ou:
- Avoir à attendre 0,2 seconde à chaque redémarrage de l'application et ne voir qu'un aperçu d'une animation
Pour moi, cette question semble si évidente (pour ne pas être impolie !!), que j'ai l'impression de manquer une grande information sur la raison pour laquelle vous envisagez votre itinéraire actuel.
Pour en savoir plus: http://www.nngroup.com/articles/progress-indicators/
L'idée derrière un spinner, une barre de progression, etc. est d'ajouter l'élément tournant à votre thread d'exécution afin que lorsque l'opération démarre, le spinner s'affiche et lorsqu'il se termine, le spinner disparaît. La façon dont vous le faites semble erronée, car vous n'attachez pas votre spinner à l'action elle-même et, par conséquent, vous y ajoutez un retard inutile.
Cela dit, cela a plus à voir avec l'implémentation qu'avec l'UX.