WEBVTT
Kind: captions
Language: en

1
00:00:00.080 --> 00:00:02.720
Whether you’re copying files,
loading a level in a game,

2
00:00:02.720 --> 00:00:04.240
or installing an app on a phone:

3
00:00:04.240 --> 00:00:08.800
it is 2021, and progress bars
and loading time estimates still suck

4
00:00:08.800 --> 00:00:11.520
just as much as they did
back when they looked like this.

5
00:00:12.240 --> 00:00:15.920
Why can’t computers just tell you
how long something’s going to take?

6
00:00:20.000 --> 00:00:23.360
Progress bars exist in all sorts
of places all over the real world,

7
00:00:23.360 --> 00:00:25.360
from countdown lights
on pedestrian crossings

8
00:00:25.360 --> 00:00:27.360
to the floor indicator
on an elevator.

9
00:00:27.360 --> 00:00:29.200
Even a line of people
queueing for something

10
00:00:29.200 --> 00:00:30.400
is a sort of progress bar.

11
00:00:30.400 --> 00:00:32.000
You know how far you’ve got to go,

12
00:00:32.000 --> 00:00:33.760
you know how fast the line’s moving,

13
00:00:33.760 --> 00:00:35.920
you can get an idea of how long it’ll take.

14
00:00:36.640 --> 00:00:39.760
More importantly, though,
you can tell that the line is moving.

15
00:00:39.760 --> 00:00:41.760
There’s a big, obvious, physical sign

16
00:00:41.760 --> 00:00:44.640
that Things Are Happening and
Progress Is Being Made,

17
00:00:44.640 --> 00:00:47.360
which means you’re more likely
to be okay with the wait.

18
00:00:47.360 --> 00:00:50.240
Particularly if you can actually
get an estimate of how long it’ll take

19
00:00:50.240 --> 00:00:52.800
or even just how many people
are in front of you.

20
00:00:53.680 --> 00:00:57.280
But as for computers:
well, they’re mysterious boxes.

21
00:00:57.280 --> 00:00:59.440
Without a progress bar,
it’s impossible to tell whether

22
00:00:59.440 --> 00:01:04.320
a task is barely started, about to finish,
or stuck in a loop it’ll never recover from.

23
00:01:04.320 --> 00:01:06.560
Or whether you’ve forgotten
to hit the start button.

24
00:01:06.560 --> 00:01:07.840
Hence: the Progress Bar,

25
00:01:07.840 --> 00:01:10.880
and its slightly fancier cousin,
the Loading Time Estimate.

26
00:01:11.440 --> 00:01:15.120
The simplest possible progress bar
takes the number of things to do,

27
00:01:15.120 --> 00:01:17.840
and shows how many of those are done.

28
00:01:17.840 --> 00:01:21.840
This video has a progress bar like that:
there’s five minutes and ten seconds of video,

29
00:01:21.840 --> 00:01:24.640
and we’ve got through one minute
and twenty-four seconds.

30
00:01:25.280 --> 00:01:27.920
That’s a pretty accurate
progress bar right there.

31
00:01:27.920 --> 00:01:29.920
Of course, the video player has one job:

32
00:01:29.920 --> 00:01:33.120
display the frames of this video
at a steady pace.

33
00:01:33.120 --> 00:01:36.560
Barring you pausing or rewinding,
it’ll probably just carry on at this speed.

34
00:01:36.560 --> 00:01:40.800
But something like installing a program
is a lot more complex and unpredictable.

35
00:01:40.800 --> 00:01:43.760
An installer might have to
download files off the internet,

36
00:01:43.760 --> 00:01:46.560
then decompress those files,
then save those files,

37
00:01:46.560 --> 00:01:49.120
along with reading or deleting stuff
that’s already there,

38
00:01:49.120 --> 00:01:51.200
and maybe make some changes
to system settings.

39
00:01:51.840 --> 00:01:54.480
Now, in theory, a programmer could
work out roughly

40
00:01:54.480 --> 00:01:58.240
how long each of those processes will take,
and bias the progress bar accordingly.

41
00:01:58.240 --> 00:01:59.680
But each one of those steps

42
00:01:59.680 --> 00:02:02.560
will take different amounts of time
on different machines.

43
00:02:02.560 --> 00:02:04.720
Downloading will depend on internet speed.

44
00:02:04.720 --> 00:02:07.360
Decompression will depend on
how fast the processor is.

45
00:02:07.360 --> 00:02:11.040
Saving, reading, deleting will depend
on how fast the device’s disk is,

46
00:02:11.040 --> 00:02:12.960
and the states of the files on it.

47
00:02:12.960 --> 00:02:15.920
And on some physical spinning disks,
it’ll even depend on where exactly

48
00:02:15.920 --> 00:02:17.680
the 1s and 0s are stored.

49
00:02:17.680 --> 00:02:20.160
And as for the making changes
to system settings,

50
00:02:20.160 --> 00:02:22.080
well, that’s up to
the operating system.

51
00:02:22.080 --> 00:02:25.520
It’s basically impossible to get a
smooth progress bar for something like that.

52
00:02:26.560 --> 00:02:29.760
But let’s say you’ve got a progress bar
that should be fairly steady.

53
00:02:29.760 --> 00:02:32.480
Like: copying 20,000 files
from one place to another.

54
00:02:32.480 --> 00:02:35.120
Surely you can just…
count the files as they go?

55
00:02:35.120 --> 00:02:38.240
Well, that’ll go wrong if one file’s
much bigger than all the others.

56
00:02:38.240 --> 00:02:40.880
Okay, so maybe it should count the
amount of data that’s been transferred.

57
00:02:41.520 --> 00:02:44.800
Sure: but that can also go wrong,
because copying lots of small files

58
00:02:44.800 --> 00:02:46.640
takes longer than a few large ones.

59
00:02:46.640 --> 00:02:50.240
It takes a little bit of extra time to
switch from copying one file to the next.

60
00:02:50.240 --> 00:02:53.520
So even for something that
seems like a simple task,

61
00:02:53.520 --> 00:02:55.200
the bar could speed up and slow down.

62
00:02:55.920 --> 00:02:58.160
Fine. Maybe you work out
all of that in advance,

63
00:02:58.160 --> 00:02:59.360
you program it really carefully

64
00:02:59.360 --> 00:03:01.600
so that the progress bar can
be as smooth as possible.

65
00:03:01.600 --> 00:03:03.920
Very few programmers think that’s
really worth the effort,

66
00:03:03.920 --> 00:03:04.880
but let’s say you try.

67
00:03:05.440 --> 00:03:07.760
And then you add a
“time remaining” display,

68
00:03:07.760 --> 00:03:10.880
based on how long it’s taken so far,
and how much there is still to do.

69
00:03:12.000 --> 00:03:13.600
That will still go wrong.

70
00:03:13.600 --> 00:03:15.840
Because the speed of your transfer,
or your download,

71
00:03:15.840 --> 00:03:17.280
or your complicated video render,

72
00:03:17.280 --> 00:03:19.600
all of those speeds could
change at any time

73
00:03:19.600 --> 00:03:22.800
because of what the device is doing,
or what the user’s doing.

74
00:03:22.800 --> 00:03:25.520
Maybe a desktop user switched
to another window because they were bored,

75
00:03:25.520 --> 00:03:29.360
and now the computer’s got to deal with
playing a game as well as rendering video.

76
00:03:29.360 --> 00:03:32.880
Maybe a phone user got a notification,
and now the device is struggling to download

77
00:03:32.880 --> 00:03:35.280
a video clip that someone’s sent in a group chat
in the background.

78
00:03:35.840 --> 00:03:38.000
Maybe the computer is starting to get too hot,

79
00:03:38.000 --> 00:03:41.360
so it slows down its processor
to avoid being damaged by overheating.

80
00:03:41.360 --> 00:03:43.600
Or maybe the device just decided that now

81
00:03:43.600 --> 00:03:46.240
would be a really good time to do
some maintenance in the background

82
00:03:46.240 --> 00:03:50.640
because… well, who knows why,
apparently it just decides that sometimes.

83
00:03:50.640 --> 00:03:53.040
One option is to take a “rolling average”:

84
00:03:53.040 --> 00:03:56.960
rather than just naively estimating based on
the time it’s taken for everything so far,

85
00:03:56.960 --> 00:04:00.080
you look at how much has been done in
the last ten seconds, or twenty seconds,

86
00:04:00.080 --> 00:04:02.480
and extrapolate from just that bit.

87
00:04:02.480 --> 00:04:05.200
It’ll still probably be wrong,
but it’ll be differently wrong.

88
00:04:05.840 --> 00:04:09.600
Or, and I think this is why most programmers
don’t spend too much time on this,

89
00:04:09.600 --> 00:04:12.480
you could accept that it doesn’t
actually matter all that much.

90
00:04:12.480 --> 00:04:15.440
Progress bars don’t have
to be perfectly accurate.

91
00:04:15.440 --> 00:04:18.080
Actually, a perfectly smooth
progress bar does kinda imply

92
00:04:18.080 --> 00:04:20.080
there’s some trickery
going on behind the scenes,

93
00:04:20.080 --> 00:04:23.800
like scammy web sites that make you artificially
wait ten seconds for something to load,

94
00:04:23.800 --> 00:04:26.320
just so they can show you an ad in the meantime?

95
00:04:26.320 --> 00:04:29.920
I reckon progress bars should be
just a little bit janky,

96
00:04:29.920 --> 00:04:32.080
because they reflect something
that’s really happening.

97
00:04:32.960 --> 00:04:36.720
And besides, the most important job
of a progress bar is not

98
00:04:36.720 --> 00:04:39.360
to give an exact, precise estimate
of how long is left.

99
00:04:39.360 --> 00:04:41.440
It's great if they can, but
the most important job

100
00:04:41.440 --> 00:04:44.640
is just to reassure the user that, yes,
things are happening,

101
00:04:44.640 --> 00:04:46.160
progress is being made,
calm down,

102
00:04:46.160 --> 00:04:55.840
don’t try to reboot the machine
just because you think it’s cra--