3/27/2023 0 Comments Be quick menu![]() ![]() ![]() ![]() One could still give less conspicuous progress feedback. Note added for the web version of this essay: Most web browsers fail in providing useful progress bars, since they don't communicate what percentage of the entire download for a page has been completed.įor reasonably fast operations, taking between 2 and 10 seconds, a true percent-done indicator may be overkill and, in fact, putting one up would violate the principle of display inertia (flashing changes on the screen so rapidly that the user cannot keep pace or feels stressed). If this is not possible either, a last resort would be to use a less specific progress indicator in the form of a spinning ball, a busy bee flying over the screen, dots printed on a status line, or any such mechanism that at least indicates that the system is working, even if it does not indicate what it is doing. For example, a system searching an unknown number of remote databases could print the name of each database as it is processed. 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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |