Ask Slashdot: Why Is It So Hard To Make An Accurate Progress Bar? 736
hyperorbiter writes "How come after 25 years in the tech industry, someone hasn't worked out how to make accurate progress bars? This migration I'm doing has sat on 'less than a minute' for over 30 minutes. I'm not an engineer; is it really that hard?"
Re:because (Score:5, Interesting)
Things are asyncronous. You wait for things from disk, ram, user input, over the network etc. How long it will take is non-deterministic. So a task composed of a bunch of these little pieces will be non-deterministic too.
If this is true (which it is), then logic would dictate that it is pointless to represent a progress bar in measurements of time.
Perhaps the larger question is how much longer are we going to continue acting stupid about it, rather than trying to make a clock out of it.
MSIE (Score:5, Interesting)
My favorite terrible progress bar was Internet Explorer, back in its early days of essentially being a renamed version of NCSA Mosaic. When attempting to load a site that wasn't available, the progress bar would slowly creep towards complete, despite the server being completely unresponsive. Then after a long while the browser would give up and stop the progress bar. Why on earth would the progress bar move if the server is completely unresponsive? Who programmed this? I would hope that they, like the inventor of Clippy, suffered a terrible death by fire.
Re:Yes (Score:5, Interesting)
I would have stopped at "yes" without the optimism, and it's not even a platform/processor issue. This is a fundamentally unsolvable thing, since in some cases it reduces to the halting problem [wikipedia.org]. That best you can do is come up with an approximation.
But the approximations will be wrong too. Simple example: write speed. If you write a block to disk, and it fits into the operating system cache, a write happens almost instantly. If the cache is full, you might have to spend tens of seconds waiting before that write occurs. Here's what happens with installers, copy programs, and a large chunk of other things. You write until the cache fills, and those happen at memory speeds. Then, all of the sudden, you grind to a halt when the cache fills. You won't see any progress, sometimes for minutes--it can take a while to chug through gigabytes of random writes. I show an example of this on my blog on Linux [blogspot.com], and this problem gets worse as memory increases, not better.
What does that look like to the user? They get a progress bar, it zooms along for a while, and then it cranks to a halt. Then it hangs for a bit, starts moving, and the whole thing completely changes scale. Does this sound familiar? That's what people complain about, right? You can't make that go away without building a model of the caching mechanism that's more accurate than the cache itself. After all, if you could predict this was coming, the OS could have done a better job scheduling I/O with that information, too. Think about that for a minute: to write a really good progress bar for write operations, you have to do a better job on I/O scheduling than Linux does.
If you step back and say "well let's approximate how long disk I/O takes then and base the bar on that", you'll discover that doesn't work either. There's over a 100:1 difference between the fastest and slowest storage on the market. Good luck modeling that accurately enough to predict the future, too.
Re:Can't Go Backwards (Score:5, Interesting)
I've seen progress bars that go backwards, but it usually indicates reversal of something that is done previously. E.g. in MS Office installer, if you cancel the installation midway through, it will "rewind" the progress bar while cleaning up.
Because it should be a graph. (Score:5, Interesting)
It is hard to make an accurate progress bar because it shouldn't be a bar at all - it should be a graph.
Consider the humble download: bytewise, it might be 97 percent complete, but at the last moment, the bps rate has fallen. With a progress bar indicating a percentage and an estimated time, it might say 97% complete, 3 seconds to go. If the progress indicator was a graph, you could tell that the bps rate has fallen, and that the 3 seconds to go estimate (probably based on a linear extrapolation of progress to date) does not apply.
I have never seen it done though. Partly, because I have never done it.
Re:Sort of. (Score:4, Interesting)
I like the new windows 8 transfer bar that shows instantaneous transfer rates (not average) as it progresses left to right. This gives you a very accurate idea of when the transfer will finish, as it can slow down or speed up based on either network congestion or file size (a bunch of small files transfer slower than few big files.)
Re: Can't Go Backwards (Score:5, Interesting)
We used an industrial strength version of cp in one product, which used DMA for much faster copy, and would write out status every 20 Mb that it could resume from in power loss, and would also, via shared memory variable, publish progress in bytes, all so you could have an accurate progress indicator.
Some people do know what they are doing.
Re:Can't Go Backwards (Score:4, Interesting)
I hate those, they're totally pointless. "I'm possibly doing something, I don't know how much of it I've done, and I don't know when it will end, and I won't show you when I started".
To be honest, progress bars shouldn't be used for indeterminate timescales. If you can guess a time remaining, then say that, as this can be changed, and it is visually more useful than a context-less progress bar that can go in reverse.