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

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

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 2

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/

Answer 3

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