This latter advantage should not be underestimated and is one reason for recommending a graphic progress bar instead of just stating the expected remaining time in numbers.įor operations where it is unknown in advance how much work has to be done, it may not be possible to use a percent-done indicator, but it is still possible to provide running progress feedback in terms of the absolute amount of work done. Progress indicators have three main advantages: They reassure the user that the system has not crashed but is working on his or her problem they indicate approximately how long the user can be expected to wait, thus allowing the user to do other activities during long waits and they finally provide something for the user to look at, thus making the wait less painful.
As a rule of thumb, percent-done progress indicators should be used for operations taking more than about 10 seconds. In cases where the computer cannot provide fairly immediate response, continuous feedback should be provided to the user in form of a percent-done indicator. The fact that computers can be too fast indicates the need for user-interface changes, like animations, to be timed according to a real-time clock rather than being timed as an indirect effect of the computer's execution speed: Even if a faster model computer is substituted, the user interface should stay usable. For example, a scrolling list may move so fast that the user cannot stop it in time for the desired element to remain within the available window. Normally, response times should be as fast as possible, but it is also possible for the computer to react so fast that the user cannot keep up with the feedback. 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. 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. 10 seconds is about the limit for keeping the user's attention focused on the dialogue.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. 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.
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.The basic advice regarding response times has been about the same for thirty years :
Excerpt from Chapter 5 in my book Usability Engineering, from 1993:
0 kommentar(er)
