Contents: Background Concepts related to progress indication User interaction contexts Overview and examples Quantitative information for progress indication displays Displaying multi-step progress information Design of user actions Interaction style Implementation Resources About the authors Rate this article Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Paul McInerney (paulmci@ca.ibm.com), Senior User Interface Designer, IBM
Jin Li (jinli@ca.ibm.com), Senior User Interface Designer, IBM

01 Jul 2002

This article covers aspects of progress indication related to: understanding the design problem, design considerations and guidelines, and implementation issues and tips. Guidance is provided based on usability testing. This information will enable UI designers and developers to design more effectively and evaluate progress indication design more critically.

Background
There is an aspect of user interface (UI) design that is present in all the applications we design yet that few of us think about - progress indication. Even the most detailed specifications written and read by the authors rarely mention progress indication. When most designers and developers hear the term "progress indication", they think of the Windows file copy dialog. Unfortunately, that is just about all that comes to mind. In fact, progress indication design can be an interesting and challenging topic for the following reasons:

1. Progress indication issues arise in many application design contexts.
2. There are many design decisions that need to be made correctly for an optimal user experience.
3. There is a fair amount of human-computer-interaction research that can be leveraged to make valid design decisions about progress indication.
4. Optimal progress indication design involves close cooperation with implementation aspects: application architecture, operating system platform characteristics, and application development tools.

As this article shows, progress indication is much more than animations of documents flying between folders.

One reason this aspect of UI design is neglected is that progress indication is rarely written about or emphasized in UI training. One of the few places to read about this topic is the excellent chapter (Chapter 7: UI Responsiveness) in Jeff Johnson's recent book GUI Bloopers. This article complements the GUI Bloopers chapter. It covers new ground and presents another perspective.

This article covers the following main topics:

• Understanding the Problem: The first section presents concepts related to progress indication and identifies the needs and constraints related to progress indication design. The second section defines some user interaction contexts that are useful for analyzing progress indication needs.
• Externals Design: Several sections are devoted to designing progress indication, each addressing a particular facet of the externals design, for example, presenting quantitative progress information. For each section, the applicable design elements and decisions are itemized, and then a few key guidelines are presented.
• Implementation: The practical details of achieving the externals designs are covered. The focus is on desktop applications written in Java.

This article will enable UI designers and developers to design more effectively and evaluate progress indication design more critically.

Understanding the problem: 1. Concepts related to progress indication

Introduction
Software engineering authors such as Michael Jackson (see Resources) have made the point that application designers spend too little attention on understanding and representing the problem to be solved; they tend to jump into solution description without sufficiently articulating the design goals or demonstrating adequate domain knowledge. One negative consequence is that solutions are arrived at by analogy which results in: (1) copying bad designs and (2) copying designs that are good but not appropriate for the current problem. This situation can be seen where design discussions of progress indication with colleagues invariably invoke the Windows File Copy window. This design has some shortfalls for its use in copying files (see GUI Bloopers) and is certainly not appropriate to all progress indication situations.

This section aims to provide a solid understanding of the domain of progress indication by describing:

• the concept of progress indication and related concepts,
• the psychological basis for progress indication design, and
• user interaction contexts which require particular progress indication solutions.

Concepts of performance and responsiveness
To understand progress indication, it is worth considering the concepts of UI performance and UI responsiveness:

• UI performance: how quickly the software computes and displays the final results
• UI responsiveness: the extent to which the software makes the wait acceptable to the user

The GUI Bloopers chapter discusses these concepts extensively. Some key points related to this article are:

• Programmers are much more concerned about performance than responsiveness.
• Responsiveness is at least as important as performance for achieving user satisfaction. For example, a key responsiveness concept is the distinction between initial results and final results; users are much more accepting of delays in receiving final results (relating to limited performance) if they quickly receive preliminary results (relating to responsiveness) that they can begin to use while waiting for the final results.
• There are several aspects of UI responsiveness, some of which are related to progress indication.

In summary, progress indication is needed because: (1) there are inevitable limitations in UI performance, that is, there are always cases where the user will have to wait for a final result, and (2) increased UI responsiveness, or improved communication with the user, can make the wait more acceptable to the user.

Types of indication: busy, working, progress, and status
Progress indication overlaps other types of indication:

• Busy indication: The system is busy working on a user request; hold further requests because the system has no (or limited) ability to process them. Visually, this is typically indicated by an hourglass icon or some other means and further input is disabled.
• Working indication: The system is still working, that is, it has not hung. Visually, this is often indicated by animation, e.g., hourglass animation, animations in web browser frames, or flying document animations.
• Progress indication: Indicates how much work has been completed or remains. As well, the indication can include information about how well the work is going, for example, indicating the status of completed steps.
• Status indication: Indicates the state of an operation or component: there may be a status aspect to progress indication but status indication is a much broader subject.

Psychological latency thresholds (or defining "instantly")
What works and does not work in progress indication design can be tied to some psychological phenomena. These phenomena correspond largely to the ways that humans think, perceive and apply to any aspect of design, not just GUIs.

The GUI Bloopers chapter highlights that there are certain time thresholds that should be observed to avoid disrupting psychological phenomena. Two thresholds are listed here and explained below:

• 0.1 second - perception of cause-and-effect threshold
• 1 second - conversation response threshold

The "perception of cause-and-effect threshold" implies that the UI should respond or visually acknowledge user input within 0.1 seconds. This applies to aspects such as: a pushbutton appearing depressed after it is clicked, the mouse pointer moving after the mouse is moved, letters appearing after they are typed, and a pop-up menu or window starting to appear after it is invoked. Failure to achieve this performance limit results in problems such as decreased eye-hand coordination, slowed input, and a decrease in the perception that the input (e.g., moving the mouse) causes the effect (e.g., the movement of the pointer on the screen). It also results in perceptions of the entire product being sluggish. Developers can observe this phenomenon for themselves by invoking pop-up menus in different applications. There are noticeable differences in latency; even with latencies well under one second, menu display can appear sluggish.

The implications of this threshold for responding to user input are: (1) in specifications, the commonly-found vague wording "... should respond instantly" should be replaced with "...should respond within 0.1 seconds to avoid degradation in user performance or satisfaction," and (2) there is no adequate progress or busy indication; performance should be good enough that there would be no latency in which to display indication. If this performance cannot be achieved, then any progress indication display is only a band-aid; it will tell the user that the system is not hung but it will not ameliorate user performance or satisfaction problems cased by the poor performance.

The "conversation response" threshold implies that the UI should provide preliminary results to a user request within one second. This tells the user their request has been received. This is based on research showing that in conversation, people (subconsciously) expect their conversation partner to react within one second. After that, they get anxious that their communication was not received. For example., the communication partner did not hear them or maybe the application is hung and needs to be rebooted. Anyone who has conducted a job interview knows the discomfort experienced after they ask a question and the seconds tick away before they get a response.

The implications of this threshold are: (1) in specifications, the commonly-found vague wording "... should respond instantly" should be replaced with "... should respond within 1 second in cases such as displaying a window." Otherwise, users may believe the system failed to accept their input and they may repeat their input. Besides the immediate user problem, repeated input can result in further performance degradation or system malfunction. (2) The user needs acknowledgement with a busy indication. Not until there is a longer delay (more than one second) do they need more detailed progress indication.

Psychology of waiting
All of us have experienced waiting: waiting in line at a store check-out, waiting on hold for service, and waiting for a movie to start. There have even been unconfirmed reports of people waiting for a computer operation to complete. Studies have been conducted of people waiting that have implications for progress indication design, and UI responsiveness more generally. While the duration of the wait affects how irksome the wait is, it is by no means the only key variable. Factors that make waiting less irksome include:

• Ability to end the wait by exiting the situation
• A known end point for the wait
• A duration that is consistent on each occasion
• Observable and linear progress
• Periodic reassurance that things are proceeding normally
• Knowledge that clear notification will be provided in the event that a function does not proceed normally

The implications of this research are: (1) designing progress indication is not an entirely new field of knowledge; as designers, we can leverage our experience in many areas of daily life, and (2) many parameters of progress indication design affect the user's waiting experience; it is a topic worthy of some attention in designer training and project work.

Understanding the problem: 2. User interaction contexts
Analyzing progress indication design specifications requires identifying user interaction contexts that need different progress indication solutions. In defining these user interaction contexts, it is useful to first distinguish between two situations where the user has input a request and is waiting for the computer to display the desired result: the Loading Tools context and the Work Actions context.

The Loading Tools context refers to waiting for a computer to display requested tools so work can be performed. Examples include launching an application, launching a dialog through a pushbutton, displaying a menu, expanding a tree, and loading the home page of a website. These examples differ widely in scale and other aspects but they all have in common that the user is preparing the computer to do some work. That work could be reading content, manipulating content, inputting data, or having the system perform some work, for example, running a script.

The Work Actions context refers to waiting for the system to display the result of the user action. Examples of work actions include 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.

The justification for distinguishing between Loading Tools and Work Actions is that users have different expectations of an acceptable wait period and the progress indication design that meets their needs. For Loading Tools, users expect their wait will be proportional to the perceived size of the tool being displayed, i.e., they expect a secondary window to load faster than the entire application. In any case, users are generally intolerant of having to wait for tools to load. Suitable progress indication, if required, is a busy indicator, e.g., hourglass. In contrast, for Work Actions, users are more tolerant of long wait times, which could be hours in some domains. For this type of system action, users are generally more interested in obtaining indication that goes beyond a busy indication.

There is a third user interaction context: User Input. This refers to interaction at the scale of mouse clicks. This wait period is the one between the input and the system acknowledging visually that it has been received. In this case, the acceptable latency is less than 0.1 second, so progress indication is not applicable. These concepts are summarized in the table below.

Table 1. Illustration of the three user interaction contexts

The differences between each user interaction context are summarized in the table below.

Table 2. Comparison of the three user interaction contexts

Externals design: 1. Overview and examples

Having described progress indication concepts, this article turns to externals design of progress indication. As shown in the figures below, there are many types of progress indication display.

Figure 1. Free time example

Figure 2. Replication example

Figure 3. Steps example 1

Figure 4. Steps example 2

The following sections address these categories of progress indication design:

• Design of information in progress indication displays: This consists of two categories of information: quantitative measures and indication of steps completed.
• Design of user actions: This involves the actions such as Cancel that need to be provided.
• Interaction style: This refers to additional topics related to user interaction style.

For each section, the design considerations and options are itemized, and then some guidelines are provided.

Externals design: 2. Quantitative information for progress indication displays

Considerations

The following points list the considerations and options related to quantitative progress information:

• Providing quantitative progress information or only a busy indicator, such as an hour glass.
• Presenting progress in terms of percentages or as a count of completed items. For example: 90% complete or 5 out of 6 steps complete.
• Measuring time vs. steps. For example: 30 seconds vs. 2 steps.
• Considering the amount remaining or time elapsed. For example: 10% done or 10% remaining.
• Displaying progress of the current step or overall progress. For example: Step 1 is 90% complete or 90% complete overall.
• Displaying rate information. For example: 3K/second.

Designers should also consider:

• Accuracy of estimates. For example: displaying 5 seconds when it is really 10 minutes.
• Precision of estimates. For example: 3.4% remaining vs. about 10% remaining.

Guidelines
The following guidelines will help designers as they consider the considerations listed above.

Guideline: Displaying the work remaining is better than displaying work completed.

Examples:

• Poor: 3 files copied
• Good: 4 files left to copy

Discussion: This guideline is based on the understanding that users are most interested in when the operation will complete. By analogy, how often have you heard restless kids on a long car trip ask , "Mom, how long have we been in the car?" Of course, the common question is, "When will we get there?"

Guideline: Displaying total progress is better than displaying progress on the current step.

Examples:

• Poor: 30 seconds left for the current step
• Good: 10 minutes remaining for all steps

Discussion: Again, this follows from the understanding that users want to know when the operation will complete. Again by analogy, kids anticipating the final destination don't want to hear "It's just five minutes until the next overpass."

Guideline: For "percent complete" information, start at 1%, not 0%.

Discussion: An important secondary function of progress indication is to reassure the user that things are progressing normally and that there is no malfunction that requires user intervention. In user tests of product usability, we have observed that users become anxious when the display remains stuck at 0% for a few seconds.

Guideline: For "percent complete" information, display 100% for less than about 2 seconds.

Discussion: This is another way to avoid alarming users.

Guideline: Show smooth, linear progress rather than erratic bursts of progress.

Discussion: This is another way to avoid alarming users and is also a way to help users estimate completion time. Of course, the smoothness of progress is related to the underlying work being done. One workaround to smooth out progress is to display progress at larger granularity. For example, instead of displaying progress every 1%, update it in 10% increments. When following this approach, there should be a separate animated graphic that indicates that work is being performed, e.g, a graphic of turning gears.

Guideline: For estimates of remaining work, use human-scale precision; don't be over-precise.

Examples:

• Poor: 3 hours and 54 minutes remaining
• Good: about 4 hours remaining
• Poor: 34.5 seconds remaining
• Good: less than 1 minute remaining

Discussion: Most progress indication today can be characterized as overly precise but extremely inaccurate. This guideline addresses one of the those problems. Again, good design can be intuited by analogy to our everyday experience. Which of the following seems more appropriate?: "I'll be home in about 4 hours" or "I'll be home in 3 hours and 54 minutes." There are many phrases that provide useful information to users: less than 1 minute, about 1 minute, between 1 minute and 5 minutes. This last example has the benefit of conveying the degree of accuracy in the estimate.

Externals design: 3. Displaying multi-step progress information

Considerations
This section covers progress indicators that display a list of steps. It is assumed that this is a list of two to ten steps that has been designed to provide useful information. This does not include things like flashing the name of each file as it gets copied during a product installation. Considerations and options include:

• Showing multi-step indication, no steps or showing only the current step.
• Displaying summary steps or providing the option to display more detailed steps.
• Displaying information related to the completion status of each step (for example, success or failure only, other states, and/or additional details such as error message text).
• Using a graphic or a text label to show the status of each step.
• Providing a final completion message, report, or log.

Guidelines
Guideline: Show steps only for work actions, not tool loading user interaction contexts.

Examples:

• Poor: While loading, an application, the following steps are displayed: Loading JVM, Allocating application memory, Verifying network connections
• Good: While loading data into a database, the following steps are displayed: Transforming data, Loading data, Verifying loaded data

Discussion: Showing steps is appropriate only when users have an understanding and interest in the interim steps. This helps them monitor that the operation is proceeding normally and allows users to estimate remaining work in the absence of good estimates from the tool. Generally, users don't know or care about the details related to tool loading operations while the opposite is the case for work actions. (The distinction between tool loading and work actions is explained in the section titled "User interaction contexts".)

Guideline: Define summary steps that are meaningful to a novice user.

Examples:

• Poor: While installing a product, the following steps are displayed: Extracting CAB files to temporary directory, Installing prerequisite components, Updating registry entries
• Good: While installing a product, the following steps are displayed: Preparing for installation, Installing, Cleaning up

Discussion: Part of the justification is the next guideline which caters to more advanced users.

Guideline: Define detailed steps when required.

Examples: See the screen shots shown earlier.

Discussion: This is typically implemented as a Show Details button which toggles the display between summary and advanced steps. This provides more raw data on the steps being completed, for example, listing each file that is copied. In the event of failure, the user can see what steps have completed and at which one the process failed. For reasons not entirely clear, users in usability tests routinely make positive comments when such a feature is available; however, we have yet to see anyone actually use it other than to try it out.

Externals design: 4. Design of user actions

Considerations
The following is a fairly comprehensive list of button labels that can be found on progress indication displays:

• Common actions: Stop, Cancel
• Specialty actions: Next, Retry, Refresh, Show Details, Close

Guidelines
Guideline: Cancel means rollback or undo while Stop means proceed no further.

Discussion: To illustrate the distinction, consider the context of copying a set of files. Clicking a Cancel button should rollback or undo any file copying done to that point and restore the system to the state before the file copy operation started. Pressing the Stop button should stop the operation as soon as feasible; any work done to that point remains. Because of the lack of attention to this guideline in current products, you never know what will happen when pressing a Cancel button.

Guideline: Cancel means canceling the operation, not just dismissing the dialog.

Discussion: To illustrate the distinction, consider a dialog displaying the progress of loading data into a database. Pressing cancel should rollback the operation, not just close the dialog and leave the operation to proceed. One case to consider is when the functionality does not exist to cancel the operation; in that case, perhaps a button labeled Close would better convey this fact. Another case is where the user may wish to close the dialog but not disturb the operation. In this case, again, Close would better convey this fact. Finally, in the case where users have the option to: (1) cancel the operation and/or (2) close the window, suitable button labels are: Cancel Operation and Close.

Externals design: 5. Interaction style
Progress indication displays are typically intrusive windows that are dedicated to showing progress information to the user. This section explores some ways to integrate progress indication into the main display. There are essentially two approaches: embedded progress indicator bar and progressive display.

Embedding progress indicators refers to displaying progress indication on the existing display surface, for example, putting a progress indicator on a splash screen or within a wizard panel or a dialog.

Progressive display refers to displaying the portion of the window that is ready to display and leaving blank or with progress information the areas that are not ready. Examples are in a figure shown earlier where the "Recommended Meeting Time" area shows the word Working and a column with no information. When the information is available those parts of the display are refreshed. With this approach, the user can work with parts of the display and the progress indication is not intrusive. Another example is when Windows Explorer displays the word "searching..." in the search results area.

Implementation
This section covers the practical details of implementing some of the externals designs described previously. The strategies described range from small-scale tips to fundamental architectural decisions that affect the ability to implement progress indication features or behaviors.

Progressive loading
When loading tools or information to the display, it is desirable to avoid explicit implementation of progress indication by following the principle of progressive disclosure. You can architect and design software such that the progress of loading the object of interest can be used as the progress indication. For example, when loading an image, break it up into multiple small chunks and use multithreading to improve responsiveness.

Another instance of this principle is to load visible elements first. For example, to display a large tree in a view, figure out which part of the tree is visible, then load and display that portion of the tree first (Figure 5). Only when users explicitly expand part of the visible tree is the additional data (Figure 6) loaded. Additionally, you can further improve the responsiveness by spawning a separate thread to load the rest of the tree data in the background.

Figure 5. Large tree

Figure 6. Additional data

Another example is related to loading Java-based applications. It takes a while to load the Java Virtual Machine (JVM) before the application can be loaded and executed. While the JVM is being loaded, no progress indication is given by default. One technique to eliminate this problem is to produce a small platform native executable program that first puts up a splash screen and then loads the JVM in the background. Such a program uses minimal overhead, but can dramatically improve the user perception of its responsiveness.

Progress estimation and linearization
Another implementation topic concerns estimating the time to completion as well as having the process progress in a relatively smooth, linear fashion. Accurate progress estimation is often difficult to achieve; in these cases initial estimate and ongoing re-estimates are required. Therefore, consider how accurate an initial estimate can be and whether periodic re-estimates are required. This needs to be balanced with the performance overhead of such estimates.

Something related to the ease of estimation is how linear progress is. Highly linear progress is a goal in its own right for user satisfaction and it also makes progress easier to estimate. A related decision is the size of the update increment (for example, every 1% versus every 10%). A larger increment can reduce the appearance of non-linear progress.

A good example of making progress appear linear is during the product installation process. Improper progress indication can often lead the user to perceieve that the install program is slow. By making sure the progress indicator is updated in a timely and linear fashion, incorrect user perception can be reduced or eliminated. This involves minimal overhead to implement, but the feasibility of such an implementation technique usually affects the product packaging architecture. Therefore, it's a good idea to explore and walk through the installation scenario early so that there is time to decide and react to different packaging requirements.

MVC and large-scale architectural approaches
It is well known that the use of Model-View-Controller (MVC) generally improves the UI implementation of a software system. However, to further improve the responsiveness and performance of a software system, you can introduce a UI specific model in the view architecture layer. This type of UI model can serve as a cache to improve UI responsiveness and performance. When designing the UI specific model, consider its granularity. This is often determined by factors such as the need for action roll back and the feasibility of stopping or canceling an operation.

Finally, entire product-wide architectural decisions can have a progress indication implication. An example in the area of compiler design is the incremental versus batch compilation of programming code. The incremental compilation architecture leads to much better response to user initiated compilation command.

Resources

• There is little published in the usability field on progress indication. The best starting point is Chapter 7 in Jeff Johnson's GUI Bloopers: Don't and Do's for Software Developers and Web Designers . This chapter covers the more general topic of UI responsiveness and provides a full treatment of the topic: background concepts, examples of good and bad designs, and guidelines which address externals design, implementation, and even development process issues. A particular strength is the evocative way the author crystallizes the design issue and incites the reader to action. One technique involves transposing common UI designs into an interpersonal context; this effectively makes the point that developers design and use human-computer dialogs that would be ridiculous if conducted between humans.
  
  
• For general information on usability and IBM, see the IBM Ease of Use site at www.ibm.com/easy.
  
  
• For readers interested in the claim that application designers spend too little attention on understanding and representing the problem to be solved, see Michael Jackson's recent book Problem Frames .
  

Rate this article This content was helpful to me: Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5) Comments?

developerWorks > Web architecture >