16

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

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

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

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

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

与此相关，我发现重新思考进度条的文章非常有趣。它展示了进度条如何改变对时间的感知，以及您如何使用这些见解来创建似乎更快的进度条。

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

我现在要做的是取上一步所花费的平均时间（按类型分组的步骤并按例如文件大小、事务大小进行标准化）并将这个平均值作为下一步的估计（再次：计算不同的类型和尺寸）。

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

4

7 回答 7

8

While an undergrad, Julian Missig and I ran an experiment not unlike the Harrison et al. paper. As you might expect for a class project, we didn't really get enough data to make strong claims, except that for a 5-second interval, showing no progress bar was actually perceived to be shorter.

So, if the task is likely to take shorter than say 10 seconds, it's best not to show a progress bar at all. That's not to say that you shouldn't show any feedback, but a progress bar is likely to just make it seem slower.

If you're interested, Julian has the paper and poster on his site.

于 2009-03-27T14:48:30.283 回答
7

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

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

只要您的操作所花费的时间很容易测量，这就是有效的。我对在下载进度指示器之类的东西上使用这种方法持怀疑态度，因为网络的速度是完全不确定的。

于 2009-03-27T13:58:29.577 回答
4

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

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

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

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

于 2009-03-27T14:04:36.927 回答
3

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

如果任务花费的时间超过 10 秒，请在任务旁边放置一个进度条，以便他们可以看到工作正在完成并且他们不会过早中止它。

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

个别任务很好，因为过去的表现强烈地预示着未来的表现。下载的前 10 秒可能会显示文件的其余部分需要多长时间。与更新本身相同。

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

进度条并没有对后面的任务需要多长时间做出任何承诺。

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

进度条的问题在于它们是线性移动的。当他们跳跃和口吃时，这对用户来说是非常令人沮丧的——他们实际上用处不大，并且在这种情况下提供了错误的信息。

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

-亚当

于 2009-03-27T15:58:26.653 回答
2

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

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

  • 适用哪些可监控的指标（复制速度、解包速度等）？
  • 该过程的平均最坏情况发生率是多少？

然后你需要建立一个你将要为整个工作做什么的列表，例如：

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

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

微软花了十年时间才把它弄好，所以如果它一开始不起作用也不要太苦恼=)

于 2009-03-27T14:00:41.133 回答
2

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

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

如果我正在等待一项任务，并且它在 10 秒内完成了 50% - 当我需要另外 20 秒才能完成最后 50% 时，我会感到沮丧。

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

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

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

于 2009-03-27T15:41:00.470 回答
2

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

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

我有关于识别速率确定变量的长期运行方法的注释。

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

于 2009-11-25T23:18:55.003 回答