Whether you’re copying files, loading a level in a game,
or installing an app on a phone:
it is 2021, and progress bars and loading time estimates still suck
just as much as they did back when they looked like this.
Why can’t computers just tell you how long something’s going to take?
Progress bars exist in all sorts of places all over the real world,
from countdown lights on pedestrian crossings
to the floor indicator on an elevator.
Even a line of people queueing for something
is a sort of progress bar.
You know how far you’ve got to go,
you know how fast the line’s moving,
you can get an idea of how long it’ll take.
More importantly, though, you can tell that the line is moving.
There’s a big, obvious, physical sign
that Things Are Happening and Progress Is Being Made,
which means you’re more likely to be okay with the wait.
Particularly if you can actually get an estimate of how long it’ll take
or even just how many people are in front of you.
But as for computers: well, they’re mysterious boxes.
Without a progress bar, it’s impossible to tell whether
a task is barely started, about to finish, or stuck in a loop it’ll never recover from.
Or whether you’ve forgotten to hit the start button.
Hence: the Progress Bar,
and its slightly fancier cousin, the Loading Time Estimate.
The simplest possible progress bar takes the number of things to do,
and shows how many of those are done.
This video has a progress bar like that: there’s five minutes and ten seconds of video,
and we’ve got through one minute and twenty-four seconds.
That’s a pretty accurate progress bar right there.
Of course, the video player has one job:
display the frames of this video at a steady pace.
Barring you pausing or rewinding, it’ll probably just carry on at this speed.
But something like installing a program is a lot more complex and unpredictable.
An installer might have to download files off the internet,
then decompress those files, then save those files,
along with reading or deleting stuff that’s already there,
and maybe make some changes to system settings.
Now, in theory, a programmer could work out roughly
how long each of those processes will take, and bias the progress bar accordingly.
But each one of those steps
will take different amounts of time on different machines.
Downloading will depend on internet speed.
Decompression will depend on how fast the processor is.
Saving, reading, deleting will depend on how fast the device’s disk is,
and the states of the files on it.
And on some physical spinning disks, it’ll even depend on where exactly
the 1s and 0s are stored.
And as for the making changes to system settings,
well, that’s up to the operating system.
It’s basically impossible to get a smooth progress bar for something like that.
But let’s say you’ve got a progress bar that should be fairly steady.
Like: copying 20,000 files from one place to another.
Surely you can just… count the files as they go?
Well, that’ll go wrong if one file’s much bigger than all the others.
Okay, so maybe it should count the amount of data that’s been transferred.
Sure: but that can also go wrong, because copying lots of small files
takes longer than a few large ones.
It takes a little bit of extra time to switch from copying one file to the next.
So even for something that seems like a simple task,
the bar could speed up and slow down.
Fine. Maybe you work out all of that in advance,
you program it really carefully
so that the progress bar can be as smooth as possible.
Very few programmers think that’s really worth the effort,
but let’s say you try.
And then you add a “time remaining” display,
based on how long it’s taken so far, and how much there is still to do.
That will still go wrong.
Because the speed of your transfer, or your download,
or your complicated video render,
all of those speeds could change at any time
because of what the device is doing, or what the user’s doing.
Maybe a desktop user switched to another window because they were bored,
and now the computer’s got to deal with playing a game as well as rendering video.
Maybe a phone user got a notification, and now the device is struggling to download
a video clip that someone’s sent in a group chat in the background.
Maybe the computer is starting to get too hot,
so it slows down its processor to avoid being damaged by overheating.
Or maybe the device just decided that now
would be a really good time to do some maintenance in the background
because… well, who knows why, apparently it just decides that sometimes.
One option is to take a “rolling average”:
rather than just naively estimating based on the time it’s taken for everything so far,
you look at how much has been done in the last ten seconds, or twenty seconds,
and extrapolate from just that bit.
It’ll still probably be wrong, but it’ll be differently wrong.
Or, and I think this is why most programmers don’t spend too much time on this,
you could accept that it doesn’t actually matter all that much.
Progress bars don’t have to be perfectly accurate.
Actually, a perfectly smooth progress bar does kinda imply
there’s some trickery going on behind the scenes,
like scammy web sites that make you artificially wait ten seconds for something to load,
just so they can show you an ad in the meantime?
I reckon progress bars should be just a little bit janky,
because they reflect something that’s really happening.
And besides, the most important job of a progress bar is not
to give an exact, precise estimate of how long is left.
It's great if they can, but the most important job
is just to reassure the user that, yes, things are happening,
progress is being made, calm down,
don’t try to reboot the machine just because you think it’s cra--