Why do computer progress bars suck as much now as they did back in the ASCII days?

[RickMycroft]

@joey_bladb

That and making sure that desktop icons show the correct image and open the right app when you click on them.

Maybe, but programs that trigger frequent desktop refreshes are vermin to be hunted down and killed.

[Richard_Kirk]

@nixiebunny

I’ve been spending a lot of time lately recompiling VHDL programmable logic code for a new spectrometer. The Xilinx Vivado tool that I’m using has a log file that shows the program’s progress as it does all the work. This is quite helpful, even though there’s no estimate of the total time.

This was my experience, when writing a program with a progress bar (weirdly, also for updating the software with a spectrometer, but nothing as fancy as yours). There were several phases - backing up the calibration and settings, checking the boot loader, loading the software, checksumming the load, and so on. The loading used serial over USB, and this performance was very variable, depending on the exact OS. The best solution I could find was…

Have a line saying briefly what it is doing. That way you can say “oh, this is where it slows right up”.

Have progress as a bar and a figure “12.34 % done” with enough precision to show you progress in seconds if it is going to take hours.

I tried giving time estimates too, based on the last figures, but this was a job that people rarely did, and the last update may well have been on a different machine.

[Richard_Kirk]

@prooftheory

@Richard_Kirk

kalpa

Got to know if it will be done in time for Maitreya.

At the height of Moore’s Law, any computer running a job that took more than about 18 months could be overtaken by a newer computer. The computer proof of the 4-colour theorem was an algorithm with known inefficiencies, but they daren’t stop the computer, as it was racing against a rival program.

Then we get quantum computing, and progress cannot be measured at all. Fun times.

[jruschme]

Maybe it was just me, but it seemed like older Windows installers (say Win95 through XP) would always initially estimate 40 minutes. I always wondered if someone was tasked to come up with a number that was big enough to approximate the real time needed but not so big as to scare people off.

[alahmnat]

@Avery_Thorn

Even if you don’t know how long something is going to take, or how many somethings you have to do… it might be better to fill the bar, then blank it and start over again than to not update until you know.

This is an even larger challenge when you’re interfacing with additional systems that are black boxes. I can give you all the granular information and smooth progress bar loading you like about how I’m doing with, say, getting transactions ready to sync to QuickBooks, but once QuickBooks has it, I might a well just lock my own thread for all the good it’ll do me.

@ikeOnABike’s GIF is actually a pretty good representation of the behind-the-scenes nonsense that frequently makes progress bars less useful than they should be.

[joey_bladb]

My absolute LEAST FAVORITE progress bar UX is Apple’s macOS installer.

It’s a slow process and usually counts down from 30 minutes. It chugs along, occasionally tells you what it’s doing, and then it gets to 1 minute remaining and will then hang there for another 10-20 minutes. EVERY SINGLE TIME.

The first time this happened I just figured it had crashed so I rebooted only to find it was all just hosed because apparently that “last minute” of unreported “progress” is spent re-writing the boot sector or whatever. After a few more times I learned to just block out an hour in my calendar to go offline and let the update run out of sight and out of mind.

[anon81034786]

@joey_bladb

It’s a slow process and usually counts down from 30 minutes. It chugs along, occasionally tells you what it’s doing, and then it gets to 1 minute remaining and will then hang there for another 10-20 minutes. EVERY SINGLE TIME.

I just figured that an Apple minute is not the same unit of measurement as an Earth minute.

[stinkinbadgers]

@anon81034786

I just figured that an Apple minute is not the same unit of measurement as an Earth minute.

Sadly Apple never followed through on the proposal to include a Jobs Reality Distortion Field Generator inside every Mac specifically to address that problem.

[smulder]

@8-p

Linux filesystems rarely suffer from the kinds of fragmentation that “good” old FAT

I have never known whether that was actually true or just classic sour grapes

“We don’t have a decent defrag utility, so therefore we must not need one”

Disks are so much faster now, would we even notice fragmenting problems, regardless of file system?

[8-p]

It’s true. It’s in the filesystem design. Ext3 and Ext4 filesystems can still get fragmented if they get really full, FAT is just lousy. Even with fast disks it can be noticeable depending on what you are doing.

[anon81034786]

@smulder

Disks are so much faster now, would we even notice fragmenting problems, regardless of file system?

Database applications with high read/write operations still suffer latency from fragmentation of the physical disk.

[Purplecat]

@anon81034786

I just figured that an Apple minute is not the same unit of measurement as an Earth minute.

It isn’t, but you can buy a converter dongle for $80.

[FGD135]

But how does one implement a progress bar for an infinite memory tape?
Something that constantly flips between 0% and 100%?

[joeluser666]

this really has nothing whatsoever to do with the halting problem (which applies to the general class of all programs and all input and which is only undecidable for specific rogue cases). progress bars are found in known, analyzed, deterministic programs which generally have strictly limited inputs. so no surprise the video didn’t mention it.