| Print version | |
Related Links |
|
| Links and References for Performance | |
| Performance Analogies | |
Background Links |
|
| Review ofGUI Bloopers 2.0 (Jeff Johnson) | |
| Research-Based Web Design & Usability Guidelines | |
By Gerd Waloszek, SAP User Experience, SAP AG – Updated: September 30, 2010
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
The following glossary collects terms from the area of human and computer performance as well as responsiveness.
Ajax (asynchronous JavaScript and XML), or AJAX, is a group of interrelated web development techniques used for creating interactive Web applications or rich Internet applications. With Ajax, Web applications can retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing page. Data is retrieved using the XMLHttpRequest object or through the use of remote scripting in browsers that do not support it. Despite the name, the use of JavaScript, XML, or its asynchronous use is not required.
Source: http://en.wikipedia.org/wiki/AJAX (Wikipedia)
See Wait Animation
Busy 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. We distinguish between the following types:
System feedback using a busy indicator (the feedback can be called busy feedback or busy indication). Busy indicator feedback is the simplest form of busy feedback: Some sort of indicator, the "busy 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.

Figure: An hourglass cursor can be used for busy indication
Time that the computer or device has been powered but has not been used. If a computer or computer device is idle for a set period of time it may go into a standby mode or power off. (ComputerHope.com)
Note: This time can be used as a resource for planning and calculating ahead and thereby reducing latencies (most of the time, modern computers are idle and wait for user input).
See Wait Cursor
Short for a delayed system response to a user action. From a user's perspective also called waiting time. Depending on the duration of the delay, the user's expectations, and the type of process, the delay causes different psychological reactions.
See also Waiting Time, Response Time, Time Ranges, and Tolerance for Waiting Times
"End-of-process" feedback 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.
Efficiency is regarded as a component of usability and addresses the question:
According to Deborah Mayhew (2008), efficiency is:
Designing for efficiency means (Mayhew, 2008):
Efficiency is the primary usability goal when (Mayhew, 2008):
Source: Mayhew, Deborah (2008). User Efficiency: Evaluation and Design.
See Busy Feedback
In the context of responsiveness, Jeff Johnson (2007) talks about "timely feedback" and discusses several types of it, such as immediate feedback, busy, working, and progress indicators.
Different time ranges require different types of feedback:
The table below shows the connection between human time ranges and different types of feedback:
| 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 (3 sec) | 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 (3 sec) | 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) | ||||
Combining time ranges and their psychological interpretations with interaction contexts leads to the following matrix of recommendations for providing system feedback:
| 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 |
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: Recommendations for the use and the timing of different kinds of feedback in the event of a delay
Human performance is characterized by the amount of useful work accomplished by a human compared to the time and resources used. (Preliminary definition)
See Time Ranges
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 below), or the look of the screen element that the user interacts with.

Figure: 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 below, center).
![]()
Figure: Three variants of a button in a Web application – not pressed, hover, pressed
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: progress indicators and system messages.

Figure: Progress indicator for file copy in Windows XP
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.
See Wait animation
Source: http://en.wikipedia.org/wiki/Perceived_performance (wikipedia)
Source: http://www.tricerat.com/support/docs/files/whitepapers/WhitepaperSimplifyResources.pdf; http://www.tmurgent.com/WhitePapers%5CPerceivedPerformance.pdf (September 2003)
More or less the same as perceived performance but reduced to the "speed" aspect.
Computer performance is characterized by the amount of useful work accomplished by a computer system compared to the time and resources used.
Depending on the context, good computer performance may involve one or more of the following:
Source: http://en.wikipedia.org/wiki/Computer_performance (wikipedia)
Note: This definition includes response times, which may not necessarily mean the same as responsiveness.
Performance, (...), has to do with how quickly the software computes and displays the desired results.
Note: Johnson distinguishes between performance and responsiveness and criticized that both are often equated.
Source: Jeff Johnson (2000). GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers. Morgan Kaufmann Publishers (Chapter 1: First Principles; Principle 7: Design for Responsiveness, p. 368).
Progress indicators tell the user (ideally) how long a process will last and what is currently going on. They 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.

Figure: Progress indicator for file copy in Windows XP
Detailed guidelines for designing progress indicators can be found in McInerney & Li (2002).

Figure: Example of a double progress indicator
Regrettably, 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:
Response time is defined as the number of seconds it takes from the moment users initiate an action (usually by pressing an ENTER key or mouse button) until the computer begins to present results on the display, printer, loudspeaker, or mobile device. (S&P, 455)
When the response is complete, users begin formulating the next action.
The user think time is the number of seconds during which users think before initiating the next action. (S&P, 455-456)
Simple stages of action model:
| User initiates activity | Computer responds | |||
| <------ Response time ------> | <------User think time ------> | |||
Figure: Simple stages of action model of system response time and user think time
More realistic model:
| User starts typing |
User initiates activity |
Computer begins response |
Computer completes response |
|||||
<------ Response time ------> |
------> |
|||||||
<----- User planning
time ------> |
------> |
|||||||
<------ |
<------User think time ------> |
|||||||
Figure: Simple stages of action model of system response time and user think time
Source: Ben Shneiderman & Cathérine Plaisant (2004). Designing the User Interface (4th Edition). Pearson Addison-Wesley, pp. 454ff.
In data processing, the response time perceived by the end user is the interval between
In a data system, the system response time is the interval between the receipt of the end of transmission of an inquiry message and the beginning of the transmission of a response message to the station originating the inquiry.
Sources: Federal Standard 1037C and MIL-STD-188; http://en.wikipedia.org/wiki/Response_time_%28technology%29 (wikipedia)
According to the IBM Dictionary of Computing (which cites International Organization for Standardization Information Technology Vocabulary as the source), response time is:
The elapsed time between the end of an inquiry or demand on a computer system and the beginning of a response; for example, the length of the time between an indication of the end of an inquiry and the display of the first character of the response at a user terminal.
There is also the concept of perceived response time, which is the time a user senses as the beginning of input and the end of the response. It is actually possible (though not usual) for perceived response time to be too fast (it can be mildly disconcerting if a system responds almost instantly). However, this is not the usual complaint.
Source: http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci212896,00.html
Responsiveness is the software's ability to keep up with users and not make them wait.
>> Research also suggests that improving the responsiveness of software, in addition to increasing user satisfaction, actually improves the productivity of its users (Brady, 1986)
Source: Jeff Johnson (2000). GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers. Morgan Kaufmann Publishers (Chapter 1: First Principles; Principle 7: Design for Responsiveness, p. 49).
The responsiveness of an interactive system describes how quickly it responds to user input.
Long delays can be a major cause of user frustration, or let the user believe the system is broken, or that a command or input gesture has been ignored. Responsiveness is therefore considered an important issue for human-computer-interaction (HCI).
Responsiveness is not the same as performance. A system with a good performance can have a poor responsiveness, and vice versa.
Source: http://en.wikipedia.org/wiki/Responsiveness (wikipedia)
In a Web as well as a server-based application, there are client-side and server-side tasks running. For example, when a page is refreshed some process will be performed between the client and the server going forth and back. This mechanism is known as server round trip, that is, a server roundtrip takes place whenever you send data to the server and it responds. (Preliminary definition)
More or less the same as performance but reduced to the "speed" aspect.
See Feedback
Often, the duration of a delay cannot be predicted. In such a case, 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.
See Performance
The action that a system performs in response to a user's input (action). For users, the time that they have to wait for the system's response is relevant.
See also Response Time, Waiting Time, Time Ranges, Tolerance for Waiting Times
See Responsiveness
See User Think Time
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 tables below summarizes the results of our literature search. It defines user-relevant time ranges* and their meaning from different perspectives.
| Time Range |
User Interface: Acceptable Response Times |
User: Response/Feedback Does Not Appear Timely |
Comments on Untimely Response |
| 0.1 sec (0.0-0.2) | Acknowledge user input (Direct manipulation: key press, mouse click, open/close menu, highlighting, …) |
Perception of smooth animations and cause-and-effect relationship breaks down | Must not happen! |
| 1.0 sec (0.2-2.0) | Present result of simple tasks (navigation, open new window), finish unrequested actions (auto-save) |
Engaged user-system dialog breaks down | Should not happen, provide feedback, allow user to abort the process |
| 3 sec (2.0-5.0) | Present result of common tasks (simple search, calculation) | User has time to think: the system is perceived as slow, the user’s focus starts to wander, and the user may turn to other tasks | |
| 10 sec (5.0-15) | Present result of complex tasks (complex search, calculation) | User looses focus on task and may turn to other tasks | |
| >15 sec | Present result of very complex tasks (extensive search, calculation) | User gets annoyed; detrimental to productivity and motivation |
A variant of the table puts the focus on the human aspects:
| 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 (3 sec) | 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 (3 sec) | 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 |
*) 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.
See also Tolerance for Waiting Times
The users' tolerance for longer delays/waiting times depends on:
Otherwise the 1 second range has to be attained (= no knowledge/context, thus no expectations)
See also Time Ranges
This term is used by Shneiderman & Plaisant (2004), but no definition is given (apart from a diagram). According to the diagram, user planning time consists of a user activity, for example, typing, and the computer response time.
For further details see Response Time.
The user think time is the number of seconds during which users think before initiating the next action. (S&P, 455-456)
Simple stages of action model:
| User initiates activity | Computer responds | |||
| <------ Response time ------> | <------User think time ------> | |||
Figure: Simple stages of action model of system response time and user think time
| User starts typing |
User initiates activity |
Computer begins response |
Computer completes response |
|||||
<------ Response time ------> |
------> |
|||||||
<----- User planning
time ------> |
------> |
|||||||
<------ |
<------User think time ------> |
|||||||
Figure: Simple stages of action model of system response time and user think time
Source: Ben Shneiderman & Cathérine Plaisant (2004). Designing the User Interface (4th Edition). Pearson Addison-Wesley, pp. 454ff.
Further details see Response Time.
Note: Contrary to S&P's diagram, this time can be also used as a resource for planning and calculating ahead and thereby reducing latencies because at least part of it is computer idle time. That is, user think time may not be finished as the computer finishes its response.
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).

![]()
Figure: Examples of loading animations
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.
Regrettably, we 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 the figure above).
A mouse cursor that indicates through its shape and/or animation that the user has to wait. It can act as a busy indicator or as a working indicator, or both. There are:
![]() |
||
| Figure: Typical hourglass cursor of earlier GUIs; static or animated | Figure: The Apple Mac OS X spinning ball cursor is an example of an animated wait cursor |
The time that the user has to wait at the computer between a user action, such as a button press or click on a link, and a system response or the ability to interact with the system again. Depending on the duration of the waiting time, the user's expectations, and the type of process, the time causes different psychological reactions.
See also Response Time, Time Ranges, and Tolerance for Waiting Times
Working feedback (McInerney & Li, 2002) tells the user that the system is still busy and is not hanging, typically by providing some sort of animation.
See also Working Indicator, Feedback
System feedback using a working indicator is a variant of busy 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, busy and working feedback are often provided by the same indicator.
Working indication can be given through wait cursors and wait animations.