进度条的现实时间估计等

Question

我知道我并不是唯一一个不喜欢进度条或时间估算的人，他们在软件中给出了不切实际的估计。最好的例子是安装人员，他们会在10秒内从0％跳到90％，然后花一个小时来完成最后的10％。

大多数时候，程序员只估计完成任务的步骤，然后以百分比显示 currentstep / totalsteps ，忽略了每个步骤可能需要不同时间才能完成的事实。例如，如果将行插入数据库，插入时间可能会随着插入行数的增加而增加（简单示例），或者复制文件的时间不仅取决于文件的大小，还取决于文件的位置。它是多么碎片化。

今天，我问自己是否有人已经尝试过对此进行建模，并且可能创建了一个带有可配置稳健估算器的库。我知道很难给出可靠的估计，因为外部因素（网络连接，用户运行其他程序等）发挥了作用。

也许还有一种解决方案使用分析来设置更好的估算器，或者可以使用机器学习方法。

有人知道这个问题的高级解决方案吗？

---

与此相关，我发现文章Rethinking the progress bar非常有意义。它显示了进度条如何改变时间感，以及如何使用这些洞察力创建似乎更快的进度条。

---

修改： 我可以想办法如何手动调整时间估计，即使使用“估算器库”，我也必须对算法进行微调。但我认为这个问题可以用统计工具解决。当然，估算器会在流程期间收集数据，以便为后续步骤创建更好的估算值。

我现在所做的是采取上一步所采取的平均时间（按类型分组并按例如文件大小，交易规模进行标准化），并将此平均值作为后续步骤的估计值（再次：计入不同类型和尺寸）。

现在，我知道有更好的统计工具来创建估算工具，我想知道是否有人将这些应用于问题。

Answer 1

虽然是本科生，Julian Missig和我进行了一项与哈里森等人不同的实验。纸。正如您对类项目所期望的那样，我们并没有真正获得足够的数据来进行强有力的声明，除了间隔为5秒，显示没有进度条实际上被认为是更短。 / p>

因此，如果任务可能比10秒短，那么最好不要显示进度条。这并不是说您不应该显示任何反馈，但进度条可能会让它看起来变慢。

如果您有兴趣，Julian的网站上有paper和poster。

Answer 2

谢天谢地，我不是唯一的一个！

我不知道有一个处理估算的库，但我个人可以保证你的分析想法。我曾经实现了一个进度条，用于报告长而复杂的文件操作的进度（正在读取，处理几个小文件，然后组合成一个更大的文件）。我让软件跟踪读取，写入和处理所花费的时间，然后相应地调整进度条。程序运行几次后，进度条会像丝绸一样平滑。没有停顿，没有快速的昙花一现。

只要您轻松测量操作所需的时间，就可以正常工作。因为网络速度完全不确定，我会对下载进度指示器这样的方法使用这种方法持谨慎态度。

Answer 3

我不认为问题在于他们估计步骤的数量，因为通常使用错误的“步骤”定义。在你的安装程序示例中，10秒内从0到9％，然后是其余的一小时，我看到当程序员决定计算要复制的文件数而不是字节数时会发生这种情况。

假设有10个文件，其中9个是每个5K（自述文件，许可证，图标等），最后一个是2Gig ISO，好吧，前9个会很快复制，最后一个会很慢！计算文件是错误的，要计算字节数。问题是，如果要计算字节数，则需要实现自己的复制例程，以便在复制大文件期间提供状态更新。实现自己的复制例程真的值得吗？

另一个问题是，安装（像许多其他事情一样）由可能非常深的例程堆栈组成。这些例程可以做很多事情，但它们可能是通用例程，并且它们中没有任何东西能够在更高级别更新某些进度表。您需要重新实现一些常用例程才能获得良好的进度信息。

至于一个强大的估算器，我认为这将非常困难。可以在配置文件中定义特定步骤，但您需要从安装过程的每个部分获得进度更新。此外，做这些事情的时间显然会因机器而异，所以无论如何你都可能会离开。当然，一旦您在特定计算机上完成安装，您可能会估计下次该计算机上的安装。 ; - ）

Answer 4

使用进度条的问题通常是一个过程需要多个不同的步骤。因此，如果我正在为软件更新执行进度对话框，我不会使用单个进度条，而是使用带有复选标记的任务列表，以便用户可以查看当前正在执行的任务。

如果任务超过10秒，则在任务旁边放置一个进度条，这样他们就可以看到工作正在进行，并且不会过早中止。

下载更新
停止运行流程
更新软件
配置软件
重启程序

个人任务很好，因为过去的表现强烈表明未来的表现。下载的前10秒可能会显示文件的剩余时间。与更新本身相同。

较短的进程不需要进度条，因此在一个进程花费10秒或更长时间之前，甚至不要在任何进程上显示进程条。这样，快速系统上的用户只会在每个任务上看到一个复选标记，在慢速系统上，用户会看到复选标记，如果它在某个任务上“停留太久”，则会获得具有实际有用信息的进度条。

进度条没有做出关于后续任务需要多长时间的承诺。

在底部有一个总体“估计剩余时间”，涵盖所有任务的最佳猜测非常有用，但我不会在进度条上显示。

关于进度条的事情是它们意味着线性行进。当他们跳起来并且口吃时对用户来说非常令人沮丧 - 他们实际上没那么有用，并且在这种情况下提供了错误的信息。

为工作选择合适的工具。当它实际上是错误的工具时，会选择进度条太多次。

- 亚当

Answer 5

正如您所说，您可能有100个步骤，但每个步骤将花费不同的时间，具体取决于他们的工作。

一种方法是按任务（删除，更改注册表值，下载，复制文件等）对任务进行分组，并为每个组分配一些关键属性：

• 适用哪些可监控指标（复印速度，拆包速度等）？
• 该流程的平均最差情况是多少？

然后你需要建立一份你将要为整个工作做的事情清单，例如：

1. 解压缩100meg文件（group：unpacking，value：100）
2. 复制120megs（组：复制，值：120）
3. 设置注册表值（组：注册表，值：25）
4. 清理（组：删除，值：100）

因此，您可以根据预设的平均最差情况值计算出总体“估算值”，但准确性的关键是更新每个指标乘数，因为您了解系统可以做多快每项任务。

微软需要花费十年时间才能做到正确，所以如果它最初不起作用，请不要太苦恼=）

Answer 6

另一种（更简单的方法）是填充估计值和用户感知。

大多数进度条对于UI响应性而言比持续时间预测更多：用户需要有反馈确认程序没有停止 - 但不关心完成时间。

如果我正在等待一项任务，并且在10秒钟内完成50％的任务 - 在完成最后50％的任务需要20秒时，我会感到沮丧。

对于同样的任务，如果它在30秒内达到50％，一直持续到60％ - 然后神奇地跳到100％ - 我很惊讶，但并不生气。

如果任务真的很短或完全不可预测，那么一些动画循环也会起作用（浏览器加载图标，iPhone等待动画等等）。

如果您处于真正需要准确性的情况下 - 那么可能值得在代码中花一些时间来提高条形码的可靠性。

Answer 7

我正在使用DREJ对历史进展进行非线性最小二乘回归。 它运作得很好。

我使用数据库表来存储我的历史数据。我根据表格中的最后100个条目重新构建我的估算函数。

我有长期运行方法的注释来识别速率决定变量。

YMMV，但下次估算会考虑到这一点。