Determining Acceptable Response Delays

JavaTM Look and Feel Design Guidelines: Advanced Topics > Part II: Special Topics > 6: Responsiveness > Determining Acceptable Response Delays

---

 

Determining Acceptable Response Delays

The term response delay refers to how long an application takes to acknowledge or fulfill a particular user request. Providing responsiveness in an application depends on achieving response delays that are acceptable to users. The longer an application's response delays are, the more time that its users lose when they make errors--especially if those errors are hard to correct. Anxiety about making time-consuming errors can frustrate users, causing them to work more slowly yet make more errors because they lose their concentration.

Inappropriately short response delays can cause problems, too. For example, one such problem occurs if an application displays and erases a message faster than users can read it. If an application displays and erases successive sets of information faster than users can read them or respond to them, users nonetheless try to keep up. As a result, they make more errors, because the application, though fast, does not keep pace with its users.

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. Table 13 shows the maximum acceptable response delay for typical interface events.

 

In your application, make each response delay as short as possible, unless users need time to see the displayed information before it is erased. Tools for Measuring Response Delays describes techniques for measuring response delays in your application.

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 Table 13. If the application cannot respond within those limits, it probably has one or more general problems--ones caused by a particular algorithm or module. To find such problems, analyze the entire application in detail.

For example, one problem might be that your application requires a more powerful computer system than the one on which it was tested. If so, work with your marketing representative to determine the true minimum system requirements for your application.

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.

---

 

Table 13   Maximum Acceptable Response Delays for Typical Events 

User Interface Events	Maximum Acceptable Response Delay
Mouse click; pointer movement; window movement or resizing; key press; button press; drawing gesture; other user-input event involving hand-eye coordination	0.1 second (100 milliseconds)
Displaying progress indicators; completing ordinary user commands (for example, closing a dialog box); completing background tasks (for example, reformatting a table)	1.0 second
Displaying a graph or anything else that a typical user would expect to take time (for example, 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