Hacker News Reader

Comment by pohl | Hacker News Reader

This defeats the point of a loading bar: it’s supposted to give an estimate of progress, not fill up at a rate entirely unrelated to actual loading!

I'd say it's actually fulfilling the real point of a loading bar: to keep the user pacified through some period of waiting that you couldn't engineer away.

View on HN

I understand that the ideal 1-to-1 progress bar is not worth making, if it's even possible, but they should at least be proportional to actual progress. I want a progress bar that goes up if and only if there are responses being received, and processing of those responses completes. Progress bars that continue to fill up even when everything is completely hung make my blood explode.

But why? Why is that important?

So the user knows if they should stop waiting, reload/refresh/restart, or just hang tight.

If a progress bar or loading animation does not stop when something goes wrong, the it is conveying zero information and shouldn't be there.

Because you want to know if there was an error during loading and it's not progressing anymore, instead of a forever-increasing loading bar that just makes you wait.

You know what's worse than being not having a perfectly accurate representation of something?

Being told that something is working when it has crashed and you'll only notice it after a long, unknown time because the damn output is lying to you.

Animations are indeed great for that but that's not a progress indicator. Those are two distinct things.

The one is just to distract the user for some time. The other is to signal that something's going on, and indicate the progress of that (background) task.

A distracting animation is only good to hide some latency. In cases where progress will be made eventually for sure and in a predicable amount of time.

If there is a task you can't be sure about when or even if it completes an animation is not the right tool. There you need a proper progress indicator.

100%. Loading indicators are psychological placebos for the user.

Reminds me of a story my old boss used to tell about how they dealt with complaints about long waits for elevators in one high-rise building: putting mirrors on the walls. With sufficient distraction (everyone likes looking at themself, or at least can't help it) the elevators were no longer "too slow"!

Once one gets old enough, you'll just get up and pee whenever something is slow on the computer.

I've been known to get up and code whenever something was too slow on the toilet.

I sort of miss the 5 minute compile time coffee breaks.

Or you can just drink too much coffee and la croix and have to pee all the time. :)

I read once how they kept elevator attendants long after they had any use as a placebo to help people get acclimated to automatic elevators.

Maybe on the web. But I feel on the web they are often not even there to mask load times but are just used as powerpoint-transition-like-effect. And also to prevent the user from seeing page-jumps when the page first loads.

But as an anecdote of where a progress bar was more than just cosmetic: Couple of years ago I attempted to upgrade to a new MacOS on my Macbook and the install ran into some error but gave no indication whatsoever. So the only info I had was that the progress bar hadn't moved at all in 5 hours. I waited another couple of hours before I switched it off and tried again. Without the progress bar I probably would've waited another day. I mean my macbook was still bricked but at least I could compare it to screenshots online of people getting stuck at the same point, allowing us all to blame Apple :)

That's quite a specific scenario but anytime it's difficult to debug what's actually happening, I wouldn't say progress bars are just cosmetic.

Off topic, but that's why I hate GUIs and animations hiding log output of the system when it's doing something important.

With a text console you can see exactly what was going on and in case of where it hung.

Then at least be so kind to ensure the spinner stops if there is an error.

I've seen enough spinners tgat will happily keep going if there is a network outage.

I think this is the difference between "communicating that there is still processing being done, even if I can't give a progress estimate" and - as you say - "keeping the user pacified". First one is helping the user, second one is really just a "not my problem anymore" asshole move.

Reply on news.ycombinator.com