Con quale frequenza devi eseguire il polling dei pulsanti dell'interfaccia utente prima che vengano percepiti come ritardati?

Sebbene sia possibile, e talvolta desiderabile, utilizzare gli interruttori di cambio pin per leggere lo stato dei pulsanti, è più semplice eseguire il polling dello stato dei pulsanti loop(). Questa è una tecnica comunemente usata.

Se loop()esegui abbastanza rapidamente, le pressioni dei pulsanti saranno sempre catturate e l'utente non sarà in grado di percepire alcun ritardo o ritardo.

È possibile che il tuo loop impieghi così tanto tempo da causare un ritardo o un ritardo da percepire.

La domanda è: quanto tempo sarebbe, in generale, prima che un utente lo veda?

La risposta breve è che hai 100 millisecondi per rispondere all'utente se vuoi che sentano l'azione avvenire istantaneamente.

Secondo Jacob Nielsen nel suo libro Usability Engineering , dal 1993, che è considerato un riferimento importante nell'usabilità dei sistemi e nell'esperienza utente:

• 0,1 secondi riguarda il limite per far sentire all'utente che il sistema sta reagendo istantaneamente, il che significa che non è necessario alcun feedback speciale se non per visualizzare il risultato.

Cita anche che questo consiglio di base sui tempi di risposta è stato lo stesso per molti decenni [Miller 1968; Card et al. 1991].

Ho preso questa citazione da questo articolo: Response Times: The 3 Important Limits , scritto anche da Jacob Nielsen.

Si noti che in questo momento è necessario includere tutto il tempo impiegato per leggere il pulsante premuto e fornire feedback all'utente.

Altre soglie dei tempi di risposta che sono importanti per l'esperienza dell'utente, dalla stessa fonte, ma che non sono state menzionate direttamente dall'OP sono:

• 1,0 secondi riguarda il limite del flusso di pensiero dell'utente per rimanere ininterrotto, anche se l'utente noterà il ritardo. Normalmente, non sono necessari feedback speciali durante ritardi superiori a 0,1 ma inferiori a 1,0 secondi, ma l'utente perde la sensazione di operare direttamente sui dati.

• 10 secondi è circa il limite per mantenere l'attenzione dell'utente focalizzata sul dialogo. Per ritardi più lunghi, gli utenti vorranno eseguire altre attività in attesa che il computer finisca, quindi dovrebbero ricevere feedback che indicano quando il computer prevede di essere fatto. Il feedback durante il ritardo è particolarmente importante se è probabile che il tempo di risposta sia molto variabile, poiché gli utenti non sapranno cosa aspettarsi.

È noto che le persone non sono in grado di percepire i cambiamenti quando si verificano al di sotto di 10 ms dopo la loro azione. Questa reattività si tradurrà in un'esperienza che è stata recentemente descritta principalmente come "scattante". È evidente ma per gli utenti è difficile assegnargli un nome.

Quindi, se vuoi la perfezione, prenditi circa 15ms di ritardo. Se vuoi davvero bene, prendi 100 ms di ritardo. 100ms è in media 50ms e passerà sicuramente per le persone.

Anche l'applicazione e i tempi di risposta previsti sono fondamentali. A una porta scorrevole o all'ascensore viene data una tolleranza molto grande (poiché l'oggetto fisico richiederà sempre molto più tempo) mentre le interfacce dei distributori automatici di biglietti non vengono date affatto.

Il limite superiore per il polling sarebbe di circa 1500ms. Da queste parti la gente noterà sempre che è lento.

Questi dati sono un'esperienza puramente personale come giocatore e programmatore. YMMV e ricorda che provarlo tu stesso è il modo migliore per scoprire come ci si sente. L'unica risposta "scientifica" è <10 millisecondi, oltre alla capacità di percepire il ritardo (che varia per persona e momento) e la tolleranza dell'utente.

Come nota a margine, puoi provare a fluttuare i ritardi per risparmiare tempo della batteria o della CPU quando l'interfaccia non viene utilizzata. L'azione dell'utente, più veloce è il polling. Quando l'applicazione sta eseguendo le operazioni, eseguire il polling molto lentamente. Meglio fare il polling quando conta!