¿Con qué frecuencia necesita sondear los botones de la IU antes de que se perciban como lentos?

8

Si bien es posible, y a veces deseable, utilizar interrupciones de cambio de pin para leer el estado de los botones, es más sencillo sondear el estado de los botones loop(). Esta es una técnica de uso común.

Si loop()ejecuta lo suficientemente rápido, siempre se presionará el botón y el usuario no podrá percibir ningún retraso o retraso.

Es posible que su ciclo demore tanto como para causar que se perciba un retraso o retraso.

La pregunta es, ¿cuánto tiempo pasaría, en general, antes de que un usuario vea esto?

button ui

— Cybergibbons
fuente

2

Si loop()es bastante lento (quiero decir, demasiado lento para poder dar retroalimentación lo suficientemente rápida al usuario final), posiblemente podría usar un ISR en el cambio de nivel de pin y proporcionar retroalimentación inmediata (si esto puede calcularse rápidamente) al usuario , o darle comentarios temporales (por ejemplo, LED encendido) para decirle que su solicitud ha sido reconocida y se procesará en breve (en loop()); permitiría loop()establecer alguna boolvariable global en el ISR.

— jfpoilpret

1

Probablemente sea una de las pocas veces en que hacer clic con la tecla es útil.

— Cybergibbons

14

La respuesta corta es que tiene 100 milisegundos para responder al usuario si desea que sienta que la acción se produjo instantáneamente.

Según Jacob Nielsen en su libro Ingeniería de usabilidad , de 1993, que se considera una referencia importante en la usabilidad de sistemas y la experiencia del usuario:

0.1 segundos es aproximadamente el límite para que el usuario sienta que el sistema está reaccionando instantáneamente, lo que significa que no es necesaria una retroalimentación especial, excepto para mostrar el resultado.

También menciona que este consejo básico con respecto a los tiempos de respuesta ha sido casi el mismo durante muchas décadas [Miller 1968; Card y col. 1991].

He tomado esta cita de este artículo: Tiempos de respuesta: los 3 límites importantes , también escrito por Jacob Nielsen.

Tenga en cuenta que en este tiempo debe incluir todo el tiempo necesario para leer el botón y presionar y dar su opinión al usuario.

Otros umbrales de tiempo de respuesta que son importantes para la experiencia del usuario, de la misma fuente, pero que no fueron mencionados directamente por el OP son:

1.0 segundo es aproximadamente el límite para que el flujo de pensamiento del usuario permanezca ininterrumpido, aunque el usuario notará el retraso. Normalmente, no es necesaria una retroalimentación especial durante demoras de más de 0.1 pero menos de 1.0 segundo, pero el usuario pierde la sensación de operar directamente sobre los datos.

10 segundos es el límite para mantener la atención del usuario centrada en el diálogo. Para retrasos más largos, los usuarios querrán realizar otras tareas mientras esperan que la computadora termine, por lo que se les debe dar retroalimentación que indique cuándo la computadora espera que se haga. La retroalimentación durante el retraso es especialmente importante si es probable que el tiempo de respuesta sea muy variable, ya que los usuarios no sabrán qué esperar.

— Ricardo
fuente

1

Brillante respuesta. Gracias por la información adicional, también es útil.

— Cybergibbons

3

Se sabe comúnmente que las personas no pueden percibir los cambios cuando suceden por debajo de 10 ms después de su acción. Esta capacidad de respuesta dará como resultado una experiencia que recientemente se ha descrito principalmente como "ágil". Es notable, pero para los usuarios es difícil ponerle un nombre.

Entonces, si quieres la perfección, tómate unos 15 ms de retraso. Si quieres realmente bien, tómate 100 ms de retraso. 100ms son 50ms en promedio, y ciertamente pasarán por las personas.

La aplicación y el tiempo de respuesta esperado también son vitales. Una puerta corredera o elevador tiene una tolerancia muy grande (ya que el objeto físico siempre tomará mucho más tiempo) mientras que las interfaces de la máquina expendedora de boletos no se dan en ningún momento.

El límite superior para la votación sería de alrededor de 1500 ms. Por allí la gente siempre notará que es lento.

Estos datos son una experiencia puramente personal como jugador y programador. YMMV y recuerde que probarlo usted mismo es la mejor manera de descubrir cómo se siente. La única respuesta "científica" es <10 milisegundos, más allá de eso se trata de la capacidad de percibir el retraso (que varía según la persona y el momento) y la tolerancia del usuario.

Como nota al margen, puede intentar fluctuar los retrasos para ahorrar tiempo de batería o CPU cuando no se utiliza la interfaz. La acción del usuario, más rápido es el sondeo. Cuando la aplicación está funcionando, sondea muy lentamente. ¡Es mejor sondear cuando importa!

— Lodewijk
fuente