Progress bars still lie

A progress bar should not indicate progress over multiple tasks — a segmented progress bar is better, or a series of spinners, or just a single spinner for the whole set. A progress bar should measure exactly one metric, where the total is known.

This seems a little funny to me, since the purpose of the spinner is so that you know the computer isn't caught in a loop — it's "busy". It's true, though, that the computer could still be stuck even though it updates the spinner. This is a hard problem to solve.

Abusing progress bars are not a good response to this, though. I would rather trust progress bars for what they are meant to show rather than as an indication of true activity. After all, you still can't tell whether the progress bar kept moving, but the process is stuck in a loop.

The progress bar for software updates and file transfers on macOS are infuriating. They’re decidedly unhelpful, and more often drastically wrong than anything I could imagine implementing myself. So wrong that it seems some significant improvements would be really low hanging fruit, if they cared to try:

- Doing anything with many smaller files will perform worse than fewer, larger files. Factor in a size/quantity multiplier/ratio on initial estimate. For APFS, I think the information needed should be available from init. For other file systems, this information should be gathered in a background process and feed the estimate as it accumulates.

- Revise the estimate more frequently, but not so frequently it produces pink noise. Apple’s progress bars notoriously get stuck for long periods, even hours. This isn’t just a bad user experience, it’s actually dangerous. Users frequently interrupt long running processes they perceive to be stalled, even if progress is ongoing but merely hard to observe. Swinging too far in the other direction at least gives an indication that something is happening, but the values become meaningless (I don’t know if this is still the case on Windows but I distinctly remember laughing uncontrollably watching estimates rapidly vacillate between seconds and hours, while overall progress appeared to have a steady pace).

- Revise the estimate based on expectations versus reality. As in, if your predetermined formula says 1000 small file operations take 15 seconds, but a comparable workload takes 30... and vice versa for large file operations... measure that! You don’t need machine learning for this, just a sufficiently proportionate time window to do some basic arithmetic.

- Provide additional observable feedback when these adjustments take place, and when there’s nothing to report other than something is taking a long time to generate more meaningful feedback. This doesn’t have to be ugly or noisy, it can be as simple as expanding the progress bar or messaging that progress is really ongoing even if you have no more information to report.

- Give us nerds a log! Please for the love of all that’s good in the world, let us see the sausage go through the grinder, even if we need to know a magic incantation to conjure it. And supplement it with a heartbeat message during long runs so we also don’t fall prey to dangerously assuming the process has stalled.

- I know Apple is notoriously minimalist in its UX style (most of the time), but maybe more information is sometimes actually less. As an example, major OS updates often quietly include multiple stages like firmware updates that require a reboot or temporarily disabling the display. These can be very alarming to users who don’t know what happened! Again, not just bad UX, it can be misleading and users may assume they’ve experienced failure or even an update loop that won’t terminate. A small amount of communication to set expectations could go a long way to alleviate that. A simple list of the overall steps and a bit of warning before a major visual disruption to observable progress would significantly reduce the chaotic list of assumptions users might be imagining.

- Maybe these updates are just too big, and doing too much at once. I mean, I understand that a major version update is going to have bigger subsystem impact, but maybe some of the ancillary stuff can be deferred. As an example, a major version update could get enough of the underlying update in place to get the machine in a usable state, then prioritize user land updates based on demand and run the rest in a background process.

- If you just don’t know, maybe it’s better to just be more vague. Apple popularized the spinner where progress is indeterminate. Use it as a last resort!

You know what I like for progress bars? The mess that is your average build script.

Tell me how many tasks there are to complete, how many you've done, and some rough details of what you're doing (e.g. is it a network request). Don't be shy about commentary ("This may take a while", "If this fails multiple times do X").

These generally contain all of the information that the developer has access to, and rarely am I left having no idea if something's failed, or what to do if I know it's failed.

Now I'm not suggesting that this is good as-is for non-technical users, but it feels wrong-headed keep iterating on a solution everyone hates (progress bars), rather than trying to adapt a solution that (if other people feel the same as me) is quite well-liked in its domain.

You see a sort of adaptation in some progress bars with the "Show details" button, but that generally sanitised variant, with one line per task and no commentary (and often, for some reason, no task count) feels like it misses all the good parts of what it's emulating.