Progress bars for tasks that can take an indeterminate ammount of time?

Question

Another random question that hit me (I've drank ~9 cups of coffee in the last 5 hours, so sorry...) -- What kind of progress bar would you show a user for a taks that you do don't know how long it would take, but you have a good idea of an "average" time. For example, a task that would usually take around 30 seconds, but you have no way of knowing the progress (other than if its still going on or just failed). What would be the best UX?:

• A progress bar that starts out fast and slows down (maybe with progress being a 1/x style asymptotic curve) that hits 50% around the average task time (the eclipse style guide suggests this).
• A progress bar that progresses, slowly, at a constant rate and maybe hits the "average time" at 15% or something (IE/Firefox do this when initially looking up a domain)
• An indeterminate squiggly bar (macs have this all over the place, newer windows versions have it, too) that just shows some sort of motion without suggesting any progress, a spinner, or some animation that just notifies the user that something is going on.

Would the answer differ if the average time was 10 minutes instead of 30 seconds?

Thanks, Robert

EDIT:

Just to be clear, the question is about progress bars where you have NO idea/indication of how long it will take (for example, executing a task on a remote machine). If you do have some indication of progress, it's often good to use that.

Answer 1

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)

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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:

1. it is not possible to determine how long it will take.

2. it is also not possible to determine if the database server is stuck or hung in a deadlock

3. 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.