# Feedback

## Characteristics of Responsive Applications

Although highly responsive applications can differ widely from one another, they share the following characteristics:

- They give immediate feedback to users, even when they cannot fulfill their 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 feedback-responding-to-user.

## Acceptable Response Times

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.

## 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.

## Guidelines

- 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.

## Responding to User Requests

If your application takes too long to respond, users will become frustrated. Use these techniques to improve the responsiveness of your application.

## Guidelines

- 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.

## Types of Visual Feedback

You can use two types of visual feedback for operations in your application— pointer feedback and progress animations.

### Pointer Feedback

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.

#### Busy pointer (left) and Busy-Interactive pointer (right)

Busy pointer (left) and busy-interactive pointer (right)

### Progress Animations

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.

### Guidelines

- 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.

#### Progress Bars

For information on different types of progress bars and when to use them see controls-progress-bars.

##### Progress Windows vs. the Statusbar

In an application where the primary windows contain a status bar (which in turn contains a progress bar), it will often be the case that an operation's feedback could be presented in either the statusbar or a progress window. A rule of thumb is to use the statusbar when an operation is expected to take fewer than ten seconds, otherwise use a progress window. However, do consider the following when choosing between the two:

- Opening a new window, particularly when an operation is short, can needlessly disrupt the user's workflow.

- Progress windows can convey more information.

- Multiple progress windows can be open at once, whereas only a single operation can be presented in a statusbar.

- Progress windows provide a Cancel button.

#### Checklist Windows

A checklist window shows the sequence of stages in an operation. See progress-window-checklists.

##### A Checklist Window

A checklist window showing a sequence of steps

## Choosing Appropriate Feedback

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.

## 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

## Guidelines

- 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, which can also be activated by pressing Esc, that lets users terminate the command's processing even if your application cannot undo the command's effects. See feedback-interrupting.

- 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.

## Allowing Interruptions

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.

## Guidelines

- Place a Stop or Cancel button, which can also be activated by pressing Esc, 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).