performance - 是否有一个普遍可接受的(软)实时延迟定义？

Question

我正试图找到一个基准来衡量用户愿意等待远程服务响应的时间。在我的例子中，响应是非常有用的，但不是对数据输入的业务关键验证。我想 HCI 领域一定已经在这方面做了一些工作。

如果您知道软实时响应的普遍接受的定义，那就太好了，但我也很感激您有充分理由的想法。

克里斯

Answer 1

美国国防部 MIL-STD 1472-F 人体工程标准对最大允许响应时间有最广泛接受的要求(来自表 XXII，第 196 页，时间以秒为单位):

Key Response(按键按下直到出现积极响应，例如“点击”):0.1

Key Print(按键直到字符出现):0.2

翻页(请求结束直到前几行可见):1.0

页面扫描(请求结束直到文本开始滚动):0.5

XY Entry(从字段选择到视觉验证):0.2

功能(从命令选择到响应):2.0

指向(从输入点到显示点):0.2

素描(从输入点到显示线):0.2

本地更新(使用本地数据库更改图像，例如新菜单列表):0.5

主机更新(来自显示缓冲区):2.0

文件更新(以易于访问的形式更改数据在主机上的位置):10.0

查询 - 简单(例如，现有图像的比例变化):2.0

查询 - 复杂(图像更新需要访问主机文件):10.0

错误反馈(从命令到显示常用消息):2.0

如您所见，可接受的响应时间取决于用户正在等待的响应。对于出现下拉菜单之类的东西，最多 0.5 秒。对于浏览器中的整页加载，您希望某些内容在 1.0 秒到 2.0 秒内出现，并在 10.0 秒内加载整页。在所有上述情况下，响应时间越短越好。只有在奇怪的情况下，用户才会反对 0.001 秒的响应时间。

在任何情况下，如果响应时间会大于 0.5 秒，那么您需要提供反馈，例如 throbber 或 hourglass sprite。如果响应时间至少为 5-15 秒(取决于您使用的标准)，请提供进度条。对于进度条，只要您为用户将其设置为“批处理”过程而不是交互式程序，就可以接受非常长的响应时间(按订单或数分钟甚至数小时)。对于用户来说，输入所有内容并等待一个小时比输入四次，每次输入后等待 15 分钟要好得多。

以上列表具有公认的标准。您的用户愿意等待多长时间(例如，在放弃之前)基本上归结为用户进行成本效益分析。我要得到的东西值得等待吗？我的沉没成本是多少？有没有可以做得更好的替代方案(例如，另一个网站)？我可以在等待的同时做其他事情以充分利用我的时间吗？但是，无论用户愿意做什么，您都可以打赌他们会厌恶比上述标准更大的延迟。