Determining Acceptable Response Delays

转载 2007年09月15日 15:57:00
JavaTM Look and Feel Design Guidelines: Advanced Topics > Part II: Special Topics > 6: Responsiveness > Determining Acceptable Response Delays   Previous NextContents/Index/Search


 

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


相关文章推荐

Time, Delays, and Deferred Work <LDD3> 学习笔记 + jiffies.h 分析

Time, Delays, and Deferred Work  Dealing with time involves the following tasks, in order of...

数据中聚类个数的确定(Determining the number of clusters in a data set)

Intuitively then, the optimal choice of k will strike a balance between maximum compression of the d...

vmware centOS 开机进度条 卡死 Determining IP Information for eth0...

vmware centOS 开机进度条 卡死 Determining IP Information for eth0...

Determining the source of Bug Check 0x133 (DPC_WATCHDOG_VIOLATION) errors on Windows Server 2012

Determining the source of Bug Check 0x133 (DPC_WATCHDOG_VIOLATION) errors on Windows Server 2012 ...
  • v2nero
  • v2nero
  • 2013年04月07日 20:35
  • 1400

CentOs突然启动不了了,“Determining IP information for eth0…”及"Bringing up interface eth0:"解决方法

当CentOs突然启动不了了,在这个进度条进行的时候,按方向键“下”箭头,就能看到信息了。可以查看一下是卡在哪。 1、修改Centos在vmware中的环境配置,在启动时不检查网卡: VM->Remo...

Determining and Monitoring the Connectivity StatusAndroid 电源管理专题之获取和监测网络连接状态

设定周期性的闹铃提醒和后台服务,最常见的用途是定期更新应用程序的数据,从互联网上下载资源,缓存数据或者执行长时间的下载任务。但是如果设备当前没有连接到网络,或者是网络状况不稳定,连接太慢,不能正常完成...
  • G_rrrr
  • G_rrrr
  • 2012年09月20日 10:22
  • 1752

SpringMVC异常报406 (Not Acceptable)的解决办法

使用SpsringMVC,使用restEasy调试,controller请求设置如下:  Java代码   @RequestMapping(value="/list",meth...
  • AinUser
  • AinUser
  • 2017年02月02日 16:47
  • 1224

SpringMVC ajax 请求报错:406 Not Acceptable 的解决办法 使用@ResponseBody注解

在使用ajax请求后台数据的时候,url一直报上面的错误。具体如下: SpringMVC ajax 请求报错:406 Not Acceptable 的解决办法 使用@ResponseBody注解...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Determining Acceptable Response Delays
举报原因:
原因补充:

(最多只允许输入30个字)