Design Tidbits

back Tidbits Overview

Tools for Design and Visualization

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 1

By Gerd Waloszek, SAP AG, SAP User Experience – Updated: October 10, 2008

Computers are becoming faster and faster – Moore's law tells us the details. For example, my first computer, an Ohio Superboard, had a 6502 MOS Technology CPU with a whopping CPU speed of 1 MHz. The CPU of my current Apple MacBook Pro is about 2,000 times faster and is even a dual core CPU, meaning that it should – at least in theory – be 4,000 times faster than my first computer's CPU. However, does my current computer feel that much faster? Does it feel fast at all? No. Actually, I have the impression that I have to wait much more today than I did nearly 30 years ago. Waiting seems to be a common experience with modern computers. The reasons for this paradox are manifold, but as a fact it stands. That's why Jeff Johnson (2007) distinguishes between a system's performance and its responsiveness: The first term relates to speed and the latter to the question of how long a computer has its users wait until they can continue with the human-machine dialog, that is, with their work. Increasing speed alone does not seem to be the solution for eliminating waiting times at the computer. In my editorial The Three Pillars of Human Performance at the Computer – Which One Fits Best? I have already discussed the difference between performance and responsiveness and pointed out how the waiting time issue can be attacked. Therefore, I will not dig into this issue any further. In this series of three articles, I would like to discuss a related issue, namely, the "worst-case" scenario: Provided that further technical optimization is not possible and users have to wait at the computer for a certain amount of time, what can developers and designers do to make the waiting more tolerable for users?

 

Time Ranges

Before we can look for approaches to making waiting at the computer more tolerable for users, we need to gain a basic understanding of how users perceive time at the computer, what the relevant time ranges for users are, and how they affect the users' work, attention, and motivation. For this purpose, I would like to cite a few references and then arrange the results into a simple table format.

Alan Newell (1994) defined a logarithmic time scale of human action, similar to size scales for the universe. His student, Stuart Card, together with coworkers, took a section from that scale and placed it into the context of human-computer interaction. Recently, Alan Cooper et al. (2007) and, most prominently, Jeff Johnson (2000, 2007) republished and further refined the scale from Robertson, Card, and Mackinlay (1989, 1993). Further relevant timing data can be found in Shneiderman & Plaisant (2004). The table below summarizes the results of my literature search. It defines user-relevant time ranges*, their meaning from different perspectives, and – as an addition – their consequences for giving users feedback, which is the topic of this short series of articles.

Time Range 0.1 (0.05-0.2) sec * 1 (0.2-2.0) sec 3 (2-5) sec 10 (5-15) sec >15 sec
Human Level Perceptual level: Perception, motor actions

Dialog level: Dialog, operation, action
Cognitive level: Thinking, attention, motivation
Hand-eye coordination, cause-and-effect relationships, smooth animation Focus on task Focus of attention starts to wander Focus of attention lost (10 sec) Motivation lost
User inputs commands and data and observes system User is engaged in dialog System is perceived as slow User probably moves over to other tasks (if possible) User gets annoyed
UI Level Direct manipulation: Mouse movement, drag, click, key press, smooth animations, highlighting, open menus, ...

Dialog

Present result of simple task**

 Present result of common task** Present result of complex task** or finish compound task (unit task) Present result of very complex task
Type of Feedback

Immediate feedback (acknowledgement): Highlighting, menu open/close, ...

Immediate feedback (options for action): hover effects, ...

 "Busy" indicator: Wait cursor "Working" indicator: Loading animation (no clue indicator)
Progress indicator (duration, type of operation)
Activity message(s) (type of operation, step number, ...)
--- "End-of-process" indicator (signals that process has ended)

Table 1: Human time ranges

*) Because the times are only rough guides, most authors simply list the powers of 10, such as 0.1, 1, and 10 sec; I have extended the numbers into consecutive ranges but please do not take the transition points too seriously. The limit of 2 seconds for the dialog level may already be too high.
**) The terms "simple," "common," and "complex" tasks haven been taken from the literature. In my opinion, they are only of limited use because they do not clearly describe the task types at the respective levels.

Basically, we have three levels or time ranges:

  • The perceptual level at about a tenth of a second
  • The dialog level at about 1 second
  • Beyond that the cognitive level, starting at about 2-3 seconds

The cognitive level can further be subdivided with respect to the effects on the users' attention and motivation.

 

An Analogy – Encased in a Use Case

In the following, I will use an analogy from real life to illustrate the different time ranges more clearly. Please note that the time ranges in the analogy are of a different scale than those for interaction with a computer. In addition, I encase the analogy into the format of a "use case" so that readers can distinguish the actions of the respective dialog partners more easily. The analogy is based on the following scenario:

  • You enter an old-fashioned shop with a counter in order to buy a book. Behind the counter, there is a clerk, your dialog partner.

The following "use cases" might happen:

Use Case
Variants
You (User)
The Clerk (System)
Type of Feedback
Type of Task
Outcome
1: Immediate Success     You ask for a book that you want to buy        
        The clerk lift his right hand indicating to you that that he has acknowledged your order and will process it – this takes just a fraction of a second Immediate feedback Cause and effect Acknowledge-
ment
        The clerk reaches into a shelf, gets the book, and places in front of you: There it is – it took just a second Dialog style feedback = successful end of operation Simple task  
      You get the book, pay, and leave       Success
2: No Immediate Success     You ask for a book that you want to buy        
        The clerk says: "It's not in the shelf but I will look into the store room and see if there is a copy for you." Here you may want to see a "busy" indicator like a watch because you do not know how long the clerk will stay in the store room    
2.1: Short Delay 1     The clerk goes to the store room, returns with a copy, and places it in front of you: There it is – it took just a few minutes Delayed successful end of operation Common task  
      You get the book, pay, and leave       Success
   
2.2: Long Delay 2     The clerk returns without book and explains: "The book is been sold out. I'll have to order one for you from the wholesaler." The clerk should also tell you that it will take about a week until the book arrives -> This is analogeous to a progress indicator Complex task  
2.2.1: Success   1   The book arrives from the wholesaler by mail, and the clerk notifies you of its arrival: There it is – it took a couple of days Very much delayed successful end of operation    
      You get the book, pay, and leave       Success
     
2.2.2: Failure   2   The book does not arrive, you do not get a notice, etc. No successful end of operation -> This is analogeous to a crashed or hanging system   Failure

Table 2: Book store analogy, encased in a use case format, for explaining the human time ranges at the computer

This analogy was inspired by Jeff Johnson (2007), who uses real-world dialogs in order to demonstrate certain responsiveness issues. For example, he explains missing feedback using the analogy of a repair shop. You might want to try that example as an exercise on your own, using the use case notation.

 

Types of Feedback

In the context of responsiveness, Jeff Johnson (2007) talks about "timely feedback" and discusses several types of it, such as immediate feedback, busy, and progress indicators. McInerney and Li (2002) add the "working" indicator to this list. According to them, a busy indicator blocks input, while the work indicator, which is typically a graphical animation, does not and indicates that the system has not hung. In practice, however, many work indicators also act as busy indicators.

As Table 1 shows, different time ranges require different types of feedback:

  • At the perceptual level, immediate feedback is mandatory to maintain the relationship of cause and action: To assure users that a command has been acknowledged, a mouse move or drag goes into the right direction, a key press has been registered, and so on.
  • At the dialog level, user and system take turns, and users are deeply engaged in the ongoing man-machine dialog. Any delays irritate users and therefore have to be indicated to them. Here, the mere indication of a delay is sufficient.
  • At the cognitive level, users have to wait for a certain amount of time before they get a response. So they start to think about why they have to wait, evaluate the system's performance, and guess what it may have to do. As a result, the impression of slowness comes up, the users' attention starts to wander, and their focus on the task wanes. Users may even switch to other tasks if the delay is too long, or they get annoyed. This "cognitive awareness" on the users' side requires a more qualified feedback, ideally one that informs them about the cause and duration of the delay and also asks them for their understanding for the delay. It may be also useful to provide an "end-of-process" indication because the users may have turned to other work after about 10 seconds.

Please note that most authors expect progress indicators to be provided within one second. I will come back to this issue in my third article of this series.

 

Outlook

In my follow-up article, I will discuss these types of feedback in more detail. The third and final article will be dedicated to the questions under which conditions and at which point in time the different types of feedback should be used.

 

References

 

top top