25 years later, progress bars are no better: they steadily go to 15%, then stop there for a while, suddenly zoom to 80%, then slowly progress to 99%, then stop there for a long time.
But if you are making something that has multiple phases and you want to use a single progress bar then that isn't goingt to progress nicely from 0 to 100 it's just impossible.
You'll either have to make an overall progress bar for the different phases, or just indicate that this is phase 4/5 and the progress of that phase is 82%. This solves the jumpy progress bar issue, but doesn't solve the underlying issue of actually showing an estimate of time remaining. You have no idea whether phase 5/5 is going to take 1 second or 1 minute.
When a progress bar stops at 99% it's just because some final task that was expected to not take very long, did. E.g. it could be deleting a file at the end of some install process, and that for some reason blocks. There is obviously no way of knowing the actual time that will take without trying it, at which point it's too late for the progress bar to adjust of course.
So: we'll have general artificial intelligence on smartwatches, before we have smooth multi-phase progress indication (because that's never).
So then why try it?
I would much rather see some sort of update like when you run "yum update" and it spits out 3/15, 11/15, etc. You don't have to show all of the lines scrolling, but you could do similar to a "\r" instead of a "\n" in the progress window with an update that is very intuitive. You know how many steps you must take to accomplish the user's request. I don't need to see how long each step is taking per se, but if you showed me the total number of steps and show each one ticking off would be much more useful than the typical blue bar race.
During startup, the console would display the modules after it loaded them. People attributed failure to load the next module as a failure of the last one visible.
This ended with mup.sys being blamed for every failure.
How is that obvious? Deleting a file doesn't just block for no reason. The OS (usually) or disk hardware (rarely) are the ones that decide to block it, and they have the information needed to know how long it will take.
What actually happens is that the advantages of showing a correct progress bar simply don't justify the complexity needed for it, and a decision to show a crappy incorrect progress bar is made.
Another example (from the real world this time): I make a progress bar for an iterative optimization of an design in a program. The number of iterations until the design completes can't be reliably estimated. It's not completely underterministic of course, but the complexity of making that estimation isn't just high, it's likely to be so high that it approaches the complexity of the optimization itself.
I like how you assume I can't recite that movie from memory.
