Usability studies (I can't find the pdf) showed that at the exact same duration, loading bars with different patterns (exponential, linear, logaritmig), the ones that "felt faster" where the ones that completed exponentialy. By that I mean, the ones that start slow, but get faster as time passes.
What I normally do is:
If I know the average time the process can take, alocate for a little more, and go slow until last 20%-10%, then the progress bar speeds up and catches up with the real progress, with such a timing that the process ends at the moment that the bar has the fastest speed.
If I don't know how long it could take, I measure many times to have the ballpark (seconds? minutes? hours?)
If its a repetitive operation with little variation between runs, I take into account the last runs time.
If its a long running operation or with high variability, I don't use a progress bar, but rather an animation to show that I'm working.
Just don't lie to your users. Never tell them it will be over in a minute and half an hour later be still running.
Definitely the Barber pole progress bar. I think it's the standard on Mac Human Interface Guidelines (HIG). I am sure similar "undefined" progress bars exists for other platforms as well.
I would also put a textual progress indicator (like the amount of bytes transferred, for example). "Guessing" a percent complete can be feasible, but you should definitely be very sure about the average time, and its standard deviation, otherwise you will get a lot of angry users pissed off and clicking cancel because your progress is stuck at 99% since one hour. That would be very annoying for them and for your software's reputation.
It doesn't matter if the progress bar moves at a precisely constant rate. Indeed, taken literally, that would surely be almost impossible. How would you know in advance what factors might come into play to speed up or slow down real progress?
So I pick any convenient measure of how much work there is to be done and track percentage complete. If that's number of bytes to transmit, number of records to process, number of foos to bar, whatever. So sure, sometimes it starts out fast and then slows down or vice versa. But all that really matters is that as long as the process is working toward completion, it continues to move.
I think the hard problem is when you don't know in advance ANY reasonable measure of the amount of work to be done. Like, you have to process a set of records, but you have no easy way to get the record count other than reading all the records and counting them, and once you've done that, you might as well just have processed them along the way. In those cases, instead of a progress bar I usually resort to displaying a "progress count": Like "1 record processed", "2 records processed", etc. At least the user can see it's moving, and after he's done it a few times he probably has a ballpark idea of how far it's going to go, i.e. it's in the tens of thousands versus the hundreds of thousands or whatever.
I'm working on a system now that routinely uses an approach I find rather lame: They just attach completely arbitrary percentages to any convenient check point. Like if a function reads a bunch of data, sorts it, formats it, and prints it, they'll say 25% when reading is done, 50% when sorting is done, 75% when formatting is done, and then 100% when printing is done. I suppose it's better than nothing.
I've never seen it, but how about a sliding window over a progress bar, so that you can see if the work is progressing, at what rate, but the end keeps being that bit further off. Sort of moonwalking for progress bars. You'd need to make the animation distinctive so that the user can tell that new blobs are being added, and the oldest ones are sliding off to the left. The sliding stops when the program determines that it knows the distance to the end of the task.
==============================================================================
Executing command xyz..
Started: 10:30 AM (usually requires about 20 minutes to complete)
Status: 10:35:10 AM.. Still working...{this line needs to update frequently}
[Send to background] [Cancel]
==============================================================================
The best strategy is to be plain, simple and honest. Tell what's known, and set the expectation right.
If it can take a long time, it's better to be verbose, such as:
==============================================================================
Executing command xyz..
Started: 10:30 AM (usually requires about 20 minutes to complete)
Status: 10:35:10 AM.. Still working...{this line needs to update frequently}
[Send to background] [Cancel]
==============================================================================
I have seen such verbose descriptions in some large installers somewhere; can't recall exactly where but it was probably operating system or server software. Phrases like "This task may take several minutes to complete" are also not uncommon in installers.
If the task usually takes a short time to complete (say 30 seconds), but may occasionally take longer, it is probably best to show only an indicator that the task is not hung or otherwise dysfunctional, if and only if that can be ascertained. i.e., if you can tell for sure that the task isn't dead or hung. If you are as uncertain as the end user as to what's going on with the task, it is best to just show a background option (to let the user do something else while it goes on), or a cancel option (if the task can be canceled).
A typical example would be a database admin console that allows the user to execute an SQL query on a database. Typically, queries are satisfied in a matter of seconds, but infrequently, there are cases when the query requires large cartesian products, creation of multiple temporary tables, waiting for locks to be cleared, etc that can take several minutes. The admin console software has no means of determining how long the query may take, because all information about the query's expected execution time can only be known by the database server. In this case:
it is not possible to determine how long it will take.
it is also not possible to determine if the database server is stuck or hung in a deadlock
worst of all, you can't cancel the query execution.
In this case, the only good thing would be to let the user "background" the task.
任务或过程花费多长时间无关紧要，当任务的 Y 部分完成时，可以简单地将进度条的值增加 X 量，或者你已经深入了解这个过程了。 （即上传 100 KB 文件时每处理 5 KB）
Why not increment the progressbar as you complete tasks in a method?
How long the task or process takes is irrelevant, it's possible to simply increase the progressbar's value by X amount when Y part of the task is complete, or you're Z far into the process. (i.e. every 5 kilobytes that are processed in 100 kilobyte file upload)
发布评论
评论（7）
可用性研究（我找不到 pdf）表明，在完全相同的持续时间内，加载具有不同模式（指数、线性、对数）的条形图，那些“感觉更快”的条形图比那些完成指数的条形图。我的意思是，那些开始缓慢，但随着时间的推移变得更快的。
我通常做的是：
只是不要对你的用户撒谎。 永远不要告诉他们一分钟后就会结束，半小时后仍然在运行。
Usability studies (I can't find the pdf) showed that at the exact same duration, loading bars with different patterns (exponential, linear, logaritmig), the ones that "felt faster" where the ones that completed exponentialy. By that I mean, the ones that start slow, but get faster as time passes.
What I normally do is:
Just don't lie to your users. Never tell them it will be over in a minute and half an hour later be still running.
我正在成为 Mac 和 Vista 风格的旋转圆圈的忠实粉丝，它可以在不设定误导用户期望的情况下指示进度。
XKCD漫画
http://xkcd.com/612/
I am turning into a huge fan of the Mac and Vista style rotating circle that indicates progress without setting misleading user expectations.
XKCD comic
http://xkcd.com/612/
绝对是理发杆进度条。我认为这是 Mac 人机界面指南 (HIG) 上的标准。我确信其他平台也存在类似的“未定义”进度条。
我还会添加一个文本进度指示器（例如传输的字节数）。 “猜测”完成的百分比是可行的，但您绝对应该非常确定平均时间及其标准偏差，否则您会得到很多愤怒的用户，他们会生气并单击“取消”，因为您的一小时以来进度一直停留在 99%。这对他们和你的软件的声誉来说都是非常烦人的。
Definitely the Barber pole progress bar. I think it's the standard on Mac Human Interface Guidelines (HIG). I am sure similar "undefined" progress bars exists for other platforms as well.
I would also put a textual progress indicator (like the amount of bytes transferred, for example). "Guessing" a percent complete can be feasible, but you should definitely be very sure about the average time, and its standard deviation, otherwise you will get a lot of angry users pissed off and clicking cancel because your progress is stuck at 99% since one hour. That would be very annoying for them and for your software's reputation.
进度条是否以精确恒定的速度移动并不重要。事实上，从字面上看，这几乎是不可能的。您如何提前知道哪些因素可能会发挥作用，加速或减缓实际进展？
因此，我会选择任何方便的方法来衡量需要完成多少工作并跟踪完成百分比。如果这是要传输的字节数、要处理的记录数、要处理的 foo 数，等等。当然，有时它开始很快，然后减慢，反之亦然。但真正重要的是，只要该过程正在努力完成，它就会继续前进。
我认为困难的问题是当你事先不知道要完成的工作量的任何合理衡量标准时。就像，您必须处理一组记录，但是除了读取所有记录并计算它们之外，您没有简单的方法来获取记录计数，一旦完成，您可能还只是沿着方式。在这些情况下，我通常不显示进度条，而是显示“进度计数”：例如“已处理 1 条记录”、“已处理 2 条记录”等。至少用户可以看到它正在移动，并且在完成后有几次他可能对要走多远有一个大概的想法，即是数万还是数十万或其他什么。
我现在正在开发一个系统，该系统通常使用一种我认为相当蹩脚的方法：它们只是将完全任意的百分比附加到任何方便的检查点。就像一个函数读取一堆数据，对其进行排序、格式化并打印它一样，当读取完成时，他们会说 25%，当排序完成时，他们会说 50%，当格式化完成时，他们会说 75%，然后当完成时，他们会说 100%。打印完成。我想这总比没有好。
It doesn't matter if the progress bar moves at a precisely constant rate. Indeed, taken literally, that would surely be almost impossible. How would you know in advance what factors might come into play to speed up or slow down real progress?
So I pick any convenient measure of how much work there is to be done and track percentage complete. If that's number of bytes to transmit, number of records to process, number of foos to bar, whatever. So sure, sometimes it starts out fast and then slows down or vice versa. But all that really matters is that as long as the process is working toward completion, it continues to move.
I think the hard problem is when you don't know in advance ANY reasonable measure of the amount of work to be done. Like, you have to process a set of records, but you have no easy way to get the record count other than reading all the records and counting them, and once you've done that, you might as well just have processed them along the way. In those cases, instead of a progress bar I usually resort to displaying a "progress count": Like "1 record processed", "2 records processed", etc. At least the user can see it's moving, and after he's done it a few times he probably has a ballpark idea of how far it's going to go, i.e. it's in the tens of thousands versus the hundreds of thousands or whatever.
I'm working on a system now that routinely uses an approach I find rather lame: They just attach completely arbitrary percentages to any convenient check point. Like if a function reads a bunch of data, sorts it, formats it, and prints it, they'll say 25% when reading is done, 50% when sorting is done, 75% when formatting is done, and then 100% when printing is done. I suppose it's better than nothing.
我从来没有见过它，但是在进度条上设置一个滑动窗口怎么样，这样你就可以看到工作是否正在进展，进展速度如何，但最终的结果仍然有点遥远。进度条有点像太空漫步。您需要使动画与众不同，以便用户可以知道正在添加新的斑点，并且最旧的斑点正在向左滑动。当程序确定它知道到任务结束的距离时，滑动就会停止。
I've never seen it, but how about a sliding window over a progress bar, so that you can see if the work is progressing, at what rate, but the end keeps being that bit further off. Sort of moonwalking for progress bars. You'd need to make the animation distinctive so that the user can tell that new blobs are being added, and the oldest ones are sliding off to the left. The sliding stops when the program determines that it knows the distance to the end of the task.
最好的策略是平实、简单和诚实。讲述已知的情况，并设定正确的期望。
如果可能需要很长时间，最好是详细一点，例如：
我在某处的一些大型安装程序中看到过如此详细的描述；记不清具体位置，但可能是操作系统或服务器软件。 “此任务可能需要几分钟才能完成”之类的短语在安装程序中也并不罕见。
如果任务通常需要很短的时间才能完成（例如 30 秒），但有时可能需要更长的时间，则最好仅显示任务未挂起或出现其他功能障碍的指示符（当且仅当可以确定这一点时）。即，如果您可以确定任务没有终止或挂起。如果您和最终用户一样不确定任务的进展情况，最好只显示一个后台选项（让用户在任务继续时执行其他操作）或取消选项（如果任务可以执行）被取消）。
一个典型的例子是数据库管理控制台，它允许用户在数据库上执行 SQL 查询。通常，查询会在几秒钟内得到满足，但在极少数情况下，查询需要大型笛卡尔积、创建多个临时表、等待清除锁等，这可能需要几分钟的时间。管理控制台软件无法确定查询可能需要多长时间，因为有关查询预期执行时间的所有信息只能由数据库服务器知道。在这种情况下：
无法确定需要多长时间。
也无法确定数据库服务器是否卡住或挂起于死锁
最糟糕的是，您无法取消查询执行。
在这种情况下，唯一的好处就是让用户“后台”执行该任务。
The best strategy is to be plain, simple and honest. Tell what's known, and set the expectation right.
If it can take a long time, it's better to be verbose, such as:
I have seen such verbose descriptions in some large installers somewhere; can't recall exactly where but it was probably operating system or server software. Phrases like "This task may take several minutes to complete" are also not uncommon in installers.
If the task usually takes a short time to complete (say 30 seconds), but may occasionally take longer, it is probably best to show only an indicator that the task is not hung or otherwise dysfunctional, if and only if that can be ascertained. i.e., if you can tell for sure that the task isn't dead or hung. If you are as uncertain as the end user as to what's going on with the task, it is best to just show a background option (to let the user do something else while it goes on), or a cancel option (if the task can be canceled).
A typical example would be a database admin console that allows the user to execute an SQL query on a database. Typically, queries are satisfied in a matter of seconds, but infrequently, there are cases when the query requires large cartesian products, creation of multiple temporary tables, waiting for locks to be cleared, etc that can take several minutes. The admin console software has no means of determining how long the query may take, because all information about the query's expected execution time can only be known by the database server. In this case:
it is not possible to determine how long it will take.
it is also not possible to determine if the database server is stuck or hung in a deadlock
worst of all, you can't cancel the query execution.
In this case, the only good thing would be to let the user "background" the task.
为什么不在方法中完成任务时增加进度条？
任务或过程花费多长时间无关紧要，当任务的 Y 部分完成时，可以简单地将进度条的值增加 X 量，或者你已经深入了解这个过程了。 （即上传 100 KB 文件时每处理 5 KB）
Why not increment the progressbar as you complete tasks in a method?
How long the task or process takes is irrelevant, it's possible to simply increase the progressbar's value by X amount when Y part of the task is complete, or you're Z far into the process. (i.e. every 5 kilobytes that are processed in 100 kilobyte file upload)