Originally published at: Why do computer progress bars suck as much now as they did back in the ASCII days? | Boing Boing
…
3 Likes
I have some video on my phone of a Windows 10 machine running an update and spinning mindlessly for 10 minutes AFTER hitting 100% completion. I don’t think Microsoft knows what 100% actually means.
Progess bars would appear more consistent if they mesured progress against the average speed so far, instead of the instantaneous speed at the moment.
7 Likes
The visualization of progress that i prefer are ones that show you what the computer is actually doing, the ones i mean are ones you’d usually see for processes like defragmenting a drive. It’ll visually show you what chunks of data the computer is currently working on and i’ve always enjoyed watching how it rearranges all the sections of files and data.
11 Likes
Imagine how they’ll work once quantum computing gets going!
“This process has either already completed or your cat is dead.”
(I might be a little shaky on actual understanding of quantum physics.)
34 Likes
Progress Bars are one of the HARD problems of computer science. That and making sure that desktop icons show the correct image and open the right app when you click on them.
You’d think both of these were easy. That we would’ve solved those problems with fancy AI models and what not. But you’d be wrong.
10 Likes
I always loved watching defrags run. I haven’t seen one in years. Linux filesystems rarely suffer from the kinds of fragmentation that “good” old FAT did under DOS/Windows. FAT under linux isn’t critical enough to need one apparently (the typical advice is wipe and start over). I thought of writing a grahpical defragger for linux vfat just for the hell of it.
11 Likes
If they used the Blockchain they could solve all this in no time at all.
7 Likes
Progess bars would appear more consistent if they mesured progress against the average speed so far, instead of the instantaneous speed at the moment.
Which adds more tasks, which creates more work, which slows the whole process down, even while your progress display is slightly more accurate…
1 Like
Not really. You only need to track the total progress made (which you need anyway) and the total time since the start (trivial). I’ve made progress bars like that, but they are definitely not the norm. They are not always predictive if the speed changes a lot, but they suffer much less from wild swings in estimates.
3 Likes
I introduced a “feature” into our CG renderer once which made the progress bar in the lighting tool sometimes run backwards. It was just that our estimate of the total number of tasks to do could grow sometimes as we uncovered new work.
This drove the artists absolutely mad, so we opted for a less accurate progress bar that at least always moved forward.
10 Likes
Just look how many cards are still in the hopper.
18 Likes
Your indeterminate process is now who the fuck knows % done. 
3 Likes
I used to work at InstallShield, and also used to code progress bars in a job after that.
Progress bars will always suck (or at least, always occasionally output something misleading), because in order for them not to suck you need to predict the future.
There’s some best practices for making good and meaningful progress bars, but nothing will solve that fundamental problem.
Displaying a % by the way, is not really that bad by itself. It’s when you try and map that to a time estimate which really infuriates users.
10 Likes
The Windows file copy dialog was terrible, but for good(ish) reasons: https://devblogs.microsoft.com/oldnewthing/20040106-00/?p=41193
The newer dialog in Win10 obviously uses a better estimate of speed, so its estimated time to finish is better, and the following doesn’t happen:
21 Likes
In the ole days, the people who ran the computer would print out the tasks that had a long completion time. IBM 360-185 completion times could be in hours, days, weeks, or I once saw one that was said the time to finish was 11.5 years. It is interesting that they programmed in ‘years’. Maybe they had centuries, millennia, eons, and kalpa too.
Of course if you want a smooth progress bar and you don’t care for Church-Turing, you could always take a 5-secod job and make it take 10 minutes. No programmer could suggest that, but someone in marketing might.
3 Likes
AS a software developer yeah it’s a PITA to implement these in a meaningful way. I prefer to give some sort of log of what’s currently happening and what’s finished in the specific terms that hopefully mean something relevant to the end user.
7 Likes
Threads like this inevitably fill up with people who are sure they have the simple solution to a problem that all the experts working for decades have failed to solve. Those of you doing so upthread, try starting from a place of humility. Try assuming that, if something everyone wants to better still sucks after all these years, maybe the problem isn’t that everyone in the entire industry is stupid. Maybe it’s that the problem is harder than you think it is, and you should seek to understand why.
11 Likes
That is generally what they do, and that works well for simple cases like download progress bars – if it changes radically that means your download speed has changed. But it doesn’t work well if the items to be processed are not all the same length or are not even known in advance.
5 Likes
Got to know if it will be done in time for Maitreya.
2 Likes
Wasn’t there a booting progress bar that was eerily accurate, because it actually recorded how long the process took last time, and remembered it for next time?
Maybe an old version of MacOS?
Also, my favourite progress bar was the “reticulating splines” on old versions of SimCity 
5 Likes
