À quelle fréquence devez-vous interroger les boutons de l'interface utilisateur avant qu'ils ne soient perçus comme décalés?

8

Bien qu'il soit possible, et parfois souhaitable, d'utiliser des interruptions de changement de broche pour lire l'état des boutons, il est plus simple d'interroger l'état des boutons dans loop(). Il s'agit d'une technique couramment utilisée.

Si vous loop()exécutez assez rapidement, alors les pressions sur les boutons seront toujours prises et l'utilisateur ne pourra percevoir aucun retard ou retard.

Il est possible que votre boucle prenne autant de temps qu’à percevoir un retard ou un décalage.

La question est, combien de temps cela prendrait-il, en général, avant qu'un utilisateur ne le voit?

button ui

— Cybergibbons
source

2

Si vous êtes loop()plutôt lent (je veux dire, trop lent pour pouvoir donner suffisamment de rétroaction à l'utilisateur final), vous pouvez éventuellement utiliser un ISR sur le changement de niveau de broche et fournir une rétroaction immédiate (si cela peut être calculé rapidement) à l'utilisateur , ou lui donner un retour temporaire (par exemple LED allumée) pour lui dire que sa demande a été reconnue et sera traitée sous peu (en loop()); vous laisseriez loop()en définissant une boolvariable globale dans l'ISR.

— jfpoilpret

1

C'est probablement l'une des rares fois où le clic sur la touche est utile.

— Cybergibbons

14

La réponse courte est que vous disposez de 100 millisecondes pour répondre à l'utilisateur si vous souhaitez qu'il ressente que l'action s'est produite instantanément.

Selon Jacob Nielsen dans son livre Ergonomie Engineering , de 1993, qui est considéré comme une référence importante dans la convivialité des systèmes et l'expérience utilisateur:

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.

Il mentionne également que ces conseils de base concernant les temps de réponse sont à peu près les mêmes depuis de nombreuses décennies [Miller 1968; Card et al. 1991].

J'ai pris cette citation de cet article: Temps de réponse: les 3 limites importantes , également écrit par Jacob Nielsen.

Notez que pendant ce temps, vous devez inclure tout le temps nécessaire pour lire la pression sur le bouton et donner des commentaires à l'utilisateur.

D'autres seuils de temps de réponse importants pour l'expérience utilisateur, provenant de la même source, mais qui n'ont pas été mentionnés directement par l'OP sont:

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, aucun retour spécial n'est nécessaire pendant des 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, c'est la limite pour que l'attention de l'utilisateur reste 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.

— Ricardo
source

1

Réponse brillante. Merci pour l'info supplémentaire, c'est aussi utile.

— Cybergibbons

3

Il est communément connu que les gens sont incapables de percevoir les changements lorsqu'ils surviennent sous 10 ms après leur action. Cette réactivité se traduira par une expérience qui a récemment été principalement décrite comme "accrocheuse". C'est perceptible, mais pour les utilisateurs, il est difficile de mettre un nom dessus.

Donc, si vous voulez la perfection, prenez environ 15 ms de retard. Si vous voulez vraiment bien, prenez 100 ms de retard. 100 ms est 50 ms en moyenne, et passera certainement pour les gens.

L'application et le temps de réponse attendu sont également essentiels. Une porte coulissante ou un ascenseur reçoit une très grande tolérance (car l'objet physique prendra toujours beaucoup plus de temps) tandis que les interfaces des distributeurs automatiques de billets ne sont pas données du tout.

La limite supérieure pour l'interrogation serait d'environ 1500 ms. Là-bas, les gens remarqueront toujours que c'est lent.

Ces données sont une expérience purement personnelle en tant que joueur et programmeur. YMMV et rappelez-vous que l'essayer vous-même est la meilleure façon de savoir comment il se sent. La seule réponse «scientifique» est la <10 millisecondes, au-delà de la capacité à percevoir le retard (qui varie selon la personne et le moment) et la tolérance de l'utilisateur.

En remarque, vous pouvez essayer de faire varier les délais afin d'économiser la batterie ou le temps CPU lorsque l'interface n'est pas utilisée. L'action de l'utilisateur, plus le sondage est rapide. Lorsque l'application est en train de faire son travail, sondez très lentement. Mieux vaut sonder quand c'est important!

— Lodewijk
source