9

Whilst it is possible, and sometimes desirable, to use pin change interrupts to read the state of buttons, it is simpler to poll the state of buttons in loop(). This is a commonly used technique.

If you loop() executes quickly enough, then button presses are always going to be caught and the user will not be able to perceive any delay or lag.

It is possible that your loop would take so long as to cause a delay or lag to be perceived.

The question is, how long would it be, in general, before a user would see this?

Cybergibbons
  • 5,420
  • 7
  • 34
  • 51

2 Answers2

14

The short answer is that you have 100 miliseconds to respond to the user if you want them to feel the action occurred instantaneously.

According to Jacob Nielsen in his book Usability Engineering, from 1993, which is considered an important reference in Systems Usability and User Experience:

  • 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

He also mentions that this basic advice regarding response times has been about the same for many decades [Miller 1968; Card et al. 1991].

I've taken this citation from this article: Response Times: The 3 Important Limits, also writen by Jacob Nielsen.

Note that in this time you must include all time taken to read the button press and give feedback to the user.

Other response time thresholds that are important for user experience, from the same source, but that were not mentioned directly by the OP are:

  • 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

  • 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

Community
  • 1
Ricardo
  • 3,390
  • 2
  • 26
  • 55
3

It's commonly known that people are unable to perceive changes when they happen underneath 10ms after their action. This responsiveness will result in an experience that has recently mostly been described as "snappy". It's noticeable but for users it's hard to put a name on it.

So if you want perfection, take about 15ms of delay. If you want really good, take 100 ms of delay. 100ms is 50ms on average, and will certainly pass for people.

The application and the expected response time is vital too. A sliding door or elevator is given very large tolerance (as the physical object will always take a lot more time) whereas ticket vending machine interfaces are not given any time at all.

The upper limit for polling would be around 1500ms. Around there people will always notice it is slow.

This data is purely personal experience as a gamer and programmer. YMMV and remember that just trying it yourself is the best way to find out how it feels. The only "scientific" answer is the <10 milliseconds, beyond that it's about the ability to perceive the delay (which varies per person and moment) and the tolerance of the user.

As a side note, you can try fluctuating the delays in order to conserve battery or CPU time when the interface is not being used. The user-action, the faster the polling. When the application is doing it's thing, poll very slowly. Better to poll when it matters!

Lodewijk
  • 131
  • 2