Why the Progress Bar Is Lying to You

The file download was a bad example. I understand the file download progress bar to mean how much of the file I have downloaded. No more, no less. Next to that progress bar is the current rate and an estimate of the remaining time. This is not what frustrates me. What frustrates me is a progress bar for an installation task that sits at 99% or 100% for about the same amount of time it took to get there in the first place. I'm skeptical that this kind of problem happens merely because the last task happens to be unpredictably long <i>every single time</i>.<p>I'm betting most of the problems are less about variance in execution time and more about measuring the right tasks at the right granularity.

I don't expect progress bar to accurately predict <i>time</i> - it's there to show <i>progress</i>. The obvious way of implementing it is to split the task into milestones of some sort and display how many are completed. It helps if there's enough milestones so that the bar looks smooth and each one takes roughly the same time, but it doesn't have to be.<p>Even for time estimates - I don't sit and watch the bar move from start to end. I'll look at it for a few seconds, notice how fast it moves, and go do something else. That "psychologically friendly" progress bar that starts slowly and accelerates will do nothing but confuse me.

Another approach is doing away with the progress bar altogether. :-) Apple used to have a boot progress bar. At one point, it worked by keeping how long the _previous_ boot took, then on the next boot it just scaled the progress bar to complete in the same amount of time.<p>With respect to download progress bars, one approach is to use an exponential moving average:<p><a href="http://stackoverflow.com/questions/933242/smart-progress-bar-eta-computation" rel="nofollow">http://stackoverflow.com/questions/933242/smart-progress-bar...</a>

Here's the research mentioned in the article: <a href="http://www.chrisharrison.net/projects/progressbars/ProgBarHarrison.pdf" rel="nofollow">http://www.chrisharrison.net/projects/progressbars/ProgBarHa...</a><p>Briefly, they took a process that proceeded linearly, applied an arbitrary function to the current progress, and displayed the result in the progress bar.<p>The conclusion is that time taken is perceived as less when the progress appears to start slowly and then accelerate, even when the actual total time taken is the same.

Two things I've half seriously considered if I ever need to do a progress bar:<p>1. Make the errors amusing to the user. For instance, if the operation goes over the estimate, go ahead and fill the progress bar to 100%. Then pause a second, and act embarrassed. Change the progress text to something like "Uhm...err...well, this is a bit embarrassing...", then go one to explain it's taking a little longer then expected.<p>Then say something like "OH MY GOD! THAT SPIDER BEHIND YOU IS THE BIGGEST I'VE EVER SEEN!!!". While the user is presumably turned around to check out the giant spider, drop the bar back to 80% or so, and pretend nothing ever happened.<p>2. Report progress bar inaccuracy back to the server, which can look and see if there thing is being consistently off in one direction and make a correction factor available to subsequent users of my software.<p>Might also stats to the user at the end of the operation, telling them things like "This progress bar was off by 10%. The average user's progress bar was off by 20%. Congratulations! Your computer was more reliable and consistent than average!"

Several people [1][2] are saying they think of the progress bar as bring about how much of the work (bytes downloaded, milestones completed) is done. It doesn't matter how you interpret the bar: what matters is what your users will think, and most people see the bar as indicating time.<p>[1] <a href="http://news.ycombinator.com/item?id=3641046" rel="nofollow">http://news.ycombinator.com/item?id=3641046</a><p>[2] <a href="http://news.ycombinator.com/item?id=3641036" rel="nofollow">http://news.ycombinator.com/item?id=3641036</a>

Very, very interesting piece. At my previous job, I spent perhaps an entire month (plus all-nighters) working on a progress bar for the restore page of a backup program. The catch was it was a multi-stage process, and we wanted one and only one bar to represent the progress as smoothly as possible.<p>It's by far one of the most deceivingly difficult problems I've worked on. If anyone cares for more info, this is what the restore process looked like:<p><pre><code> * Single thread that determines the list of files that need to be restored, asynchronously feeding to * Multiple threads that download the files from our servers as ZIP files, then each queue their results to either * A thread pool with a dynamically adjusted number of worker threads for the unzip and decrypt process, extracting the files to their final destination, OR * A different thread pool with a fixed number of threads that does block-level (byte-level differential) restore, which may, when processing a file, need to add files to the first thread mentioned in this list </code></pre> To pull this off, we had to modify the backup process to store enough info to be able to calculate, immediately when the user presses "start restore," the total number of files to be restored, the total number of files to be downloaded (which may be different because ZIP files can contain many small files to minimize latency and overhead, and also because the byte-level differential backup has "backup run" outputs), the total bytes to be restored, the total bytes to be downloaded, the total bytes to be unzipped, etc. etc. etc.<p>The progress bar had to move "smoothly enough" across the entire backup. If you're restoring a hundred and one files, 100 of which are tiny and in a single zip file, and the 101st being a huge differentially-backed-up file, the 101st will take forever and the progress should reflect that. For multi-GB restores, the math could give you 100% (with rounding) for over 10 minutes - need to jam the progress bar at 99% until it's actually done or you'll get complaints. Likewise can't keep it stuck at 0% even if it rounds down to 0% or you'll get complaints.<p>At the end of the day, the formula I came up with weighted for the following:<p><pre><code> * The number of files to be downloaded * The number of files to be restored * The size of the files to be restored * The number of files to be decrypted * The number of files to be differentially restored * The number of files required to differentially restore a single file * The size of the files required to differentially restore a single file * The size of files cached locally that can skip download * The number of files coalesced in a single ZIP archive * The destination drive (externals are slower than internals) * The average download speed </code></pre> Fringe cases such as attempting to restore a single file that was contained in a single ZIP with a hundred other files when tested with a naïve algorithm would end up giving negative progress as if you adjust for the factors listed above you'll end up needing to factor in a (relatively) "huge" number of bytes for download while you're actually only grabbing a single "small" file from the ZIP. Basically, if you adjust the weight of one factor for one case, you'll end up getting non-smooth progress bars for other cases as a result. Took a lot of charting, a lot of trial and error, a lot of user feedback (each time from people that had never participated in the test before to prevent any sort of bias or preconceived notions) to finally get it right. That code is now classified as "no one touch it, no matter how trivial (you think) a bug you found would be fix."<p>So, yes. Progress bars lie. It takes a shitload of work to make pull these lies off, and if they told the truth, your users would really make sure you never heard the end of it. Even if you've already technically done 80% of the work, if only 20% of the required time has elapsed, that progress bar had damn well not say 80%. Or 20% either, for that matter.

Irrelevant Digression:<p>The niftiest progress bar I've ever seen wasn't a progress bar.<p>It was a little morality play.<p>As the game installed a dinosaur slowly bounced across the installer window and _ate_ a hapless user .. who didn't send in his registration card.<p>Still remember that, seventeen years later.

Suggestion: use a succession of checkpoints (including start and finish) to keep track of overall progress. Then create a database of checkpoints along with timestamps (either from historical runs if this is a process that normally runs often for an individual user or from a few sets of lab runs if this is a one time thing like an installation). Now, calibrate the checkpoints to the expected position on an "ideal" progress bar given the historical data and present that to the user.

For anyone who missed it, here's an idea for making progress bars way more fun: <a href="http://xkcd.com/1017" rel="nofollow">http://xkcd.com/1017</a><p>And I'll throw in this one just because it's funny (and quite on-topic): <a href="http://xkcd.com/612/" rel="nofollow">http://xkcd.com/612/</a>

Relevant: <a href="http://www.chrisharrison.net/projects/progressbars/ProgBarHarrison.pdf" rel="nofollow">http://www.chrisharrison.net/projects/progressbars/ProgBarHa...</a>

It seems to me that a modern operating system, which might be used on several different networks throughout the day, and which may offer a variety of different hardware configurations, should be able to provide information to applications which could be useful in calculating this sort of thing. Things like latency, typical data throughput (network and local storage), etc.