Design Tidbits

back To Overview of Tidbits

Design Tools

Simplification

Interaction Design

Screen Design

Hierarchies

Visual Design

Design Process

Web, Web Applications, Web Design

Performance

Miscellany

 

 

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

By Gerd Waloszek, SAP AG, SAP User Experience – October 14, 2008

In this series of three articles, I would like to discuss the following issue: Provided that users have to wait at the computer, what can developers and designers do to make the waiting more tolerable for users? 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 I presented in form of a use case. I also introduced several types of feedback that can be given to users to indicate that they will have to wait for the computer. In the second article, I discussed these types of feedback in more detail and looked at recommendations for their use. In this third and final article of the series, I will finally focus on the important questions under which conditions and at which point in time the different types of feedback should be given.

 

The Questions: When to Show Which Feedback?

The most important questions from developers regarding feedback in the event of delays are:

In the following, I will try to find answers to these questions. First, I will present the results of my (incomplete) research of the literature about feedback in the event of delays. Then I will adopt a concept that has been put forth by McInerney & Li (2002), namely the concept of interaction contexts. Often, the timing recommendations for feedback are cast into variants of the table that originates from Robertson et al. and has been adopted by a number of authors in different ways. I presented this table in "my own adoption" in the first article of this series and added a psychological interpretation of the time ranges to it. I will refer to these categories at the end of this article in order to better justify certain recommendations, which I will give in my "unproven" version of recommendations for feedback.

 

What the Literature Says...

As indicated, many recommendations about the timing and the kind of feedback for delays are provided within the context of the table originating from Robertson et al. (see also part 1 of this series) who already provide some recommendations. Their table and their recommendations have been adopted by a number of authors, and it is interesting in itself to find out how they interpreted and modified the original table. As a result, I came across some conflicting recommendations for feedback. At this stage, however, I do not want to resolve these issues but will list what I have found for your reference:

Duration
(Variation)		 Type of Feedback Mainstream Opinions Further Opinions and Remarks
0.1
(0.05-0.2 seconds)
  • Immediate feedback
  • Busy indicator

Immediate feedback:

  • For successful hand-eye coordination
    • mouse click (G)
    • pointer/mouse movement (J, G)
    • window movement and sizing (J, G)
    • drawing operations/gestures (J, G)
    • key press (G)
    • other (G)
  • That a button has been clicked (J, G)
  • After other physical input from the user (G)
  • After each change in the state of controls that react to input from the user (G)
    • Displaying menus
    • Indicating drop targets

Busy feedback:

  • Displaying "busy" indicators (J)

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

Acknowledge all button clicks by visual or aural feedback within 50 milliseconds. (T)

Acknowledge user input. (J)
1
(0.2-2 seconds)
  • Busy/working indicator
  • Progress indicator

Busy feedback:

  • Display an hourglass for any action that will take from 1/2 to 2 seconds; animate the hourglass so [users] know the system hasn't died (T)

Informed feedback:

  • Display progress indicators [for long operations (> 1 second)] (J, G)

Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, ... (N)

3
(2-5 seconds)
  • Progress indicator
  • System message

Informed feedback:

  • Display progress indicators for long operations (> 1 second) (J, G)
  • Communicate the actual length through an animated progress indicator (T)
  • Display a message indicating the potential length of the wait for any action that will take longer than 2 seconds. (T)
  • Offer engaging text messages to users informed and entertained while they are waiting for long processes ... to be completed. (T)

 

Mac OS X displays the spinning cursor automatically when your application fails to process an event within 5 seconds (A)

For 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 (...). One could still give less conspicuous progress feedback. A common solution is to combine a "busy" cursor with a rapidly changing number in small field in the bottom of the screen to indicate how much has been done. (N)

10
(5-15 seconds)
  • Progress indicator
  • "End-of-process" feedback

Informed feedback:

  • Up to about 10 seconds: Providing a progress bar is critical here. (C)
  • Percent-done progress indicators should be used for operations taking more than about 10 seconds. ... Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. (N)
  • 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 [Myers 1985]. As a rule of thumb, percent-done progress indicators should be used for operations taking more than about 10 seconds. (N)

"End-of-process" feedback:

  • 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. (T)
 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. (N)

 

 
>15 seconds

Table 1: Results of a literature search about the use and the timing of feedback in the event of delays

Authors: (J) Johnson (includes Robertson et al.), (C) Cooper et al., (N) Nielsen, (T) Tognazzini, (G) Gnome

The most apparent conflict in the table above is how Nielsen and Tognazzini handle progress indication, compared to Robertson et al. and authors like Johnson who follow them. For arriving at a plausible conflict resolution, I will add the human levels that I had already defined in the first article of this series further down.

 

Adding the "Context" Aspect: Interaction Contexts

McInerney & Li (2002) introduced the concept of interaction contexts. This concept allows for giving recommendations that depend on the situation, in which a delay appears. The authors list three different contexts (two of which are only relevant to them), to which I would like to add a fourth one, namely monitoring processes:

  1. The loading tools context refers to waiting for a computer to display requested tools so work can be performed.
    Examples: Launching an application, launching a dialog through a pushbutton, displaying a menu, expanding a tree, loading the homepage of a Website
    These examples all have in common that the user is preparing the computer to do some work such as reading content, manipulating content, inputting data, or having the system perform some work like running a script.
  2. The work actions context refers to waiting for the system to display the result of a user action.
    Examples: Presenting search results, presenting a requested Web page, or presenting the result of an application command invoked by the user, such as a command to create a new database
  3. The user input context refers to interaction "at the scale of mouse clicks" and thus to the wait period between user input and the system acknowledging that it has been received.
    Examples: Highlighting icons, buttons, links, or other screen elements in various ways after these have been clicked, showing the outline of an object that the user drags with the mouse (or the object itself in a new location)
  4. The monitoring processes context has been added by me and refers to users monitoring processes that take some time.
    Examples: Coping files, installing software, installing software updates

According to McInerney & Li, users have different expectations of an acceptable wait period and the kind of feedback that meets their needs:

 

Combining Everything: My (Unproven) Recommendations

Finally, I would like to combine the two inputs, that is, the recommendations from the literature and the interaction contexts, and add the "human level" as a further guide for arriving at my own, unproven recommendations for the use and the timing of the different kinds of feedback that I have presented in this article series. Combining time ranges and their psychological interpretations with interaction contexts leads to the following matrix:

Duration
(Variation)		 Human
Level
Interaction Context
Loading Tools Work Actions Monitor. Processes User Input
0.1
(0.05-0.2)		 Perception, motor actions --- --- Informed feedback: progress indicator ** Immediate feedback
1
(0.2-2)		 Dialog, operations Busy feedback: static/animated cursor, animation Working feedback: static/animated cursor, animation Informed feedback: progress indicator ---

> 3
(2->15)

 Cognition*:
Thinking, attention, motivation

Busy feedback: static/animated cursor, animation

Informed feedback: progress indicator, system message ***

Informed feedback: progress indicator, system message

"End-of-process" feedback ****

Informed feedback: progress indicator

"End-of-process" feedback ****

 ---

Table 2: Recommendations for the use and the timing of different kinds of feedback in the event of a delay

Legend

*) I combined the three times ranges of the cognitive level into one level. • **) See item 5 below. • ***) Whereas McInerney & Li recommend to use only busy feedback in the loading tools context, I would recommend informed feedback, particularly in the case of longer delays. • ****) See item 6 below.

I would like to add a few comments to this table:

  1. I follow Nielsen and Tognazzini by recommending to use a progress indicator only after 2-3 seconds, that is at the cognitive level. My decision acknowledges that only after arriving at this stage, users start to think and thus are open to digesting more complex information.
  2. For the case that a system offers both a wait cursor and an animated graphic I could neither find any recommendations nor resolve this issue. In my opinion, the wait cursor should be displayed first, followed by the wait animation. I would not display both at the same time because this might confuse users, particularly if the cursor flickers and changes between different states, thus "contradicting" the animation.
  3. Nielsen recommends to indicate percentage complete if a prediction of the duration of the is not possible. Following McInerney & Li, it would probably be better to indicate "percentage remaining."
  4. Problems can arise if the threshold for displaying and hiding a busy indicator such as a watch cursor is set inappropriately. This can result in a flickering cursor (changing between wait and normal cursor), which causes distracting "agitated" feedback.
  5. Before a progress indicator provides monitoring information, it may show an "initializing" information (see figures 1 and 2).
  6. Following Tognazzini, I included a further type of feedback, namely "end-of-process" feedback (I have updated the two previous articles accordingly). This feedback is useful if delays are longer than 10 seconds, after which users typically turn to other work and need to be notified that the original process has ended.

Progress indicator initializing before providing a time estimate

Figure 1: Progress indicator initializing before providing a time estimate (Mac OS X; the text states that the computer is calculating the time remaining)

Progress indicator initializing before providing a time estimate

Figure 2: Progress indicator initializing before providing a time estimate (Windows XP)

 

Conclusions

While there may be some uncertainty in the literature about after which delay which type of feedback should be given, there seems to be mostly a general agreement about in which context which type of feedback – ranging from immediate feedback, to busy indicators, and further to progress indicators – is appropriate. Using the concept of interaction contexts and the human levels, I could resolve some of the conflicting issues, but some open questions remain, such as the use of animated cursors and graphics. In contrast to McInerney & Li, I would also provide progress indicators in the loading tools context if delays last for several seconds (or longer than 10 seconds).

To sum up, the main purpose of any busy feedback is to inform users about a delay and ask for their understanding for it. That is, this feedback serves for increasing the users' tolerance for waiting times. Such an approach implies that developers are cooperating with users in these situations. Therefore, I would seriously warn them to use tricks, such as increasing the speed of animations because this might make the delay appear shorter, use animations that pretend progress, or display phony progress indicators in order to fool users about the length of the delay. These tricks may work for a short while but will in the end annoy users because the system made "wrong promises."

 

References

 

top top