|Waiting at the Computer: Busy Indicators and System Feedback – Part 2|
|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: 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?
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, ...||
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 cognitive level can further be subdivided with respect to the effects on the users' attention and motivation.
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:
The following "use cases" might happen:
The Clerk (System)
Type of Feedback
Type of Task
|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-
|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.
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:
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.
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.