Hacker News Reader

Comment by jdietrich | Hacker News Reader

It's really just an audio version of a loading bar or spinner - users get really uncomfortable if the UI becomes unresponsive for even a few hundred milliseconds, but they'll wait for several seconds if it looks like something is happening.

View on HN

People have learned that the spinner is non-progress, though. The progress bar still has some life in it, except that those are often fake, not measuring progress.

OS-level cursor spinners like the mac pinwheel have lost credibility, because they don't reliably indicate whether the system is temporarily unresponsive or needs to be restarted. Modern multitasking OSes have a wide range of situations in which they can become mostly unresponsive without actually crashing.

Spinners on the application or UI element level are more credible, but generally worse than a progress bar. They're still very useful as a comfort indicator for short delays.

Progress bars have very low credibility on Windows, because users have learned that they're basically useless as an indicator of wait time. A progress bar might get stuck at 7%, then suddenly rush to 100%; conversely, it might get stuck at 95% but never finish. The bar offers no real indication of the actual level of progress; in most cases, this could be greatly improved with a bit of educated guesswork.

A completely fictitious progress bar can be extremely credible, because it's totally predictable - if you need to create a 10 second delay, then it's easy to make the bar progress linearly from 0% to 100% in that time. Users learn very quickly that your progress bar tells the truth about how long they'll be waiting, even though it's lying about the reason for the wait.

> Progress bars have very low credibility on Windows, because users have learned that they're basically useless as an indicator of wait time. A progress bar might get stuck at 7%, then suddenly rush to 100%; conversely, it might get stuck at 95% but never finish. The bar offers no real indication of the actual level of progress

I disagree with this; I find the progress bars more credible with erratic timing. (And ideally, a display of the task currently at hand, like "Copying tiny file. Copying tiny file. Copying giant file............")

A progress bar that smoothly fills from 0 to 100 looks like an animation that somebody thought it would make you happy to watch. A progress bar that lags at 7% and then rushes the rest of the way looks like the software has some internal metric for task completion, and is reporting according to that metric. This implies that when the number changes, progress has happened, which isn't the case for a progress bar that isn't affected by workload.

The software can't use "how much time has elapsed?" as a progress metric, because it doesn't know how much time things will take, and because the passage of time does not actually cause -- or reflect -- any progress. That progress bar would be a spinner, not a progress bar.

> Spinners on the application or UI element level are more credible, but generally worse than a progress bar. They're still very useful as a comfort indicator for short delays.

Strongly disagree. A spinner on the web UI element that lasts longer than ~1 second indicates for me that the site's JavaScript broke again, and it's time to reload or wait for the devs to notice and fix it.

He's not talking about the cursor.

He's talking about a circular loading animation. Like the one that replaces the submit button when you're making a post on Twitter/Facebook.

I'm talking exactly about that spinner. It's a lie. You quickly learn it has no relation whatsoever to what's happening in the background. And indeed it doesn't, because it's an animated GIF, completely detached from any logic or networking code!

(Compare the CLI spinner/fan - that "/ - \ |" animation used to indicate progress. There you know that each tick of the spinner means work has been done, because it has to be animated from code, and it's much simpler to just update it from the code that does the work.)

That's not true at all. In the websites I and many others build, that loading spinner is linked directly to network code.

The spinner appears when a request is made. It disappears when the request is resolved.

I was talking about animation. Show/hide on request made/resolved gives only binary information about starting and finishing something. But the spinning animation itself does not represent any operations being executed. It may very well be that the request failed and a bug in JS made it not remove the spinner. You end up with a forever-looping animation of "work", even though no work is being done. This makes the spinner an untrustworthy element.

Still better than nothing? Sure, maybe sometimes exceptions aren't handled properly, but at least you know that it was trying to do something, rather than having users click a submit button 10x because there was no UI feedback whatsoever.

The most annoying part of progress bars is the fact that programs so often use multiple bars. What's the point of watching a bar slowly reach 100%, only for it to be replaced with another progress bar that starts from 0 again?

My apps add a second "outer" progress bar for that use-case.

The "please wait while we verify your passcode" on our corporate phone conference system drives me nuts. In the time that it took to speak that sentence, the passcode could have been verified millions of times.

That may be yet another use case of delays: makes bruteforcing (or even plain guessing a few common codes) a lot slower.

In true market economy fashion, the comfort noise is also a perfect advertising opportunity.

For instance, I frequently deal with ATM machines that display "please wait" screens between every operation. Those screens last usually between 1 and 3 seconds, and it's obviously because the operations take that long, and totally not because they also display a half-screen or full-screen ad...

Reply on news.ycombinator.com