Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted about a year and a half ago | from the this-post-is-98%-complete dept.

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

cancel ×


it's because (5, Funny)

Anonymous Coward | about a year and a half ago | (#42879229)

Comment loading ...

Can't Go Backwards (5, Insightful)

naroom (1560139) | about a year and a half ago | (#42879363)

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 (4, Insightful)

Jafafa Hots (580169) | about a year and a half ago | (#42879377)

I've seen some progress bars that do exactly that - go backwards.

Re:Can't Go Backwards (2)

UltraZelda64 (2309504) | about a year and a half ago | (#42879475)

Yes and it's those--as well as those that dance left and right for no damn reason--that really piss me off.

Re:Can't Go Backwards (0)

Anonymous Coward | about a year and a half ago | (#42879543)

Yes it can. Just try a full-compile using ISE Eiffel :)

Predicting the future is hard (0)

Anonymous Coward | about a year and a half ago | (#42879233)

even on a small scale

Not hard at all (1)

Zynder (2773551) | about a year and a half ago | (#42879315)

The computer is able to measure it's data throughput, read/write times, etc. Whether programmars actually do this measurment I don't know. But if the computer knows how fast it is reading or writing a disk or transferring over the LAN then there is no reason why it shouldn't be able to make those calculations. Even if the environment changes from task swapping or adding overhead or whatever then the measurement, being dynamic, can be recalculated on the fly and the 'finish time' updated accordingly.

Mandatory Car Analogy: I know that if my speedometer indicates 60 miles/hour, that in one minute I will have travelled one mile. That's predicting the future son!

Re:Not hard at all (1)

LiENUS (207736) | about a year and a half ago | (#42879433)

So if you're transferring a file over the network maxing it out and you know it will take 10 minutes but then your wife starts streaming video over the network, how do you predict that at the start of the transfer? It's pretty damn difficult to predict the future man.

Mandatory Car Analogy: How long will it take you to drive 60 miles if you're going 60 miles/hour now? (what you don't know is that in two minutes someones going to cut you off and you'll end up rear ending them)

Re:Not hard at all (2)

Lisias (447563) | about a year and a half ago | (#42879469)

The programmer does what the boss tell him to do.

The Progress Bar loses his functionality when Windows 96 start to use it just as something that moves on the screen. No real processing is associated with the Bar or Animation activity!

On the other hand, there are programs that do it right! Unfortunately, one of the best examples I have is a console Linux program: The Midnight Commander - so, very few people nowadays is exposed to a correctly written Progress Status notifier mechanism...

Re:Not hard at all (1)

fsterman (519061) | about a year and a half ago | (#42879571)

Mod parent up: progress bars make for simple bullet point on a requirements spec, but defining one is takes an entire sentence.

Sort of. (1)

MrEricSir (398214) | about a year and a half ago | (#42879483)

That's all very true in the world of single tasking. Remember the days of DOS? When a file transfer said it would take 10 minutes, it took 10 minutes, dammit!

But once you enter the world of multitasking, your program has no idea what slice of the CPU pie it's going to get in the future. And surprise, in every modern OS, those file transfer time estimates tend to be significantly off.

Re:Not hard at all (0)

Anonymous Coward | about a year and a half ago | (#42879523)

Even if the environment changes from task swapping or adding overhead or whatever then the measurement, being dynamic, can be recalculated on the fly and the 'finish time' updated accordingly.

And how does that look any different than what happens now?

Re:Not hard at all (1)

stanlyb (1839382) | about a year and a half ago | (#42879659)

But your car is simply UNABLE to run backward or left, without pause, ain't so? Oh wait, actually it could, if you are hit by meteor :D

Uhmmm. (5, Insightful)

Fellon (1525917) | about a year and a half ago | (#42879235)

Yes it is "that hard".

Yes. (5, Funny)

kc9jud (1863822) | about a year and a half ago | (#42879237)

Yes it is. And to be fair, it's a lot more accurate than Nostradamus ever was.

because (5, Insightful)

ILongForDarkness (1134931) | about a year and a half ago | (#42879241)

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 (4, Insightful)

eksith (2776419) | about a year and a half ago | (#42879259)

This. Also, there may be other applications/processes that may start up, suddenly demand resources or jump in priority, which inevitably result in a progress bar going backwards.

Re:because (0)

Anonymous Coward | about a year and a half ago | (#42879373)

So the progress is being unmade ?

Like its going ahead three steps and then two steps back again ? :P

Re:because (1)

Anonymous Coward | about a year and a half ago | (#42879649)

Think of it more like you are driving your car with the gps on, and it says you are an hour away from your destination. Suddenly, 5 miles ahead of you a crash occurs. The resulting traffic delays you half an hour, so the original estimate turns out to be wrong.

Re:because (5, Interesting)

geekmux (1040042) | about a year and a half ago | (#42879329)

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.

Re:because (2)

marnues (906739) | about a year and a half ago | (#42879353)

As long as people want to know how much longer it takes. We operate in time. This is why progress bars are so prevalent even though they aren't accurate.

Re:because (0)

eksith (2776419) | about a year and a half ago | (#42879427)

People don't work on logic... especially when we're impatient :/

Honestly, I would welcome the demise of the progress bar if it were replaced with an activity animation along with Andy Rooney quotes.

Re:because (2)

ILongForDarkness (1134931) | about a year and a half ago | (#42879465)

Well we do this in the real world too though say asking the mechanic when you can get your car back. Just asking wastes resources and means the answer is "later than it would have been before you interrupted". But even with a rough estimate is usually pretty good (except when it isn't and then it really isn't like installing apps and seeing 10min go to 2hrs) and can adapt to changing data. I think the problem is expectations: we want exact answers which is understandable if you are waiting for something (I work with radiation simulation software you can be waiting for 20min for a result if you knew exactly when you could leave instead you watch the progress bar) but exact answers are not inherent in either the hardware or the problem space that we are working.

Re:because (5, Insightful)

NotQuiteReal (608241) | about a year and a half ago | (#42879449)

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 (5, Insightful)

ILongForDarkness (1134931) | about a year and a half ago | (#42879573)

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.

Re:because (0)

Anonymous Coward | about a year and a half ago | (#42879525)

The way to deal with that is to use Bayesian methods to estimate the distribution of weight times given the system's load average and/or other measures of how likely the process will be forced to wait for something to finish.

  When a download starts, your best estimate is probably best based on the system's long term average download rate. If the current download rate varies from that, you adjust your estimate slowly rather than instantly going to the most recent rate.

Simplest answer. (0)

Anonymous Coward | about a year and a half ago | (#42879243)

Because doing so, in most cases, would make the process take a bit more time. The first step would be to assess how much time it should take, and that would generally add to the total time.

Just take a simple recursive file copy, for instance. In order to make an accurate progress bar, you'd first have to recursively go through all the directories and sum the sizes, which would take a bit of time, and you'd be duplicating work.

Re:Simplest answer. (1)

uncqual (836337) | about a year and a half ago | (#42879595)

you'd first have to recursively go through all the directories and sum the sizes

And also figure out which are links to other devices including network storage (both WAN and LAN) and benchmark each to see what its capabilities are. Heaven help you if the destination is on a device with a large non-volatile write cache (such as a hybrid drive) that works really hard at looking just like an ordinary disk drive.

Why? (1)

tian2992 (1690038) | about a year and a half ago | (#42879247)

Why is it so hard to prove than NP = P?

Solution: (0)

Anonymous Coward | about a year and a half ago | (#42879539)


Various reasons (5, Insightful)

GoodNewsJimDotCom (2244874) | about a year and a half ago | (#42879249)

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 (1)

number11 (129686) | about a year and a half ago | (#42879489)

One reason is the progress bar starts out as just a generic tool to show that your loading hasn't froze

And a spinning asterisk or swirlie does that fine, without implying anything about "progress" or "time left".

Another reason is it is difficult to estimate time left.

We're not talking about a "time left" bar, we're talking about a progress bar (although if things continue at a constant rate, the two should be the same). While there are exceptions, mostly the program should have a decent estimate of the total amount of work to be completed. At half the tasks done, the bar should be at 50%. Yes, things like fragmentation and other tasks running will impact the time to completion, but they won't affect the amount of work that has been already completed by the program.

Re:Various reasons (1)

PlusFiveTroll (754249) | about a year and a half ago | (#42879641)

>At half the tasks done, the bar should be at 50% > but they won't affect the amount of work that has been already completed

You assume that the program knows how much it will have to do before it completes. Many programs have to call in 3rd party libraries that install in the background of what you are doing, they don't know how long the other program will take (think .net libraries). Dependency chains suck in these cases.

Also, installing a large application is not a constant rate event, especially on spinning disk. A fair number of installers work like this. 1. Install large data files, this goes fast because disks have pretty good streaming throughput. 2. check and write ini files OR check and write registry keys. Unless you have an SSD this is slow as crap (maybe 100 IOPS if you're lucky). You could have wrote 1GB of data before then at 100MBps, then because of fragmentation and random seeks suddenly drop below 1MBps.

Re:Various reasons (2)

ILongForDarkness (1134931) | about a year and a half ago | (#42879503)

This is why if it is something the user will understand I like to use a status bar instead. Much nicer to see things moving through a workflow than trying to guess how long the db load vs analysis will take and display the progress bar correctly which will change as the data grows, complexity of the problem, computer the user is on etc. Progress not timing, we should just completely remove the complete from the visual just have a numerical counter, if it is increasing things are still working.

Crappy software (0)

Anonymous Coward | about a year and a half ago | (#42879251)

Also see

For, eg, HTTP downloads, it's easy to make a progress bar. It sends a Content-Length and every byte received is accounted for. But other problems, like disk IO, are harder, but not intractable.

I'm willing to bet it's just crappy software.

Re:Crappy software (1)

greg1104 (461138) | about a year and a half ago | (#42879599)

You'd lose that bet. The rate of future I/O operations is extremely difficult to work out at any price, with any quality of engineer. I would bet you a billion dollars it can't be done reliably in the case of HTTP downloads, and not lose a moment of sleep about losing. If you spent all of the money hiring the best developers in the world with that billion, all you'd have when you were done is a better understanding that it's impossible. In fact, I'd make a side-bet that someone tells you it's impossible before they even start!

sometimes (3, Informative)

MrDoh! (71235) | about a year and a half ago | (#42879257)

Copying files. Sure, get a list of the files to be moved, get the size, as files go across, start the % progress meter. What if the network starts slowing down as you start to copy? New files are added. You used a rough calc to get a vague idea as it was 10x faster, but when you start copying, there's a lot of files bigger than you thought. Network's fast, but the end machine you're copying too is having problems keeping up. You start hitting cache, it was fast (and skewed the result) till then, now it's crawling. Installations. All the fun of copying files, but you're updating existing files too, file system may be fragmented, some of the .ini files as you get to may need extra work. Drivers to install may take longer than expected. Once installed, you have to generate/compile/download extra, that's more rough guesses. As long as the hourglass/cursor/spinner is spinning, and the %'s is going up now and then, probably the best you can ask for. The trend for guesstimating time remaining seems to be diminishing, as surely the main thing most people want is to know 'is this still working or has it hung?' for anything else, logcat/catch stderr'more details' to find out what it's actually doing. It COULD be more accurate perhaps, but you'd spend so long working it all out in advance, for 9/10 things, it'd have been quicker to just do it.

Yes (3, Insightful)

Austerity Empowers (669817) | about a year and a half ago | (#42879261)

It's very hard to predict how long something will take, particularly in relation to other things, if what you're writing is going to be on any number of platforms with different processors, storage, memory and network situations.

You can be reasonably accurate with it, far more than my favorite 99% in 1 second, the last 1% in one hour scenario. There are cleverer and cleverer ways of making it ever more precise, but those methods usually involve spending time on getting it right, and not many people do it.

Re:Yes (4, Interesting)

greg1104 (461138) | about a year and a half ago | (#42879491)

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 [] . 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 [] , 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:Yes (1)

fsterman (519061) | about a year and a half ago | (#42879653)

As an engineer, however, I would argue that we don't have to just give up because the maths proves it to be impossible. Even a reliably incorrect signal would tell us to not trust it and offer up a spinning (or otherwise infinite) processing ball. The reason we have these is to improve perceived performance.

I mean, what's worse, being stood up on a date or not knowing for sure if s/he was going to tag-along on a group activity that you invite him/her to?

Re:Yes (1)

Bigby (659157) | about a year and a half ago | (#42879521)

Unless you are on a Real Time System. But then you KNOW how much processor time you will get and you KNOW how many clock cycles your execution requires.

The problem is simple. People want progress in "time remaining" and you aren't copying "time". So you have to do a translation of non-time to time and that is hardly ever linear.

Re:Yes (0)

Anonymous Coward | about a year and a half ago | (#42879531)

... spending time on getting it right ...

That's the key point. I have written a small handful of things that I added a progress bar too. Very few of them have been accurate. I mostly put it in so that we can see the general progress of something. If I am copying a file, that is one thing.

But if I have something that pulls a database off of a ftp server, then processes that database, then generates 5 reports from it then that's another story. Do I make a progress bar for each stage? do I approximate how much each stage contributes to the progress and update each part in real-time? do I just jump 20% every step? does the progress bar really matter all that much to my goal?

I will gladly cut corners for internal apps and put more effort into ones used more publicly. But at the end of the day, I have better features to write.

I wrote one app that was copying 1-2 Gig files off of usb for whatever reason. I was able to make an accurate progress bar (simple math). But I also added a random short phrase generator. It would say it was calculating indexes, adjusting DRM, processing channels, ... ect. It made it feel much faster than it really was.

AMD Catalyst (1)

jones_supa (887896) | about a year and a half ago | (#42879265)

The AMD Catalyst installer progress bars are my favorite comedy example. It's jarring that such a high-profile product can have such a hacked solution in place.

Some progress bars seem to have gotten better (1)

dakohli (1442929) | about a year and a half ago | (#42879267)

I think that I can say it seems like some have gotten better, like large file copy dialogs no longer seem like a suggestion

But, I have to agree that more complex operations like OS installations seem to be out to lunch, I can remember years ago joking about "Microsoft Minutes" during what seemed like Windows Marathon installations. I think with the array of processors, HD speeds, SSDs, etc, perhaps we should dump the x minutes remaining, and rather look at a percentage completion factor, although this too is not perfect because we all like thinks to install quickly so we can get on with using the software

Re:Some progress bars seem to have gotten better (0)

Anonymous Coward | about a year and a half ago | (#42879429)

But the stupid user will still asume that things get done at a constant pace.
So they would simply start complaining about the last 10% taking 90% of the total time instead.
And *then* they will demand some clever algorithm to predict how long it will actually take again.

This, a thousand times this! (0)

Anonymous Coward | about a year and a half ago | (#42879269)

It has come to pass that I sincerely prefer the hourglass (or spinning discus or beachball, or whatever) to seeing the various permutations of horror inflicted on the progress bar.

From serial progress bars that use the same bar, to progress bars that empty again (though the empty-on-uninstall is just brain-twinging, not actually wrong) to progress bars that change function halfway through, I find that I cannot stand the abuses of user interface design that some idiots perpetrate.

For crying out loud, why cannot a simple progress bar actually display some indication of !@#$ing progress for once?!

It's probably patented (3, Funny)

Punto (100573) | about a year and a half ago | (#42879273)

There's probably a pantent for a "method or apparatus for an accurate display of progress", nobody wants to mess with that (but seriously most of my innacurate progress bars deal with unpredictable things like I/O, or non-uniform sets like loading textures and meshes and animations all together, so who knows how much time it will actually take to process the same ammount of data?)

too many factors (0)

Anonymous Coward | about a year and a half ago | (#42879275)

too many calls to too many black box parts that you have no control or even no telemetry of.

i'm just guessing.

If I only had a crystal ball... (1)

dav1dc (2662425) | about a year and a half ago | (#42879283)

Unfortunately, one does not know the exact running time "a priori" - it varies widely with different hardware configurations, network congestion, hard drive speeds and is therefore often easier to measure than to predict.

The progress bar has always been a "best effort" guess as to the amount of time remaining, I think they have gotten a lot more accurate over the years - but perfection is a long way off I suspect.

Too many variables (0)

Anonymous Coward | about a year and a half ago | (#42879285)

There's just too many factors involved. Are you installing something? Well the read/write speed of your hard drive can impact that. Even if you KNEW what the read/write speed was averaging there's no guarantee that it will maintain that speed; if the drive was severely fragmented the head could be jumping all over the place to get the necessary data and write it out. That's just a small sample, I'm sure you'll get more examples.

Streaming (-1, Flamebait)

dubbayu_d_40 (622643) | about a year and a half ago | (#42879291)

This question is stupid shit for stupid people. Fucking deal with it...

Re:Streaming (-1)

Anonymous Coward | about a year and a half ago | (#42879419)

Says the dumbass who's user name is dubbayu. That's 'double U'
Stupid shit for stupid people indeed. You should enjoy the rest of this thread then!

It's not hard.. (0)

Anonymous Coward | about a year and a half ago | (#42879293)

It's not hard to make an accurate progress bar for file transfers in within a filesystem. The problem is that it doesn't really matter in small transfers and creating an accurate estimation of big and many filed transfers would make for a significant delay on its own, as each file had to be scanned.

different builds (0)

Anonymous Coward | about a year and a half ago | (#42879295)

Because everyone has a different set of variables.

no, it's easy. (-1)

Anonymous Coward | about a year and a half ago | (#42879301)

i'm a computer programmer. it's easy to make an accurate progress bar. take the total, take the current, divide. done. i don't know why windows progress bars and time estimated are so messed up. they're clearly doing something totally wrong. if not many things. as usual.

Re:no, it's easy. (5, Funny)

dotHectate (975458) | about a year and a half ago | (#42879335)

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

Re:no, it's easy. (2)

GigaplexNZ (1233886) | about a year and a half ago | (#42879625)

i'm a computer programmer. it's easy to make an accurate progress bar. take the total, take the current, divide. done. i don't know why windows progress bars and time estimated are so messed up. they're clearly doing something totally wrong. if not many things. as usual.

Clearly you're not a very good one.

the time cost (0)

Anonymous Coward | about a year and a half ago | (#42879303)

Making it any more accurate (say by prescanning all files ahead of time) would dramatically increase the amount of time the operation would take.

Re:the time cost (1)

rwa2 (4391) | about a year and a half ago | (#42879369)

Either that, or the progress bar overestimates, and then just makes you wait at the end until it hits its estimate right on the mark!

Actually, MS should do this. It would make them look like geniuses.

Re:the time cost (1)

GigaplexNZ (1233886) | about a year and a half ago | (#42879639)

Making it any more accurate (say by prescanning all files ahead of time) would dramatically increase the amount of time the operation would take.

You've just described why Vista took so damn long to actually start a copy operation.

Please wait. (0)

Anonymous Coward | about a year and a half ago | (#42879305)

Comment loading 12%

Dev tasks work just the same! (0)

Anonymous Coward | about a year and a half ago | (#42879309)

My team lead often wonders why my own "progress bar" seems occasionally to freeze.

It's because things vary a lot. (1)

CityZen (464761) | about a year and a half ago | (#42879311)

You can make an accurate estimation for a given system. However, everyone else's PC and network environment will be significantly differently from that system. Even things that you think might be predictable can take unpredictably long, given the "right" setup.

Of course, sometimes it's just due to bad programming.

Also, oblig xkcd: []

No completely accurate algorithm exists (1)

insecuritiez (606865) | about a year and a half ago | (#42879321)

Progress bars are all about using past history to predict future performance. The problem is that past history doesn't always say anything about what will happen in the future.

If you only use very recent history then you can usually better predict the very near future but it also makes the progress prediction and remaining time prediction very unstable and jump all over.

You're a human so use your own intuition to predict progress in part on what the program tells you and in part based on your knowledged of the work involved and the work yet-to-be-done.

Leave it out (1)

jones_supa (887896) | about a year and a half ago | (#42879323)

It is sometimes hard to make a good progress bar for certain procedures. In such case, please don't even try. No one wants to see those bars that sit at 0% for three minutes and then jump to 100%. Leave the progress bar out completely or use one of those "infinite" bars that just have block sliding from left to right, or the Win8 spinning pearls animation.

Re:Leave it out (0)

Anonymous Coward | about a year and a half ago | (#42879389)

Then the product manager comes by and insists that they need an estimated time to completion, and the engineer says 'less than one minute'.

Hey my washing machine sits at 1 minute for at least 10 minutes every cycle.

It's mathematically impossible. (4, Informative)

PseudoThink (576121) | about a year and a half ago | (#42879337)

See [] and []

(No, I'm not being serious. The topic just reminded me of when I once jokingly justified a poorly estimated ETA on a "simple" development project by referencing the above paper.)

MSIE (5, Interesting)

Anonymous Coward | about a year and a half ago | (#42879351)

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.

Zenity (1)

flyingfsck (986395) | about a year and a half ago | (#42879361)

It is quite trival actually.

This one is always perfectly accurate:
zenity --progress --text="Testing..." --title="Test" --auto-close --pulsate &
Do whatever...
kill $PID

And yet the boss always can set a deadline ;-) (0)

Anonymous Coward | about a year and a half ago | (#42879367)

...that we meet every time.

Work is hard. (0)

Anonymous Coward | about a year and a half ago | (#42879371)

To meaningfully show progress, you have to do work and plan. This is an anathema in software development these days.

If you are going to have a progress bar that simultaneously shows steady progress through the amount of time required and actually represent real progress, you need to identify similar-duration chunks of actual progress. Without that effort, you stand the chance of the issue seen by the submitter.

Even given that work, sometimes the software executes in an environment with different performance characteristics (e.g. SSD instead of the HDD you tested on, 1G of RAM instead of the 8G on the development system). I suggest that it isn't always easy to represent everything with one bar.

That is still NO EXCUSE for failing to find a better solution. You could have achecklist that checks off TODO items, a series of individual progress bars, or ANYTHING indicating what resources are being used without the end user resorting to opening some diagnostic software.

Cost Benefit (4, Informative)

infernalC (51228) | about a year and a half ago | (#42879381)

Progress bars do not make sequences of actions complete any faster. In fact, they make them slower.

That being said, take for example an installer that must perform the following steps during an upgrade:

0. Figure out how many files need to be replaced.
1. Replace 30 files of varying sizes.
2. Add 10 files.
3. Update a half million rows inn a table with a million rows setting a column to a computed value based on some predicates.
4. Run a third party installation mechanism (MSM?) for a supporting library, etc.

Modern computers are time-sharing systems. Each process that involves computation is at the mercy of the scheduler in the kernel to give it the cycles it needs to complete. That means that even if you measure the time it takes to complete some process, it's not going to be the same a second time, because the installation process doesn't get undivided attention.

Steps 0 - 2 - you're at the mercy of the IO buses, hard disk, antivirus software interfering, etc.
Step 3 - What shape are the database statistics in? How efficiently can you apply the predicates? What does the distribution of the data look like? You can't tell this ahead of time...
Step 4 - Does this third party installer provide you some sort of metrics as it runs?

These are the sorts of problems to be overcome to do an accurate progress bar. In short, they aren't worth overcoming.

It's not the progress bat that has the problem (1)

stafil (1220982) | about a year and a half ago | (#42879393)

But the data it represents. In your case, I assume, it's estimate time to completion.

Computing something like this is difficult indeed. It's like planning a car route. You can have an estimate of the time it will take, but the end time will depend if the current traffic condition at each segment if your route when you are travelling.

consider a rocket launch countdown (4, Insightful)

at10u8 (179705) | about a year and a half ago | (#42879405)

For over 50 years rocket launch countdowns have not run in a linear fashion, sometimes even being set backwards.

Development time (1)

Torp (199297) | about a year and a half ago | (#42879415)

For complex operations, doing accurate progress may take a lot of development time you can't afford. Mostly everyone has deadlines...

Re:Development time (1)

Bill Dog (726542) | about a year and a half ago | (#42879601)

Or for a non-trivial set of combinations of operations. Take an installer that has to be able to upgrade just about any of a number of possible applications in a business's suite of related apps, and applying patches, in order, to support up to three versions back. Where different applications can be at different suite versions (customer pays for upgrades of some apps faster than others). It's just not feasible to make a progress bar account for all of those possibilities to be accurate.

A bit warped but... (0)

Anonymous Coward | about a year and a half ago | (#42879431)

OS/2 got it right. I once saw an installer fail and the progress bar went backwards as it cleaned up the bad installation.

Better than a progress bar... (2)

0xffffffff (161827) | about a year and a half ago | (#42879443)

...would be a PB combined with some way for the app and OS to tell me why things have slowed down, in plain language. This would not be impossible to do.

Apple Compressor has the worst progress bar (1)

Y-Crate (540566) | about a year and a half ago | (#42879471)

I'm convinced that it's just a random number generator. Half the time it gets to 50% in an hour, jumps to 75% in ten seconds, then finishes. Other times it grinds away at a job for the full estimated time. Which changes constantly.

Re:Apple Compressor has the worst progress bar (1)

Cyclon (900781) | about a year and a half ago | (#42879613)

Windows file copy dialog is pretty awful, too. Obligatory XKCD []

It's actually very easy (0)

Anonymous Coward | about a year and a half ago | (#42879477)

It's just a matter of rounding up/down to the right scale. I usually use a standard approximation equal to 100% floored: Until the given set of operations is within the range of 0-99.9999999% completed, the progress indicator is rounded down to "It's not done yet!" so the bar stays empty. Once all the operations are finished, the bar fills up completely and displays "Now it's done! Go treat yourself to a cookie!" Sounds pretty damn accurate, don't you think?

Physics! (5, Funny)

ignavus (213578) | about a year and a half ago | (#42879479)

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.

because fortune telling (0)

Anonymous Coward | about a year and a half ago | (#42879509)

I think the only reasonable response here is two-fold:

1. Obviously, the problem with perfect progress bars is that one cannot predict the future behavior of nondeterministic systems -- and the ever-increasing abstraction of software is only making this harder. If you're complaining about poor estimates of OS-level (or worse, network-level) operations, there's so much going on that there's simply no hope without a psychic to provide supervised training.

2. In fact, I write (non-graphical) progress meters all the time that do a damned good job. However, I am usually just estimating the amount of time to completion of a computation that is broken into chunks of similar difficulty on a system whose behavior is pretty consistent (in-memory operations on a virtualized machine). Most often (total number of steps - current step count)/(current step count) * (time passed so far) is completely adequate. Sometimes it makes more sense to use an exponentially weighted moving average version of (time passed)/(current step count), and all it takes is a little forethought (or observation of inadequate estimates) to identify when this extra step is needed. Since I don't expect to predict the future very accurately, what's left ain't rocket science but generally works pretty well.

Not A Progress Bar (1)

StormReaver (59959) | about a year and a half ago | (#42879519)

What you're describing isn't a progress bar. It's a time remaining indicator. Progress bars tell you how far long a process is on its path to completion. It was never meant to tell you how much time remains, and using it as such will predictably lead to end user confusion and frustration.

Even when a progress bar goes from 0 to 99% in an instant, then takes forever to go from 99% to 100%, it is doing what it is intended to do: tell you how far long the process is. That's all it is supposed to do. It should NEVER be used to tell you how much time remains. You can sometimes infer timing from progress if the progress bar progresses smoothly, but that's a side effect.

As for the time remaining indicators: those will ALWAYS be inaccurate (usually severely so) because most factors that contribute to how much longer a process must run to completion are unpredictable. It's like trying to predict when someone is going to turn off the hall light tonight based on when they turned it off last night. It might be accurate sometimes, but that's just from pure chance.

One thing.. (1)

lionchild (581331) | about a year and a half ago | (#42879537)

We live in a world of multi-tasking, or task-swapping hardware. It would seem to me that we've not figured out how to simply stop or buffer other tasks so we could give you something a bit more like an acual progress bar and not just a best guess.

Well, that, or that's a feature that they're planning to put in next version of the OS.

Play Progress Quest (2)

sidevans (66118) | about a year and a half ago | (#42879545)

They have their progress bars sorted perfectly. Great game too!

XP progress bar was perfect (1)

michaelmalak (91262) | about a year and a half ago | (#42879549)

Flame mode: ON

The Windows XP Windows Explorer and IE8 progress bars were perfect. They took recent data transfer rates, did a simple division of bytes remaining / bytes/sec and reported the expected remaining time at the most recent transfer rates. Yes, transfer rates fluxuate over time. That is the nature of things.

The Windows 7 Windows Explorer file copy progress bar, by contrast, is absolutely worthless. No doubt the engineers screamed under pressure to implement that way, under duress of pressure from the Microsoft marketing dept, who undoubtedly heard undue amounts of whining by people like you who couldn't understand a simple formula involving one division. Now when I go to copy files in Windows 7, it saws 2 hours remaining, and stays stuck at that readout for five minutes, before it finally comes up with a more reasonable estimation like 12 minutes.

The only way to make the progress bar more informative is for it to provide error bands, based on both short-term transfer rate history and longer-term transfer rate history. That would be pretty slick, actually. But to expect the general public to understand the math used in high school Chem I is just too much.

Sorry asshole, (0)

Anonymous Coward | about a year and a half ago | (#42879563)

but computers can't predict the future.

Kalman Filter (1)

laing (303349) | about a year and a half ago | (#42879565)

Here is your answer: []

The problem is that most software engineers are too dense to implement this properly.

Probably take up too much processing (0)

Anonymous Coward | about a year and a half ago | (#42879575)

It probably will take up too much processing just to calculate a potentially more accurate estimate. Which will still be wrong some of the time at least.

I too am surprised. (1)

bobamu (943639) | about a year and a half ago | (#42879579)

at the lack of progress in this technology. ( Yeah, I know, I even had mod points, I'm sorry ).

Sometimes. (1)

Sipper (462582) | about a year and a half ago | (#42879593)

When it comes to the back-end of the "progress bar", it's essentially a widget that shows a percentage from 0 - 100%.
So the question actuall is, does the thing the progress bar is showing the "progress" of output a "percentage done" or not.
Sometimes the "percentage done" can be estimated or calculated, but sometimes it can't. Some programs (like 'dd') don't give any progress output at all.

What's annoying is when programmers show a "progress bar" that changes but doesn't actually show any progress -- so whatever they show is fake. That's irritating, because when that happens it means the user is essentially being lied to, and defeats the purpose of the progress bar. I'd personally rather see a message of "please wait while (blah)" than see a fake progress bar.

The latest place I saw a fake progress bar was in the Java setup GUI in Untange (which is based on Debian). Every single area a progress bar is shown in this GUI shows looping "fake" progress. Ugh.

Nostradamus (0)

Anonymous Coward | about a year and a half ago | (#42879611)

If you want to know "how much longer", ask Nostradamus, but if you want to know more about what is taking place during the 30 minutes while the progress bar is at 1%, tell your programmer to add some more detail.

Are you referring to Windows? (1)

Haydn (592455) | about a year and a half ago | (#42879621)

I don't know why Windows' progress bars have such chaotic behavior, but I've generally had better luck with ones which run on other operating systems or at least aren't written by Microsoft. :-)

It should not be hard. (0)

Anonymous Coward | about a year and a half ago | (#42879629)

I remember in the 80s when Apple had this great idea. It would calculate how much space was needed before doing the copy and prevent you from wasting your time. Before then you'd only find out it was not possible when the system choked. The way around this problem is first recognizing it is a problem as the author has done. The next step is to write the code in such a way there are multiple split second tasks that can be checked off. Then these tasks are timed on various machines. Hopefully crowd sourced. As the machine in question compares how long it is taking to finish each of the task it determines which of the probably curves best fits and chooses to extrapolate from there. If crowd sourcing is not available then it would attempt to use the 20 or so time logs the developers included with the software.

We need some standards to make this catch on.

Let me try... (1)

stanlyb (1839382) | about a year and a half ago | (#42879631)

You have to implement a BAR, showing the progress of M operations, executed in N seconds.
Your BAR has 100 units. Your time is.....the computer time.
The computer time is INCORRECT. Believe me, it really is.
Now, You dont have M, and you dont have N. So, the questions is, how to divide M by N, when you dont know anyone of them!!!
Short answer, by measuring the calculated Mt, for a fixed amount of period T. Every t seconds.
So, in the begining you will have pretty funny results, but as the calculations are going, so will your BAR.
A few problems here, the fixed "t" amount of time is fixed for you, but not for the computer, and there is simply NO way of having always the exact "t" period of time, all the time. Except if you have a real time OS. Even then it is not an easy task.
Second problems is that the calculations made so far are not keeping the progress of the calcultaions. So, just for example, a better solutions it to keep all the Mt and Tt pairs, and to make one nice, good, pretty complicated math calculation, called interpolation, for the purpose of finding out the exact LAW your bar is progressing on.
So, easy task, huh? And i have not even started talking math.........Again, trust me, it is not an easy task :)

It's not hard, but it takes time ... (1)

GNUALMAFUERTE (697061) | about a year and a half ago | (#42879633)

A program you could code in 2 days would take a week with actual, proper error checking. Add another week if you want a precise progress bar, since that's a whole different program to write.

Programmers work on an schedule, and therefore we have to cut corners. Let's say you need to collect some information from a form, then process it, send it to a web service, then report back to the user.

You could do this:

-> Pass all fields to the server (set progress to 20%)
-> Check they aren't blank (set progress to 30%)
-> Call the webservice, pass the data (set progress to 60%)
-> Check the return against a case with error cases: 1) Everything ok 2) Service not responding 3) Anything else (set progress to 90%)
-> Report to the user. (set progress to 100%)

There, it works. But you are cutting corners.

You should also check the fields against regular expressions to validate the data, and you should implement the complete API with all return codes, which could be hundreds, and each would require a different response from the program, to that you have to add all possible responses outside the API (TCP errors, etc.). Also, if the problem was data, you should try to find out what particular field caused the problem, and show the user what the particular problem is. If you want accurate progress, you need to make measurements of each atomic process you are doing, and then check for a lot more conditions, and either increment progress or report special circumstances (hey, IO is stuck, we don't know how much we'll have to wait). Doing that also means implementing threads, in order for the IO operations to be non-blocking so you can report back to the user. By this point, we've already transformed the complexity of the program from something a single guy can do in half a days work, to a complex piece of code that will take at least a week to complete, and it'll be more complex to maintain later. And we're still cutting corners here, there's a lot more we could be doing to be more accurate.

So, you can implement a hundred error-probing statements, or you can just throw it out there, hope for the best, and tell the user "it went ok" or "everything's lost".

It isn't up to you, it's up to management, up to the customer, and determined by your budget.

So, no, it's not impossible, and it's certainly not "hard", as in, it's solvable with well known methods. But it's time consuming. So you'll have to deal with it, programmers usually measure with a micrometer, mark with chalk, cut with an axe. Not because they want to, but because it's the only way to deliver ontime, within budget, and most of the time, it's the reasonable thing to do.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account