|Waiting at the Computer: Busy Indicators and System Feedback – Part 1|
|Waiting at the Computer: Busy Indicators and System Feedback – Part 3|
|The Three Pillars of Human Performance at the Computer – Which One Fits Best?|
|Performance – Merely a Technical Problem?|
|What Matters Most?|
|Golden Rules for Bad User Interfaces|
By Gerd Waloszek, SAP AG, SAP User Experience – Updated: July 29, 2009
In this series of three articles, I would like to discuss the following issue: Given that users have to wait at the computer, what can developers and designers do to make the waiting more tolerable? In the first article, I discussed time ranges that are relevant for human users at the computer and illustrated them with a book store analogy that was encased in a use case format. I also briefly introduced several types of feedback that can be given to users to indicate that they will have to wait for the computer. In my second article, I will discuss these types of feedback in more detail and give some recommendations for their use. The third and final article will be dedicated to the important questions of (1) under what conditions and (2) at what point in time the different types of feedback should be used.
As already stated in my first article, immediate feedback assures users that a command has been acknowledged, a mouse-move or drag is going into the right direction, a key press has been registered, and so on. It can be provided in many ways, such as by changing the color, the shading (see figure 1), or the look of the screen element that the user interacts with.
Figure 1: Changing the shading of a button in order to show that a button has been clicked
In the case of menus, an animation effect – such as the opening or closing of the menu – shows that the direct-manipulation action (not the menu command!) has been acknowledged. Similarly, for mouse drags, either the screen element itself or a simplified representation of it – such as a rectangular frame – is moved. The latter effect should be used if the object itself cannot be moved in a timely manner. "Hover" effects are a special case. Rather than indicating that an action has been acknowledged, they indicate an available option. For example, a hover effect over a button or link indicates that this screen element can be clicked (see figure 2, center).
Figure 2: Three variants of a button in a Web application – not pressed, hover, pressed
Immediate feedback needs to be given within 0.1 seconds in order to maintain the cause-effect relationship that is necessary for direct-manipulation operations. If this does not happen, users may be tempted to repeat their action. For example, they may click a link or button a second time and run into confusing situations, such as opening a window twice or starting two identical searches. For move operations, this time limit of 0.1 seconds ensures that users perceive a smooth animation.
In principle, immediate feedback is more of a design issue than a responsiveness one. Buttons, links, icons, menus, and other screen elements need to indicate that the user has interacted with them. Firstly, therefore, a feedback feature must be included in the design of the screen elements. Secondly, the feedback feature must be designed properly. As Jeff Johnson remarks, delayed acknowledgement of user actions is almost as bad as no acknowledgement at all. In such cases, we definitely have a responsiveness issue as well. I agree with Jeff Johnson when he states: "Given the speed of today's computers, there is no excuse for GUI components that can't acknowledge user input within 0.1 seconds."
In my opinion, it is not a good idea to send busy indicators if immediate feedback cannot be given timely (although Jeff Johnson (2007) lists this as an option for developers) as this only confuses users even more. For example, I would not recommend sending a wait cursor if a dropdown list does not open even after 1 second (it should open within 0.1 seconds). The reason for such a delayed response might be that the application needs a server roundtrip to fill the list with content. The real issue here is that that the list content should be available locally in order to ensure a timely response.
Let us now turn to a different type of feedback – one that does just the opposite of immediate feedback. Instead of telling the user that the system is catching up and responsive, this feedback tells the user that the system cannot keep up, that it has become unresponsive, and that the user will have to wait for the computer's response. It may also assure the user that the system is still working and is not hanging. In its most advanced form, it can also tell the user the reason for the delay and its expected duration. I will use the term "busy feedback" for all variants of this kind of system feedback and distinguish between the following types:
In the following, I will discuss these types of busy feedback in more detail.
At the dialog level, that is, in a time range of up to a maximum of two seconds, the user and the system take turns. At this level, users are deeply engaged in the ongoing man-machine dialog and any delay caused by the system will irritate them and must therefore be indicated to them. In this time range, using busy indicators to indicate a delay is usually sufficient, because more sophisticated feedback might be distracting.
Busy indicators range in sophistication: They can be static or animated indicators for a delayed system response. Typically, either the mouse cursor or a specific graphic is used as an indicator. I would like to distinguish between the following types of busy indicators:
According to the distinction made by McInerney and Li (2002), static cursors indicate that the system is busy and blocked for further input (busy indication), while animations indicate that the system is still working (working indication). In practice, the system often also blocks input during animations, so that both functions are combined.
Wait animations are more user-friendly than static "wait" cursors or images, because they clearly indicate that the system is still working and has not crashed or hung (which is why McInerney and Li (2002) call them "working indicators"). However, if an animated GIF is used for a wait animation, the animation may continue even though the application in the background has hung.
Figure 3: Examples of loading animations
Regrettably, I could not find any clear recommendations about when to use wait cursors (static, animated) and when to use wait animations. Some systems use one only type, others both. In the latter case, a wait animation should follow a watch cursor in order to indicate a longer delay. Some systems display both types of animation at the same time, which can be confusing for users. In certain cases – such as during system startup – there may be no cursor available, and an animated graphic is the obvious choice (see right example in figure 3).
I recently encountered speculations about how the speed of an animation could influence the users' perception of the duration of a delay. I would be rather hesitant about trying to try to fool users with speed-related tricks. A typical "spinning" time seems to be about one second for one cycle. While faster speeds may attract the users' attention to a greater degree, they may also distract them. This distraction effect may also be the idea behind animated cursors, in that the animation distracts users from the delay for a short while. However, this effect may actually backfire if the animation goes on indefinitely...
Like wait cursors, wait animations do not tell users how long a delay will last. In this sense, they are "no-clue indicators:" The developer seems to have no clue about how long the delay will last, and the user won't be given any clue either. Therefore, in the same way as wait cursors, wait animations should be replaced by a progress indicator if the delay lasts longer than a few seconds and is likely to be of longer duration.
As soon as users have to wait for a few seconds before they get a system response, they switch to the cognitive level: That is, they have time to think and speculate about the reasons for the wait, and they make remarks about the system's performance. A mere three seconds suffice to make the system appear slow to users; some authors even say that one or two seconds are enough. The users' attention starts to wander; their focus on the task at hand wanes and is eventually lost (at about 10 seconds). Users may even start other tasks, such as checking their e-mail, if the delay lasts too long, and eventually they get annoyed (at about 15 seconds). Thus, the cognitive level includes aspects of thinking, attention, and motivation.
Cognitive activity on the user side requires more qualified feedback from the system; feedback that informs users about the cause and duration of the delay and also asks for some understanding for it – such as by explaining what is going on in the computer (in user-oriented language, of course). There are two types of informed feedback that I would like to discuss in the following: progress indicators and system messages.
As I mentioned above, progress indicators provide the best busy feedback because they inform users about the remaining waiting time and typically also the ongoing process. Progress indicators can be graphical, textual, or a combination of both. According to Jeff Johnson (2007), they greatly increase the perceived responsiveness of an application or a system, even though they do not shorten the actual time required to complete an operation. This is probably due to the fact that users can adapt their behavior according to the expected waiting time. They are also given reasons why they have to wait rather than being left in the dark, which is the worst thing a system can do with users. Users need orientation.
Detailed guidelines for designing progress indicators can be found in McInerney & Li (2002) – so I will only add a few remarks. First, it is better to display the work remaining than the work completed (see figure 4):
Figure 4: Different states of a progress bar (Mac OS X) showing the work remaining in "human-scale precision" forecasts
Secondly, although progress indicators should make reliable predictions, they do not need to be exact. Rough predictions will not disturb or confuse users. However, indicators that irregularly and unpredictably change the value for the estimated waiting time – for example, within a range between 100 minutes and 10 seconds – are a nuisance for users. This issue can in part be eliminated by reducing the precision of the given information. McInerney & Li (2002) suggest: Use human-scale precision, not computer precision. Here are two examples:
|Less than a minute remaining||47.5 sec remaining|
|About 4 hours remaining||3 hours and 35 minutes remaining|
This approach is, for example, used by Apple's Mac OS X (see figure 3).
Finally, the authors state that displaying total progress is better than displaying progress at the current step. For example, it is better to have a progress bar that indicates the overall progress of a multi-step procedure than one that displays the progress of the current step and starts over with each step, leaving users without orientation about the overall process. Personally, I prefer double progress bars in this case: One progress bar displaying the progress of the current step and one showing the progress of the overall process (see figure 5; note that this example violates in part the recommendation to show time or percentage remaining):
Figure 5: Example of a "double" progress bar – one bar displays the progress of the current step, another shows the progress of the overall process
Computer users know all too well that not every progress indicator can be trusted: There are a lot of so-called "phony" progress indicators out there. According to Jeff Johnson, in a "phony" progress bar the fullness of the bar or the displayed value does not show the operation's actual progress. Phony progress indicators are just fancy busy indicators – even worse, they try to fool users. There are several variants of them:
Figure 6: Progress bar with an animated bar that may provide the illusion of moving forward even if there is no progress
McInerney and Li (2002) make some interesting remarks about the interaction style for progress indicators. Typically, the indicators are implemented as intrusive dialog windows (see figures 4-6, for example). However, it is also possible to integrate progress indication into the main display. The authors suggest two approaches: embedded progress indicator bars (see figure 7 below for an embedded message) and progressive display. For example, some browsers integrate progress bars that show the progress of page loads into their window controls. As an example of the latter technique, the authors refer to the technique of progressive loading, which avoids the appearance of a progress bar altogether. Instead, the loading process itself serves as an indicator of the progress. A typical example is the progressive or piecemeal loading of images on Web pages.
Often, progress indicators include some information about what is happening during the delay. For example, they display which file is being copied. Given that the duration of a delay cannot be predicted, the developer can at least send a system message that indicates the currently active operation – preferably in simple user terms, not in technical ones. Such messages show that the developer cares about the user and wants to ask for their understanding. An alternative would be to keep the progress indicator and not display the remaining time but the remaining percentage of work, instead, as Nielsen suggests.
Figure 7: Embedded system message with animation
Regrettably, developers are often faced with with situations where the duration of a delay is hard or even impossible to predict and thus decide to use indicators that leave users clueless about the reason for and the duration of a delay. From a user's point of view, providing a message that contains information about the computer's activities is a much better choice than an endlessly spinning animation. Figure 7 (above) shows an example that combines a message with an animation; this message is also embedded, not in a separate dialog window.
Inspired by Tognazzini, I would like to add one more type of feedback to the list, namely "end-of-process" feedback, which is given after a lengthy process has finished. Tognazzini suggests on his Website: Make the client system beep and give a large visual indication upon return from lengthy (>10 seconds) processes, so that users know when to return to using the system. Thus, this feedback is useful because users may have turned to other work after about 10 seconds. The feedback should not only be given visually but also acoustically because the user may have hidden the window that belongs to the process or even have left the computer.
I have now investigated the different forms of feedback: immediate, busy, and informed; I have also added "end-of -process" feedback to this list. In the third and final article of this series, I will move on to the important questions of (1) under what conditions and (2) at what point in time the different types of feedback should be used.