This weekend is, I hope, something of a lull between last week’s upgrade marathons of iOS 10, watchOS 3, Xcode 8, and plenty of apps, and next week’s macOS Sierra. I really need a couple of days resting in a darkened room, and I am sure that you do too.

Upgrading is a strange experience. Even after all these decades of upgrades, it is probably our least favourite activity, and the one which attracts most adverse criticism. We enter into the process with fear and trepidation, wondering whether the upgrade will take properly, or trash everything, leaving us with long hours to recover a working system.

And once it gets started, we’re confronted with yet another highly non-linear progress bar. Yes, it’s still sat at about 90% complete, and hasn’t moved for twenty minutes. Then we get to try calibrating its scale against the nearest text, staring intently at it, to see if it is creeping forward a pixel at a time.

In any install or upgrade process, progress bars are often more trouble than they’re worth. Brad Allan Myers first wrote about progress indicators way back in 1985, and ten years ago, Chris Harrison did some more studies. They and others have pointed out many of these problems, but no one seems to have come up with a solution.

The behaviour of progress bars is strongly influenced by our perception of time. Although the latter can be highly non-linear – some events proceed in apparent slow-motion, others flash past – for the duration of a software event, such as an upgrade, they appear much more linear. The progress bar itself has an implicit linearity: when it is half-way, the elapsed time should be roughly half of the total time required. Those perceptions and assumptions are fairly rigid, and not something that a software developer can change.

When I was coding progress bars of this kind, there were two main approaches, based on the number of items to be installed/copied/handled, and their size.

For example, a progress bar for download from the internet should be based on the total number of bytes transferred, and the total to be transferred. As transfer speeds are fairly constant, when 128 MB of a total 256 MB has been transferred, you’re fairly safe setting the bar at 50%.

On the other hand, when iterating through a set of database records making changes to them, you are concerned with total number of changes, and what percentage you have achieved so far: it is then number which is usually the best metric.

I don’t know which Apple’s installers are based on, but it certainly isn’t working out, is it? Almost every update or install gives wildly inaccurate times to complete, which dart between seconds and several minutes, and the bar behaves similarly erratically.

I think that we are using a fundamentally flawed model in the human interface: no matter what is done, we expect a progress bar to fill at a fairly uniform rate. If that is not possible, get rid of the bar and replace it with a better indicator which is not perceived or expected to behave linearly. By that I don’t mean an indefinite ‘busy’ indicator like a spinning beachball – which would cause widespread panic and be hopelessly uninformative – I mean something which we don’t consider progresses linearly.

My first suggestion for this is an hourglass or sand-in-glass timer, which could even be given non-parallel sides, like an X. I don’t know, though, whether younger users are sufficiently familiar with hourglasses now to understand the metaphor, and I expect that greater minds than mine will need to brainstorm this out.

What I am confident about, though, is that Sierra’s upgrade progress bar will, like every other installer progress bar, behave highly non-linearly, and cause anxiety and frustration, and make us all feel that the experience is worse than it should be. We need to move on from what we have accepted, begrudgingly, for well over thirty years.