Design Tidbits

back Tidbits Overview

Tools for Design and Visualization


Interaction Design

Screen Design


Visual Design

Design Process

Web, Web Applications, Web Design





Waiting at the Computer: Busy Indicators and System Feedback – Part 2

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.


Immediate Feedback

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.

Changing the shading of a button in order to show that a button has been clicked

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).

Three variants of a button in a Web application - not pressed, hover, pressed

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.


Busy Feedback

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:

  • Busy indicator feedback is the simplest form of busy feedback: Some sort of indicator tells the user that the system is busy and will not accept user input, but neither why it is busy, nor for how long.
  • Working indicator feedback is a variant of this feedback (McInerney & Li, 2002). It tells the user that the system is still busy and is not hanging, typically by providing some sort of animation. In practice, both types of feedback are often provided by the same indicator, so that I will refer only to busy indicators in the following.
  • System messages tell the user the reason for a delay and might therefore be regarded as "informed feedback." The message may change according to the current process. Again, no information about the duration of the delay is provided.
  • Progress indicators tell the user (ideally) how long a process will last and what is currently going on. They, too, offer "informed feedback" – the best feedback one can give, provided that the progress indicator does not try to fool the user.

In the following, I will discuss these types of busy feedback in more detail.


Busy and Working Indicator Feedback

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:

  • Static wait cursors, such as watch cursors and hourglass cursors, are the simplest form of busy indicators.
  • Animated cursors, such as a rotating beach ball or hourglass cursor, are more sophisticated than static cursors and indicate that the system is still working.
  • Wait animations are animated graphics that appear prominently on the screen and may be much larger and thus more conspicuous than a cursor. Examples of these are the "downloading data" animations in Web browsers and the startup animation of the Apple Macintosh. They also indicate that the system is still working (but see below).

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.

Example of a loading animationExample of a loading animation

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.


Informed Feedback – Feedback That Asks for User Understanding

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.

Progress Indicators

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.

Design of Progress Indicators

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):

Different states of a progress bar

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:

Good Bad
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):

Example of a double progress bar

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

Phony Progress Indicators

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:

  • Some indicators show the progress for each item; they fill up once for each item, starting over for the next one; users do not have any orientation with respect to the whole process.
  • Others simply fill up cyclically in correspondence to nothing particular.
  • I also found a progress indicators that filled up to 100%, stated that the remaining time would be 5 seconds, and remained unchanged for more than 10 minutes.
  • Finally, I would add to this category animations of the progress bar that seem to indicate progress by inducing an illusory movement (see Apple Mac OS X, figure 6). This is particularly annoying for protracted processes where the progress bar creeps forward very slowly (or not at all).

Progress bar with an animated bar

Figure 6: Progress bar with an animated bar that may provide the illusion of moving forward even if there is no progress

Interaction Style

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.

System Messages

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.

System message

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.


"End-of-Process" Feedback

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.




top top