Our WPF desktop application will be executing various tasks. In general, the average length of time for each task will range from basically instant to a few seconds or longer (possibly minutes).
We are trying to establish a standard to determine when to change the cursor to an hourglass to indicate processing and for longer tasks display a progress bar in the interface.
Where are these thresholds in seconds? At what point does a user think nothing is happening and start to become frustrated that no progress is reported (which is what we want to avoid)?
Answer
Remember 0.1
, 1.0
, and 10
seconds...
You have about 1 second to show something whether that be the finished result or an indicator that the computer is working (usually some type of spinner)
Not doing anything for 1 whole second after a user initiates an action can still make an application feel sluggish (as noted in the comments below) so I like to provide immediate feedback to my users by showing the spinner right away while fading it in slowly.
Spinners only work for so long, however, and any operation that could take over 10 seconds should have a more advanced mechanism for letting the user know when the task they initiated will be completed (such as a progress bar)
Here's the data backing this up...
The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]:
- 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.
- 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.
source: Neilson Norman Group
No comments:
Post a Comment