You know, the ones you see when you’re installing or loading software that have very little relation to the actual progress of the installation or loading time. Maybe the bar just sits there interminably before shooting to the end during the last 5 seconds. Or worse, it gets to the end and then starts over at the beginning, which only serves to taunt you. “Ha,” it says, “you thought I was done but I am only just beginning! Perhaps I have just been slacking off. Perhaps I have scrapped everything and started all over from scratch! You’ll never know, you poor deluded sap! Muahahaha!” How hard is it to have a progress bar that actually shows your progress? I hardly think it takes the likes of Stephen Hawking to figure this out.
It’s impossible, I think; something to do with the impossibility of predicting how long a computation takes, IIRC. Those progress bars and clock symbols and such mean little if anything.
For it to start displaying the graphics “open loop” and magically finish as the computation ends is a non-trivial task. On the other hand, it’s easy to code in a display that shows how far through a task of known length you are. For example, I simulated ~3,000 rocket launches last week, and I used a MATLAB script to post-process them. I told the machine to take “n” (the number of files already processed) and divide it by 3000, and display it as a percentage. The comment in the code says
disp(PercentComplete);
% Because Jurph is impatient
It’s quick and dirty, and it’s not a “bar”, but it works. Fuck anyone who codes a progress bar that does an indeterminate number of laps for no conceivable reason. The glass is half-full… three-quarters-full… full BANG! FUCKIN EMPTY!..one-quarter-full…
Ah yes, the halting problem. It is impossible to construct a program that will correctly identify when all possible programs will finish execution. But sometimes they don’t even try to give you a rough estimate, which sucks.
I pseudo-pitted this one about a year ago, as part of the broader concept of What You See Is What You (Don’t) Get; despite accepting the technical explanation it still bugs me.
Yeah, for instance, I have some software that loops over, say, 100 iterations.
We have a progress bar that matches that perfectly. It’s done the simulations exactly when the progress bar gets to the end.
But, then, all the results need to be written to a couple files.
Your choice is either to start a new progress bar for that, or try to plan out in advance just how long it’s going to take and try to make your progress bar correspond to that.
Either way, the desire of the end-user to really know how much time is left isn’t worth the effort of trying to get it right.
Then, there are some parts of code that you want a progress bar around, but you have no idea in advance how long they’re going to take.
As others said, it’s not trivial.
They are also used just to let you know something is still happening and the machine hasn’t hung up. If there is no visual clue during a long process the user thinks something is wrong. Granted a ‘progress’ bar isn’t the right mechanism for that.
What would be a better mechanism for that? The interminably flipping hourglass doesn’t make me feel any more confident that the machine hasn’t hung. I can’t think of something that would make me feel confident that things were still happening other than a progress bar. (maybe I haven’t installed enough software)
The problem with the hourglass is that it can still keep flipping, even if the process really has hung up. Bytes copied, for example, would be good. How many have been copied, and how far from the end we are isn’t really important but the fact that it’s a number that keeps going up is good feedback that things are still progressing.
Strangely enough, developers seem to forget that a progress indicator should be linked to, duh, progress. They get lazy and start the hourglass spinning, or a progress bar jumping back and forth, in a separate thread than the actual one doing the work.
How about a constantly updating windows system message:
‘X hours Y minutes and Z seconds since last crash’?
The ones that are funny are those that fly right across the screen and sit at 100% for 5 minutes. :dubious:
It could display a series of advertisements. Those are always charming.
For that, the solution’s actually pretty simple:
* Looping Iterations
=================== Done!
* Write Results to file
=================== Done!
* Clean up lost bits and other housekeeping
======= Working...
How hard is that? You don’t necessarily need to know exactly how much is left, but knowing that there are other steps can be useful.
Aside from that, there’s a reason we have a unit of time called the Microsoft Minute. 
Sure, but they could do a few little things to make the user feel a bit better; even something as simple as adding the word ‘approximately’ before the ‘minutes remaining’ would be nice, especially for new users.
But the other thing mentioned in the OP I think has no excuse - that is when the things start again. They should tell you something like: “This is just the download progress bar. After that, there will be an installation one which will run for approcimately 50% of the time this one takes. Then there will be a quick third bar as your preferences are added, and then you’ll be able to use the software.” Or something.
The worst one is my Motorola phone tools. If I haven’t used it for a while - generally the case - and I just want to load some phone camera pics onto my PC, I fire this thing up and I get “Updates are available. Select to download and install”. I look at the things, see that they’re about 20Meg each, wonder why this particular program insists on such huge, frequent updates, and then give up and uncheck them so I can get on with using the thing. “YOU MUST SELECT AT LEAST ONE UPDATE FIRST”
WTF? I bought my phone in 2006 and my PC in 2003. I’m happy the way it is, and don’t need your freakin’ updates. I don’t need to wait ten or more minutes before I can even start the program.
Speaking as a game programmer, there are several factors at work:
(1) On some platforms (ie, most consoles), your game code is typically single-threaded. And it’s MUCH easier to write code that says basically:
-load file1.txt
-see if that worked
-load file2.txt
-see if that worked
Than
-start file1.txt loading
-set up a callback which constantly queries your file load for progress and runs a quick frame-swapping algorithm to keep the video display updating, and hook it into that file load, along with some utterly custom bar-displaying code which is separate from all of your normal graphics code, because all of your normal graphics code expects to have access to certain system resources and libraries that are not currently loaded or accessible from a background thread, yada yada yada
(2) Plus when you’re under tight deadline pressure, you’re spending all your effort getting the bugs out of the game. Really well-done progress bars are just on the wrong side of the bang-for-buck tradeoff as far as programmer effort is concerned.
(3) And as others have said, a loading process is usually not just 1000 consecutive file loads, where after 273 of them you are 27.3 percent done. Rather, you have a big-ass loading function, which calls 38 different things, which you are constantly tinkering with the order of. To really do a loading bar perfectly, each of those 38 things would have to have its internal logic set up to be pollable as to status, AND you’d have to have a good idea ahead of time how long each of those 38 would take. Usually 33 of them will take basically zero time and the other 5 will take a LOT of time, etc.
True anecdote: We recently had a programmer who had a slow mental breakdown and had to be hospitalized. One of the impending signs was that he spent days and days, while writing an internal tool, trying to come up with a nice polymorphic inheritance class for progress bars.
You’re scaring me, dude. I’m a game programmer/designer. :eek: This little rant was inspired by installing a service pack for Visual Studio and having it tell me, “Yeah, this may take anywhere from a coupla minutes to all fucking day, depending on a bunch of shit. Here, look at this progress bar not doing anything for an indefinite amount of time. Oh, that one’s done. Here, look at another one.”
I work mostly with the scripting rather than with the main engine though, so I have a different set of headaches to worry about.
So a rabbi, a duck, and a lawyer walk into a progress bar, and get* totally* downloaded…
Actually, now that you mention it, that’s one of the things I like about my antivirus.
If I tell it to scan, say, my C: and E: drives, it shows three bars on top of each other and goes through each in turn.
First bar, “preparing to scan,” (I think it’s calculating how long it will take, after all E is always 320G but it’s not the same to scan it if I only have one 1K file than if I have 160G worth of stuff),
second bar, “C:”
third bar, “E:”
It works quite well, at least from my point of view.
ETA: oops, what gotpasswords said.
Am I the only one who came in here wondering is wrong with what must be the latest in meat markets?
It’s not the halting problem so much as it’s the real-world issues that make progress bars difficult. Picture this: I’m writing a program that writes a bunch of data to your hard drive (say, an installer). I go through and do my calculations to figure out how long this’ll take, display my progress bar, and go. Halfway through, your antivirus program starts a scheduled scan. Now there’s a lot more disk activity, and it’s going to slow me down a bit. I can go through and recalculate, but there’s no guarantee that things won’t change after that. It’s a losing battle.
Ah yes, the old MS standard. What those progress bars are indicating is how far along the process will be once the current step is finished. Why did anyone think that was a good idea?