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?"
it's because (Score:5, Funny)
Comment loading ...
Can't Go Backwards (Score:5, Insightful)
Comment removed (Score:5, Insightful)
Re: (Score:3)
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 (Score:5, Funny)
You mean like this one? http://xkcd.com/612/ [xkcd.com].
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.
outline format (Score:4, Insightful)
Re:Can't Go Backwards (Score:4, Insightful)
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.
Well, they are not pointless. They let the user know "Something is happening, but I have no idea when it's going to be done.". If you don't do something like that, then the user thinks your app has locked up and they kill the application. It's called "User feedback".
Now on to the original theme of the story....
Progress bars shouldn't be based on time, they should be based on quantity of work. Typically when they do the marquee style of progress bar (where it just show animations, but no actual progress), it means the quantity is unknown. This happens in a lot of situations where the total number of steps to be processed is unknown due to the data, or the amount of time it would take to calculate the total number of items would take too long.
Progress bars should also be a different subject then Time Estimates as they are not the same. I have 100 things to process, so my progress is between 1 and 100. How long that takes depends entirely upon what I am processing. If I'm processing Invoices say, then how long it takes depends a lot on what is involved with the invoice (line items, calculations, other look ups).
Just because it took 10 seconds to process the last one doesn't mean it's going to take 10 seconds to process the next one. In order to determine how much time is left, what most people do is take the quantity left and multiply that by the average time it's taken so far. You could apply smoothing to the average (so it doesn't jump around a lot), but other then that, how else would you estimate the time? If the amount of time it takes to process items is fairly even, your estimate will be very accurate, if they are vastly different between items, then your estimate is going to jump all over the place and be wildly inaccurate.
Re: (Score:3)
Yes and it's those--as well as those that dance left and right for no damn reason--that really piss me off.
There's one worse: A single progress bar animation that seems like it's working normally, gets to the end.... and then *starts over* (not the entire process, just the progress bar).
That's worse than useless, it's utterly misleading. Either code a proper progress bar, add a second progress bar to indicate overall progress (assuming the first bar keeps resetting for every sub-task), or use one of those "indeterminate" animations. The "dance left and right" bars are attempts at one, but visually make no sense.
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.
Re:Can't Go Backwards (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.
Re:Can't Go Backwards (Score:5, Insightful)
Yeah, but then users complain because the bar is weirdly scaled, like 95% taking up a second and the remaining 5% an hour. You can try to profile it, but the actual time is determined by the local hardware after all: Processor speed, number of cores (which affects only some operations), network speed, free memory - there's no way to predict how much of the time will be spend on each task.
(And if the progress bar isn't an indicator of execution time at all, then the arbitrary completion percentages assigned by the developer mean little. In that case, you may as well go back to hourglasses and spinning beachballs...)
Re:Can't Go Backwards (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).
Re:Can't Go Backwards (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?
Re: (Score:3)
Install an HP printer for the best example of this. Breaks down the install in steps, usually 3-5, and in each step it shows the name of the current file being installed as well as the size of that file.
Too bad that HPs printer installers suck terribly. They find more reasons to fail, or just to grind and grind forever installing god knows what. I'm not really sure why their base printer drivers are over 100MB for some models. Other manufactures for models that perform similar functions will be 20-30MB.
Re: (Score:3)
A lot of the time, buried away inside that 100MB archive, there is just a small little drive file and its attendant meta data. It just they like giving you a thousand pieces of crap on top of it that you don't really need.
Re: (Score:3)
Re:Can't Go Backwards (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.
Re: (Score:3)
I'd be happy with the bar just to indicate some form of total progress, quite unlike the latest trend in things like the Windows 7 installer. Why give a progress bar at all if it gets to the end and starts again at zero for some mythical next stage of the install progress?
Re: (Score:3)
Re: (Score:3)
I know that NSIS Installers at the very least base the default progress bar internally* on the line number through the length of the entire set of installation process code. This makes it quite fun when you have long position jumps in the code or repeating loops that have enough code to cover a good chunk of progress. I would expect that several other installers may use the same base internal calculation of the progress bar.
*The progress bar can also be controlled manually within the code for the coder to
Re: (Score:3)
they should become longer instead of moving backwards.
Re:Can't Go Backwards (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%.
Re: (Score:3)
Re:Can't Go Backwards (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 [codeproject.com]
Re:Can't Go Backwards (Score:4, Insightful)
No, no it isn't. A second progress bar flickering up and down all the time tells the user nothing. Just put the one general progress bar there, and you're done.
Re: (Score:3)
No. You're wrong.
This is a solved problem that was done, IMHO, good enough back in the mid-1980s on AmigaDOS.
The AmigaDOS progress bar was actually two. The top one was the entire task - like installing the application. The bottom one was the individual action, like copying a file or updating a config.
The were separated and there was a line of text over the lower bar telling you exactly what the current specific task was. Over the top bar was a line of text with a fraction showing you the number of total su
Re: Can't Go Backwards (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?
Re: Can't Go Backwards (Score:4, Informative)
Re: (Score:3)
If the transfer is going to take more than a few hundred milliseconds, yes. The extra latency due to such "interruptbs" is small enough to justify the improvement in responsiveness.
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: (Score:3)
Last time I did that at work I got told to reduce it back to one.
Re:Can't Go Backwards (Score:5, Funny)
Re:Can't Go Backwards (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.
Re: (Score:3)
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.
A lot is just stupidity. When you copy lots of files on a hard drive, the time is proportional to some constant times total file size, plus some other constant times number of files. Lots of small files take longer than their size indicates. Most progress bars don't take that into account, so you make huge progress through a dozen 20 MB files, and then slow down through a lot of tiny files. Accounting for that alone would be a huge improvement.
Re: (Score:3)
All these constants go out of the window if anything else starts accessing the drive as well, of course, and they're actually variable based on file system and a variety of other things.
Re: (Score:3)
Sorry, that's the wrong approach.
The progress bar should not advance unless something has been completed. If you have it go back or have to rescale, then you should be using a different mechanism for determining completion.
A more ideal way to do it would be with multiple process bars: a 'step' bar, and an overall progress bar. Step bars would be solely progressively linear. The progress bar would measure the steps. There are some tools which do this. The key point, I think, is that the overall progress bar
Re: (Score:3)
Uhmmm. (Score:5, Insightful)
Re: (Score:3)
Yes. (Score:5, Funny)
Re: (Score:3)
Yes it is. And to be fair, it's a lot more accurate than Nostradamus will ever be.
There, FTFY.
because (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.
Re:because (Score:5, Insightful)
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.
Re: (Score:3)
Re: (Score:3)
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
Re: (Score:3)
...I would welcome the demise of the progress bar if it were replaced with an activity animation along with Andy Rooney quotes.
Or even some Andy Rooney animation:
"You ever wonder why they call it a 'computer?' We don't really do any computing with it. Maybe they should call it a 'time-wastey box'..."
Re:because (Score:5, Insightful)
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 (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 (Score:5, Insightful)
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: (Score:3)
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.
Re:Various reasons (Score:5, Insightful)
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.
Re: (Score:3)
The turning propeller or cylon helmet light going back and forth (or the papers flying if you must) should work like a watchdog. If the worker thread/process gets hung, the displayed element should freeze. If all it tells you is that some propeller updater thread is still running in isolation, then the system is not competently designed.
Re: (Score:3)
Sure it should.
The thing is a progress bar is pretty hard to fake convincingly, if your bar always progresses at the same rate and then freezes at a fixed point it's going to get noticed pretty quick. A spinner or similar indicator is much easier to fake convincingly and if something is easy to fake convincingly there will always be the suspicion that it is fake..
Heck windows kinda institutionalised faking such things by including animated icon support in the OS itself and including an icon set where the ho
Re: (Score:3)
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.
What is the measurement unit for "amount of work", though?
Take file copying for a canonical example. The most reasonable unit of measurement in that case would be the number of bytes copied. However, to properly compute relative progress for that, you need to find out the total size of all files before starting the copy. For a large tree, computing that can itself take a fair bit of time (remember the copy dialogs in Vista, which could sit there for a minute before even starting to copy?). It can be even mo
Re: (Score:3)
Say you are copying files from a network drive to local, and you get 90% of the file(s) done in an hour. Then, the network usage spikes, so your bandwidth drops to 1% of what it was. A progress bar would show 90%, even though you are going to get that last It should take, if my brain is working right, just over another hour to copy the remaining file(s). So, what do you want the progress bar to show? 90% because only 10% of the bits are left? 50% because that's the time estimate? Maybe 2 of 3 files were copied already and the remaining file is huge, so should the progress bar show 66% to show that 2/3rds are done?
You've got 90% done, so you're at 90% progress. I'm arguing that progress bars should not be "time to completion", for that reason, that you can't easily predict those variables.
OTOH, my bittorrent client uses bytes still needed at the current speed to predict time to completion, that works too, but that technique may not generalize well to other tasks. To me, time to completion should be a number, not a bar. To have a bar, you need to know what the maximum is. Hell, show both % complete and time to co
sometimes (Score:4, Informative)
Re:sometimes (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 [encosia.com]
It draws a graph showing you the current rate, in which you can see the average over time.
Yes (Score:4, Insightful)
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 (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.
AMD Catalyst (Score:2)
Some progress bars seem to have gotten better (Score:2)
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
It's probably patented (Score:4, Funny)
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?)
If I only had a crystal ball... (Score:2)
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.
No completely accurate algorithm exists (Score:2)
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
Leave it out (Score:2)
It's mathematically impossible. (Score:5, Informative)
(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 (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: (Score:3)
Are you kidding? Lots of processes still use that damn indefinite progress bar. I think a recent version of IE might, even. As time progresses, even if no real progress is made, it fills up some small fraction of the remaining space. The next block of no-progress "time" uses up the same small fraction of the *now-remaining* space, so the progress bar creeps forever toward the end, even though no progress is made.
Zenity (Score:2)
It is quite trival actually.
This one is always perfectly accurate:
zenity --progress --text="Testing..." --title="Test" --auto-close --pulsate &
PID=$!
Do whatever...
kill $PID
Cost Benefit (Score:5, Informative)
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.
consider a rocket launch countdown (Score:5, Insightful)
Development time (Score:2)
For complex operations, doing accurate progress may take a lot of development time you can't afford. Mostly everyone has deadlines...
Better than a progress bar... (Score:2)
...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 (Score:2)
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.
Physics! (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.
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: (Score:3, Informative)
Windows 8 actually has this.
Screenshot: http://stackoverflow.com/questions/14064017/is-there-an-api-for-the-windows-8-progress-dialog-api
Re:Because it should be a graph. (Score:4, Informative)
We will have an accurate progress bar when ... (Score:4, Insightful)
... when we solve the halting problem. I'm not entirely joking. The main problem with progress bars is that, quite often, it is not possible to accurately estimate how much time is needed to complete a problem (i.e. for the program to halt).
The 99%... (Score:5, Insightful)
The public opinion of the Progress Bar would be considerably more favorable if programmers would simply treat 100% as if it were 75%.
In other words, do all the stuff you have to do, measuring progress and whatnot, but when you're actually at 80%, report yourself at 60%. Likewise, when you're at 95%, say you're at 70%.
Then, only when you really are completely finished, you jump from 75% to 100% in under a second.
Complaints gone.
You know what I'd like to see? (Score:5, Insightful)
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.
We will have .... (Score:5, Funny)
No, wait. It seems to have stalled.
It's a Prediction of the Future (Score:4, Insightful)
"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?"
Yes, because all progress bars are inherently a prediction of things that will happen in the future. If there is any error condition, unusually large blob of data or weirdly structured hard drive to read from, varying bandwidth bottleneck, fritzy peripheral not responding as expected, etc., etc. times a million, then the unusual event will make the prior prediction incorrect and look silly in retrospect. As long as there is any "if-then" clause or error handling in the branches in the system, then the unexpected can happen and make the prediction (progress bar) invalid.
It's analogous to weather prediction. It can't be perfect, it's an extrapolation, but people will always complain about it.
Ooo 'e wants a progress bar! (Score:3)
Is why.
Hmm. I wonder if I wrote an app that was nothing BUT progress bar, if people would go for it.
Some developers have already come to the conclusion that installation is a prime advertising timeslot. So even if anyone was inclined to write a progress bar, it'll still end up ad-laden and annoying.
Simple solution (Score:4, Insightful)
Show progress of the work, not the time. You never know what other things the machine is doing, and is better to give no estimate than a bad one.
And don't suffice with a bar, also provide information on what the process is doing.
Solved Ages Ago (Score:4, Funny)
This problem was solved a long time ago... I still wonder why people don't know how to code a proper progress bar...
HOWTO:
I've left out the easy stuff but this provides for a 99% correct est. Please note that the computer must be from 1 year in the future for this to exceed 87% correctness without causing time dilation within progress meter by blocks remaining^66 msecs. Check Mfg date at start and adjust time est accordingly.
The above is copy-written and my not be used....
Re:no, it's easy. (Score:5, Funny)
Re: (Score:3)
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.
Re: (Score:2)
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: (Score:3)
Re: (Score:3)
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: (Score:3)
As a happy middle, we could just change the UI widget to detect when a signal is lying to it and offer up a spinning (or otherwise infinite) processing ball.
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: (Score:3)
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: (Score:3)
Re:Crappy software (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.
Re:Crappy software (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.
Re:Crappy software (Score:5, Insightful)
Except even the number of tasks is often variable over the life of the task.
Take for example loading a web page. It starts out as 1 task: Get a page from the server. Once you've done that, how many more requests will that first request generate? Impossible to tell. It could be none. It could be hundreds, and some of those can generate their own requests. (etc, etc.)
The answer is this: Some feedback, no matter how incorrect, is better than no feedback at all.