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

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

Comments

Uhmmm.

[Fellon]

Yes it is "that hard".

because

[ILongForDarkness]

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.

Re:because

[NotQuiteReal]

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.

Re:because

[ILongForDarkness]

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

[GoodNewsJimDotCom]

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.

Re:Various reasons

[uncqual]

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.

Can't Go Backwards

[naroom]

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.

Re:Can't Go Backwards

[Agent ME]

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.

Re: Can't Go Backwards

[LesFerg]

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?

Re:Can't Go Backwards

[asliarun]

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.

Re:Can't Go Backwards

[fnj]

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.

Re:Can't Go Backwards

[rioki]

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).

You know what I'd like to see?

[k3vlar]

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.

Re:Crappy software

[nabsltd]

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.