Why are progress bars so awful?

Question:

Why are progress bars so awful? I’m not just talking about the Windows
file-copying and move bars which are pretty well known for this but I don’t
think I’ve found a progress bar for anything that’s not inclined to get stuck
at a certain percentage for a long time or jump around or sporadically speed up
and slow down. Why haven’t they figured out a way to be more accurate as of
yet?

In this excerpt from
Answercast #91, I look at the difficulties software designers have in
writing progress bars for copying and installing files.

]]>
<![CDATA[

Awful progress bars

Well, the short answer is that it’s a really, really, really hard problem.

You’d think that it would be fairly simple and straightforward but as it turns out, it’s an incredibly complex thing to try and figure out how much time is really remaining. There are many things that come in to play.

Copying speeds

Most progress bars that we see have to do with file copying of some sort. Not just the progress bars that you’ve referred to, in things like Windows Explorer, but even when you’re running a setup program. What a setup program is spending most of its time doing is copying files.

So, what does the setup program need to figure out just exactly how far along you’ve gotten?

Is it the number of files?

Well, it can’t really be the number of files – because some files are big and some files are small. We can’t really assume that if you’ve copied half of the number of files you’re actually halfway done. If the first half of the files were all small and the second half were much larger, obviously, the second half, based on the number of files, is going to take a lot longer than the first half.

Maybe it has to do with file size?

Well, that kind-of sort-of works. It assumes you can pre-calculate exactly how much file size you’re copying.

In the case of a setup program, that gets really weird because it means the setup program can’t calculate what’s going to be installed… as it goes. To provide an accurate progress bar it would first have to figure out everything that’s going to be installed, without installing it, and then finally kick in the install process and start copying the bits and bytes that are resulting from the choices you made when you setup that program.

Hardware speeds

The problem is; that really isn’t even good enough. Why? Well, the hardware starts to play a role.

Hardware has different speeds. Everything from:

Things taking longer to read on the outside of a CD than from the inside,
to things like information that’s being buffered by various pieces of hardware.

The first one-megabyte of data may go in very quickly. The second megabyte may come out very slow.

Busy computer

But wait, there’s still more. It also depends on what else your computer is doing.

If your computer is accessing the disk while all of this copying is going on? That too is going to cause any calculation that would end the progress bar to, by definition, be wrong – because all of a sudden the copying that the progress bar is assuming is happening by itself, is now being interfered with by whatever else is happening on the machine.

Inaccurate progress bars

So, yes, there are absolutely some progress bars that are abysmal. They are so inaccurate as to be completely useless. You have no idea how many times I’ve spent looking at a “90% done” progress bar that seems to take about 90% of the time to make that last 10% copy.

On the other hand, I have a lot of sympathy for the people who write the software that does that – because it’s just not a simple problem. It is not a simple thing to calculate up front. It’s not a simple thing to keep accurate as the progress is happening.

The best we can hope for is a rough approximation – and ultimately that’s what most progress bars do: kind of an okay job.

(Transcript lightly edited for readability.)

Next from Answercast 91- Why is my Hotmail login not being remembered?

7 comments on “Why are progress bars so awful?”

Well, there is one thing that they could do to improve things… When copying a large (sometimes “huge”) file, many programs appear to not update the progress bar until the copy of that single file is finished. (Even worse are the ones that cause Windows to think the program is “not responding”.) If you know that this file will add X% to the progress, you can certainly update the progress bar as it does the copy.

But, aside from that, I pretty much agree with everything you’ve said. (About the only thing everyone would agree on is that you start at 0% and end at 100% when you’re done. How to calculate “how far are we so far” is up to debate.)

Yes, this is all correct. It is clear, however that some programmers spend a lot more time trying [to make the display as accurate as possible] than others.

For example, 100% should mean DONE. If the progress says 100% for 3 minutes before the install is finished, then some programmer could have done his/her job better.

Similarly, some programs have two bars, “this particular step in the process” and “entire install” shown simultaneously. I’ve always found these to be more informative.

Worst of all are the “entertainment” bars that just cycle to give you something to watch while the install happens but don’t actually provide any information at all about the process.

I’ve experienced the problem in two ways. One is that the copying process seems to have got stuck, as you see X% for very long. Second is that even if you see 100%, the success message does not appear for long.

I’m more concerned about proper copying and status than accuracy. So, I prefer programmers code to indicate through messages whether copying is going smoothly or got stuck. In case it has got stuck, it can restart/refresh itself than just showing X% for long.

Progress bars? Something to watch, I guess. My all-time favorite was this little man climbing up a rope.

I understand and appreciate the difficulties with determining how much longer an installation will take but it’s helpful to know there is x% complete or x% remaining. You can always watch to see how quickly the percentage is changing and judge for yourself about how much longer it might take.
There is one completely ridiculous scenario though: The one where a single progress bar goes from 0% to 100% and then resets to 0% as EACH file is copied. We’ve all seen this. This indicates activity but is absolutely useless as a “progress” bar.

Whilst agreeing generally with the various comments, explanations etc, I wonder what we would say if “progress bars” et sim were removed/omitted?

My experience of writing many programs is that the users, you and I, would demand their reinstatement, on a “better than nothing” basis.

Very helpful article and comments! Takes away a lot of the argggghhh! factor for me.

Thanks