60 milliseconds is when we notice something isn’t immediate. Any user interaction, that involves sending data over the network or doing heavy computation on it, usually takes way longer than 60 milliseconds. So, we end with a progress bar. There are two broad categories of progress bars, one that shows the absolute/relative progress, a determinate progress bar, and one that does not an indeterminate progress bar.

Fancy but will this ever finish?

Now, here’s what’s the state transition looks like, task started -> task progressed -> task finished/failed.

So, ideally, a software engineer should be implementing all these states. Most don’t. Some push the error handling to a later point. And then forget.

In such a situation, the indeterminate progress bar just stays there, spinning and spinning. While a determinate progress bar actually stops. So, a determinate progress bar not only communicates the speed of progress to the user but also, communicates if the progress has stalled.

So, why aren’t they more popular? Probably because it is a bit more work, you have to decide what the unit of work is. And if you are too off, the progress can look arbitrary. In my belief, even if the progress looks like a car navigating a bunch of speed breakers, it is superior since it communicates more actionable information to the end-user.

Slow towards the end but the user can see the rate of progress and if the job is stuck