Ask Slashdot: Why Is It So Hard To Make An Accurate Progress Bar?

← Back to Stories (view on slashdot.org)

Ask Slashdot: Why Is It So Hard To Make An Accurate Progress Bar?

Posted by Soulskill on Tuesday February 12, 2013 @04:14PM from the this-post-is-98%-complete dept.

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?"

28 of 736 comments (clear)

Min score:

Reason:

Sort:

it's because by Anonymous Coward · 2013-02-12 16:17 · Score: 5, Funny

Comment loading ...
Uhmmm. by Fellon · 2013-02-12 16:17 · Score: 5, Insightful

Yes it is "that hard".

--
I did it all for the penguins!
Yes. by kc9jud · 2013-02-12 16:17 · Score: 5, Funny

Yes it is. And to be fair, it's a lot more accurate than Nostradamus ever was.
because by ILongForDarkness · 2013-02-12 16:18 · Score: 5, Insightful

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.
1. Re:because by geekmux · 2013-02-12 16:27 · 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.
2. Re:because by NotQuiteReal · 2013-02-12 16:38 · Score: 5, Insightful
  
  Plus, you are lucky even get a "guesstimate bar". Showing progress with bad estimates is more reassuring than just a "working on it spinner". Either is an order of magnitude better than an unresponsive GUI because the programmer didn't put that stuff in another thread.
  
  Personally, I like the "list of what I am going to do + check them off as they are done" approach, if the "progressing task" is of varying descriptions.
  
  That said, for some tasks, you have to consider the "Heisenberg effect" a bit, depending on the work being done - do you want your progress bar pestering the "worker" for progress reports all the time, or just doing its job.
  
  --
  This issue is a bit more complicated than you think.
3. Re:because by ILongForDarkness · 2013-02-12 16:53 · Score: 5, Insightful
  
  The list/status bar solution is nice for another reason: if your program does hang your users know where in the process it happened. You get more useful feedback from the users, sometimes they might be able to troubleshoot it themselves (oh it is dying when connecting to my fileserver, perhaps I"m not connected to the network). Heck it is useful for course grained optimization you see the logical steps that take the most time and can drill down into speeding them up as much as possible.
Various reasons by GoodNewsJimDotCom · 2013-02-12 16:19 · Score: 5, Insightful

One reason is the progress bar starts out as just a generic tool to show that your loading hasn't froze. At first it is parsed correctly with the elements to be loaded, but as scope increases and more things load, it can get sketchy later on.

Another reason is it is difficult to estimate time left. If you look at some old FTP programs, they'd estimate the rest of the download's time based on how fast the previous has taken. Future lag, fragmented files, etc aren't taken into consideration.

There's a bunch more reasons, but namely the progress bar's main purpose is to show you that the whole system isn't locked up, which they've been doing well for the past 30 years or so.

--
God spoke to me
1. Re:Various reasons by uncqual · 2013-02-12 17:07 · Score: 5, Insightful
  
  And a spinning asterisk or swirlie does that fine, without implying anything about "progress" or "time left".
  The spinning asterisk or swirlie just tells you that the thread updating the asterisk or swirlie hasn't frozen -- it often doesn't tell you anything about the underlying activity the user is waiting for.
  
  --
  Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading /.
Re:no, it's easy. by dotHectate · 2013-02-12 16:27 · Score: 5, Funny

You know someone is going to take your suggestion literally as a tutorial on how to implement a progress bar - later they'll come back with some mystical crash always happening at 0%.

--
Patience is a virtue, but haste is my life.
MSIE by Anonymous Coward · 2013-02-12 16:29 · 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.
Can't Go Backwards by naroom · 2013-02-12 16:30 · Score: 5, Insightful

Consider this: Once you've put progress on a bar, you can't take it off. Suppose you start a process that should take 20 minutes, and do the first 5 minutes, progress is now at 25%. But then, partway through, something unexpected happens and you realize the process is actually going to take 40 minutes. You can't take the progress "back" now, that would disorient the user. So you have to rescale the remainder of the bar.
1. Re:Can't Go Backwards by citizenr · 2013-02-12 16:35 · Score: 5, Informative
  
  This is why you put two progress bars. One general and one for sub processes.
  http://www.codeproject.com/KB/progress/SplitProgressBar/SplitProgressBar.gif
  
  --
  Who logs in to gdm? Not I, said the duck.
2. Re:Can't Go Backwards by Agent+ME · 2013-02-12 17:06 · Score: 5, Insightful
  
  What? Why the fuck would a progress bar go backwards? A progress bar shouldn't be pegged to the fraction of time of the job done. It should be pegged to the actual progress. If progress starts going slower, then the progress bar should start moving slower.
3. Re:Can't Go Backwards by The+Snowman · 2013-02-12 17:08 · Score: 5, Funny
  
  Yes and it's those--as well as those that dance left and right for no damn reason--that really piss me off.
  You mean like this one? http://xkcd.com/612/.
  
  --
  24 beers in a case, 24 hours in a day. Coincidence? I think not!
4. Re: Can't Go Backwards by LesFerg · 2013-02-12 17:16 · Score: 5, Insightful
  
  Realistically a large IO bound task is something you hand off to low-end process to get it done as fast as ppssible. Would you over-ride the O/S to transfer that 10gigs in 100 meg blocks and report each bit back to your high level UI so that th progress bar is accurate?
  
  --
  If I had a DeLorean... I would probably only drive it from time to time.
5. Re:Can't Go Backwards by asliarun · 2013-02-12 18:22 · Score: 5, Insightful
  
  To put it another way, it is impossible to make an accurate progress bar because it is impossible to predict the future. That's all.
  You can make assumptions, extrapolation, use past performance,etc but you are never going to get it accurate.
  This is like getting pissed at your GPS because it told you you will reach in 22 mins when it actually took you 35.
  It is either a dumbass expectation from the user or a dumbass design decision. You might have as well used an hourglass so the user could spend their time shaking it trying to get the sand to fall faster.
6. Re:Can't Go Backwards by ibennetch · 2013-02-12 18:29 · Score: 5, Funny
  
  I think I prefer going backwards to what I once saw on (what I remember as) a Microsoft Office installation, probably 15 years ago. The progress bar ever so slowly crept upwards...98, 99, 100% done...then 101, and so on. It finally locked up somewhere after 140%.
7. Re: Can't Go Backwards by Impy+the+Impiuos+Imp · 2013-02-12 18:35 · 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.
  
  --
  (-1: Post disagrees with my already-settled worldview) is not a valid mod option.
8. Re:Can't Go Backwards by fnj · 2013-02-12 20:07 · Score: 5, Insightful
  
  Suppose a bar can never back up. Then its speed may vary enormously, making the visual how-done-am-I representation valueless.
  It is HARD.
  Define "fraction of job time done" numerically. Suppose you have to download 100 packages and then install them. How many % of the total should the download represent? Does the guy have cable or dialup? And how many % does the install represent? Does he have a slow USB hard drive or a ridiculously fast SSD? What if the first file downloads at 1 MBps and the 17th one at 139 Bps? I've seen that happen (varying server load, per-file mirrors). Which installs faster, a package containing 250 files totaling 10 MB, or a package containing 10 files totaling 100 MB - hint; it depends.
  Generally, might as well show a rotating propeller or a cylon helmet moving dot, neither of which has a beginning or an end. Just an indication that something is going on, and the system doesn't look frozen. Maybe a couple of numbers under it showing # files done out of # total files.
9. Re:Can't Go Backwards by rioki · 2013-02-12 20:46 · Score: 5, Insightful
  
  What I like is the Step X of Y types of progress indicators. Sure step 5 of 12 might take way longer then the rest but at least it is honest. It also helps to tell the user what it is currently doing. You know that downloading drivers may take a while when the internet is slow (or down).
10. Re:Can't Go Backwards by telchine · 2013-02-12 23:08 · Score: 5, Funny
  
  Sure step 5 of 12 might take way longer then the rest but at least it is honest. It also helps to tell the user what it is currently doing.
  Reticulating splines?
Physics! by ignavus · 2013-02-12 16:42 · Score: 5, Funny

You can work out where you are (% completed) or how fast you are going (rate at which the progress bar is growing), but not both at the same time.
It's simple quantum mechanics.

--
I am anarch of all I survey.
Re:sometimes by PlusFiveTroll · 2013-02-12 17:03 · Score: 5, Informative

The Windows8/Server 2012 dialog is much better in this case.
http://encosia.com/blog/wp-content/uploads/2012/09/windows-8-file-copy-dialog.png
It draws a graph showing you the current rate, in which you can see the average over time.
Re:Crappy software by Jiro · 2013-02-12 17:11 · Score: 5, Informative

The progress bar on the HTTP download doesn't show the amount of remaining time in the bar. It shows the number of bytes remaining in the bar; the number of bytes remaining can't go into reverse. The time remaining is showed as a numeric value for how long it would take assuming the speed is the same as the speed so far; if the transfer suddenly slows down, this value can go into reverse.
You know what I'd like to see? by k3vlar · 2013-02-12 17:38 · Score: 5, Insightful

You know what I'd like to see more than a working progress bar? A "Cancel" button that actually stops the f*%! process! .
I don't want to finish the sub-process I'm currently doing (which has probably stalled)... just FREAKING STOP.

If you (programmer) want to close connections, or save the changes to the disk, do it in the background. Making me sit there for another 10 minutes while you're "cancelling..." is not helpful. I will force close your program. Failing that I will hard-reset the computer. Seriously.

--
Unlike porn, which yada yada rimshot hey-ooh!
Re:Crappy software by nabsltd · 2013-02-12 17:38 · Score: 5, Insightful

Give this man some upward moderation.
The problem is that the question is wrong. It's trivial to make a progress bar...just sum up all the things you have to do, and move the bar each time a "thing" is done, rounding to the nearest pixel. It doesn't matter if the "thing" is a byte to copy, a file to install, or any generic task. As long as you can add one to a counter each time you have done another "thing", you can then display it graphically.
The actual complaint is about displaying accurate time remaining to complete the task, which really has nothing to do with the display of the progress bar. Instead, it involves guessing about how long each remaining "thing" will take to complete, and then displaying that sum of those times. This is hard because no matter how accurate the data used to make the guess, something outside the control of the program can disrupt the processing.
We will have .... by PPH · 2013-02-12 17:59 · Score: 5, Funny

... a functional progress bar in 5 years.
No, wait. It seems to have stalled.

--
Have gnu, will travel.