Table of Contents
Although highly responsive applications can differ widely from one another, they share the following characteristics:
They keep up with users, even when they cannot fulfill users' requests immediately.
They handle queued requests as users would expect, discarding requests that are no longer relevant and reordering requests according to users' probable priorities.
They let users do other work while long operations proceed to completion— especially operations not requested by users— such as reclaiming unused memory or other "housekeeping" operations.
They provide enough feedback for users to understand what they are doing, and organize feedback according to users' abilities to comprehend and react to it.
They let users know when processing is in progress.
They let users know or estimate how long lengthy operations will take.
They let users set the pace of work, when possible, and they let users stop requested tasks that have started but not finished.
Highly responsive applications put users in control by quickly acknowledging each user request, by providing continuous feedback about progress toward fulfilling each request, and by letting users complete tasks without unacceptable delays.
Even applications with attractive, intuitive user interfaces can lack responsiveness. Typically, unresponsive applications have at least one of the following problems:
They provide late feedback— or no feedback— for users' requests, leaving users wondering what the application has done or is doing.
When performing extended operations, they prevent users from doing other work or cancelling the extended operation.
They fail to display estimates of how long extended operations will last, forcing users to wait for unpredictable periods.
They ignore users' requests while doing unrequested "housekeeping", forcing users to wait at unpredictable times— often without feedback.
You can sometimes possible to improve an application's responsiveness without speeding up the application's code. For tips on how to make such improvements, see the section called “Responding to User Requests”.
Some user interface events require shorter response delays than others. For example, an application's response to a user's mouse click or key press needs to be much faster than its response to a request to save a file. The table below shows the maximum acceptable response delay for typical interface events.
Table 7.1. Maximum acceptable response times for typical events
UI Event | Maximum Acceptable Response Time |
---|---|
Mouse click, pointer movement, window movement or resizing, keypress, button press, drawing gesture, other UI input event involving hand-eye co-ordination | 0.1 second |
Displaying progress indicators, completing ordinary user commands (e.g. closing a window), completing background tasks (e.g. reformatting a table) | 1.0 second |
Displaying a graph or anything else a typical user would expect to take time (e.g. displaying a new list of all a company's financial transactions for an accounting period) | 10.0 seconds |
Accepting and processing all user input to any task | 10.0 seconds |
Make each response delay in your application as short as possible, unless users need time to see the displayed information before it is erased. The acceptable response delay for each event is based on a typical user's sense that the event is a logical point at which to stop or pause. The greater that sense is, the more willingly the user will wait for a response. Verify that your application responds to users' requests within the limits listed in the table above. If your application cannot respond within those limits, it probably has one or more general problems caused by a particular algorithm or module.
Recommendations:
Verify that your application provides feedback within 100 milliseconds (0.1 second) after each key press, movement of the mouse, or other physical input from the user.
Verify that your application provides feedback within 100 milliseconds (0.1 second) after each change in the state of controls that react to input from the user— for example, displaying menus or indicating drop targets.
Verify that your application takes no longer than 1 second to display each progress indicator, complete each ordinary user command, or complete each background task.
Verify that your application takes no longer than 10 seconds to accept and process all user input to any task—including user input to each step of a multistep task, such as a wizard.
If your application takes too long to respond, users will become frustrated. Use these techniques to improve the responsiveness of your application.
Recommendations:
Display feedback as soon as possible.
If you cannot display all the information that a user has requested, display the most important information first.
Save time by displaying approximate results while calculating finished results.
If users are likely to repeat a time-consuming command in rapid succession, save time by faking the command's effects instead of repeatedly processing the command. For example, if a user adds several rows to a table stored in a database, you might display each new row immediately but delay actually creating each new row in the database until the user finished adding all the rows.
Work ahead. Prepare to perform the command that is most likely to follow the current command. That is, use idle time to anticipate users' probable next requests. For example, as the user of an email application reads the currently displayed new message, the application might prepare to display the next new message.
Use background processing. Perform less important tasks —such as housekeeping— in the background, enabling users to continue working.
Delay work that is not urgent. Perform it later, when more time is available.
Discard unnecessary operations. For example, to move back several pages in a web browser, a user might click the browser's Back button several times in rapid succession. To display the final requested page more quickly, the browser might not display the pages visited between the current page and that final page.
Use dynamic time management. At run time, change how your application prioritizes user input and other processing, based on the application's current state. For example, if a user is typing text in one word-processing document while printing another, the word-processing application might delay the printing task if the user shifts to an editing task (such as cutting and pasting text) that requires greater resources.
In your application, display an estimate of how long each lengthy operation will take.
If a command might take longer than 5 seconds to complete its work on an object, allow users to interact with any parts of the object and parts of the application that are not directly affected by the command.
If a command provides lengthy output, show partial results as they become available. Scroll the results (if necessary) until the user moves input focus to a component (e.g. a scrollbar or text area) involved in the scrolling.
You can use two types of visual feedback for operations in your application— pointer feedback and progress animations.
Pointer feedback changes the shape of the pointer. For example, a busy pointer indicates that an operation is in progress and that the user cannot do other tasks. A busy-interactive pointer indicates that an operation is in progress but the window is still interactive.
Figure 7.1. Busy pointer (left) and Busy-Interactive pointer (right)
Progress animations show either how much of an operation is complete, or only that an operation is ongoing. Normally, these take the form of either a progress bar or a progress checklist.
Recommendations:
When displaying a progress animation, open it as soon as possible after you know it is required, and close it automatically as soon as the associated operation is complete.
Use a measured-progress bar if your application can estimate either how long the operation will take, or what proportion of the operation is complete.
If your application can make neither estimate, and the operation only has one step, use an indeterminate-progress bar. For operations with two or more steps, use a progress checklist that dynamically displays a check mark for each completed step.
You can use two main types of progress bars in your application— measured-progress bars and indeterminate-progress bars. There are three types of measured progress bars, but only one type of indeterminate progress bar, which are described in the following sections.
Ensure that a measured-progress bar measures an operation's total time or total work, not just that of a single step. An exception is a progress bar that measures the total time or work of the current step in a progress checklist.
An animation consisting of a bar whose changing length indicates how much time remains in an operation, and text stating how much time remains before the operation will be complete. Time-remaining bars are the most useful type of progress bar.
Figure 7.2. A simple 'time remaining' progress dialog
Use a time-remaining bar if your application will display an initial estimate of an operation's remaining time and then periodically display updated estimates. Each updated estimate should be based on changes that have occurred and that will cause the operation to finish more quickly or more slowly. If the operation will finish more slowly, your application can display an updated estimate that is greater than the estimate previously displayed.
A bar whose changing length represents the completed proportion— typically a percentage— of an operation's total units of work. Proportion-completed bars are less useful than time-remaining bars but more useful than typical-time bars.
Figure 7.3. A simple 'proportion completed' progress dialog
Use a proportion-completed bar if your application will estimate an operation's duration by counting the units of work completed so far, without regard for changes that might affect how quickly the remaining units will be completed. If the operation will process a known number of objects or a set of objects whose total size is known, equate the length of the bar to the total number of units of work that the operation will perform. At least every four seconds, update the bar to show how much of the operation is complete.
A bar whose changing length indicates how much time remains if an operation takes as long as it typically does. Typical-time bars are the least precise type of measured-progress bar, but they are more useful than indeterminate-progress bars.
Figure 7.4. A simple 'typical time remaining' progress dialog
For some operations, you cannot estimate the time remaining or the proportion of work completed. However, if you can estimate the typical time for that operation, you can provide feedback with a typical-time bar.
If your application overestimates the completed amount of work, the length of the bar can indicate "almost complete" until the operation is complete. If your application underestimates how much work is complete, the application can fill the remaining portion of the bar when the operation is complete.
An animated bar indicating only that an operation is ongoing, not how long it will take. One example is the "throbber" in a web browser. Indeterminate-progress bars are the least precise type of progress bar.
Figure 7.5. A simple 'indeterminate time' progress dialog; the slider moves from left-to-right and back again until the operation is complete
Use an indeterminate-progress bar to provide feedback only for operations whose duration you cannot estimate at all.
A progress checklist shows the sequence of stages in an operation but does not display time estimates for those stages.
Figure 7.6. A simple progress checklist dialog
When providing feedback with a progress checklist, you can include a measured-progress bar directly below the checklist. The bar measures the progress of the current step in the progress checklist.
Figure 7.7. A progress checklist dialog with progress bar for current step
To determine which type of visual feedback to provide for a particular operation, consider these factors:
Whether your application can provide an estimate of the operation's progress.
Whether the operation blocks the user from issuing further commands in your application.
Whether your application has a dedicated space, such as a status bar, for indicating the status of operations.
The table below shows which type of feedback to provide for operations that usually take at least 1 second to finish. In the "Appropriate Feedback" column, "Internal progress animations" means progress animations displayed in an application's dedicated status area, and "External progress animations" means progress animations displayed somewhere other than in a dedicated status area— typically, in an alert box.
Table 7.2. Visual feedback types for operations that take at least 1 second
Typical Duration > 5 seconds? | User blocked from issuing further commands? | Application has dedicated status area? | Appropriate feedback |
---|---|---|---|
Yes | Yes | Yes | Internal animation plus pointer feedback |
Yes | Yes | No | Pointer feedback |
Yes | No | Yes | Internal animation |
No | Yes | Yes | Internal animation plus pointer feedback |
No | Yes | No | External animation plus pointer feedback |
No | No | Yes | Internal animation |
No | No | No | External animation |
Recommendations:
Use a busy pointer whenever users are blocked from interaction with your application for 1 second or longer. Display the busy pointer less than 1 second after the operation begins.
If a command will likely take 10 seconds or longer to finish, provide a Stop or Cancel button that lets users terminate the command's processing even if your application cannot undo the command's effects. See the section called “Allowing Interruptions”.
When using an external animation, leave the window containing the animation on-screen for at least 1 second after the operation has completed, with a successful completion message. Change the Stop or Cancel button to an OK button during this period— pressing this button should close the window immediately.
Users sometimes need to stop a command— for example, because it is taking too long. Your application should let users stop commands in progress, even if stopping a command cannot undo or "roll back" all the command's effects.
Recommendations
Place a Stop or Cancel button near the progress animation for the interruptable command.
Label the button Cancel if the whole operation can be cleanly abandoned with no side effects, leaving the system in the state it was in prior to the operation beginning. Terminate the command immediately when the user presses this button.
Label the button Stop if the command can be interrupted, but its effects up to that point cannot (or should not) be reversed. When the user presses this button, open an alert box that warns of the potential side effects of stopping the command. The alert box should have only two buttons: one for continuing the command's processing, and one for immediately terminating it.
Alternatively, you can place the Stop or Cancel button near the control with which the user issued the command that needs to be stopped. Place the button here only if:
There is no progress animation for the command, or
The progress animation is in a window's status area or in another location that lacks space for a Stop or Cancel button.
In the alert box that appears after pressing a Stop button, ensure the message and button labels in the alert box are specific and precise. Ambiguous button labels can cause users to terminate or continue a command unintentionally. For example, use:
Continue deleting files? [Continue Deleting] [Stop Deleting]
rather than
Operation interrupted, continue? [Yes] [No]
since in the latter example, it is not clear whether pressing Yes would continue the operation or continue the interruption (i.e. cancel the operation).