Why the Progress Bar Is Lying to You
popularmechanics.com
Why the Progress Bar Is Lying to You
1–10 of 30 posts
Re: Why the Progress Bar Is Lying to You
#2Re: Why the Progress Bar Is Lying to You
#3Here's the research mentioned in the article: http://www.chrisharrison.net/projects/progressbars/ProgBarHa...
Briefly, they took a process that proceeded linearly, applied an arbitrary function to the current progress, and displayed the result in the progress bar.
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.
Re: Why the Progress Bar Is Lying to You
#4Another 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.
With respect to download progress bars, one approach is to use an exponential moving average:
http://stackoverflow.com/questions/933242/smart-progress-bar...
Re: Why the Progress Bar Is Lying to You
#5I don't expect progress bar to accurately predict time - it's there to show progress. 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.
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.
Re: Why the Progress Bar Is Lying to You
#6Very, 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.
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:
* 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
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.
At the end of the day, the formula I came up with weighted for the following:
* 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
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.
Re: Why the Progress Bar Is Lying to You
#7The 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 every single time.
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.
Re: Why the Progress Bar Is Lying to You
#8It 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.
Re: Why the Progress Bar Is Lying to You
#9I don't expect progress bar to accurately predict time - it's there to show progress . 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. Even for time estimates - I don't sit and watch the bar move from start to e…
Well I guess the implicit assumption is that the rate of progress is relatively constant - hence proportional to time.
Re: Why the Progress Bar Is Lying to You
#10Several 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.