Hacker News Reader

Comment by paxys | Hacker News Reader

Progress bars are something that have been researched and iterated on for decades now, and the overall sentiment is pretty clear – users like seeing numbers go from zero to a hundred while they wait. It doesn't matter if they aren't always accurate. Replacing them with a static "processing" message would absolutely increase user confusion and dissatisfaction with loading times.

A while ago we put in a lot of engineering effort to build a good progress system for a heavy, multi-step background task to show to our users, and the overwhelming feedback was - "it always gets stuck on a certain percent", "it is too slow" and "it is unreliable". After feedback from design we hard-coded it to a steadily increasing bar regardless of actual progress, and the complaints all stopped immediately.

View on HN

As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung".

I think the best option is simply X/Y bytes downloaded, like Blizzard does on WoW patches. The fraction indicates how much is left to download, and the rate of the numerator changing informs how quickly the download is going.

You're bringing up the easiest use case though. Most complex flows cannot be easily expressed by a single determinable metric.

Complex flows can be represented by a tree control full of checkboxes that tick off for things that are done, which can be hidden behind a "show details ..." button next to a regular progress bar. If the users can see the detailed tasks, maybe they will be less ticked off by a jumpy progress bar.

Or just show verbose logs like Apt GUI frontend.

Problem with just logging the progress is that the user has no idea where he "bottom" is. A log might as well be a spinning cursor or any other animation.

It's invaluable from a troubleshooting perspective, though. "Hmm, it always seems to get stuck when installing this particular package"

This is the most infuriating part of progress bars to me. When it hangs I don’t even have a jumping off point for Google. I can only search “foo hangs during install” which almost always results in issues that are not the problem I’m experiencing because usually the most common reason isn’t the reason the majority of the time. “Foo hangs during ‘reticulating splines’” usually has far more useful results.

Had problem when GUI closed after trying to install a package. No error, no logs. (or was it defaulting to the normal state with install button and no logs, I don't remember)

Found out about package conflict only after running apt from the terminal.

If you can reliably break down your complex flow into a tree of checkboxes, you could just as easily render a truthful progress bar based upon how many sub tasks are done.

Yes, but that bar would still get hung intermittently whenever a specific task took a long time.

How is the checkbox thing any different? If one task blocks progress, the tree also doesn't update

I don't know whether it _will_ be any different, but there was some speculation about that:

> If the users can see the detailed tasks, maybe they will be less ticked off by a jumpy progress bar.

Context. You see not just the thing currently executing, but also the things remaining to be executed - which allows you to mentally gauge which of them may slow down.

At least I know what it is doing at the moment its blocked (and in many cases I can tell whether that is justified to take N time or not).

With a progress bar I don't know anything.

A tree is insufficient for flows at $dayjob, you need a directed acyclic graph to handle fanout/parallelism.

For which a visualization exists internally, but every time someone decides to "fix" the progress bar problem they do a one-off analysis and only wire up the three biggest steps to the bar.

> As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung".

This is an important point. "Lying" progress bars are still conveying essential information - that the installation is progressing and isn't frozen. I remember from my days working with W98 and early Ubuntu versions, one of the most important bits of information coming from progress bars was whether or not the whole thing was frozen and needed the power cord pulled.

Well, not necessarily, if the GUI with the progress bar and the installation or whatever are on seperated threads.

That's true on the backend, but it doesn't help the end user much, since they don't know that.

Heh, I've imagined a message like:

"Your task has started and is processing in the background where it can't be observed. Please wait."

[OK]

I've seen Google display progress bars showing that my page is loading, even when I've totally lost internet connection and I know it will never load. The progress bar goes as something like 1-e^-t, so it just asymptotically approaches 100% but never gets there. When it's that kind of lie, I don't think it's conveying any essential information.

IE6 also did this back in the day, it was infuriating.

Even worse than not conveying information, it diminishes your user's trust in your product if they realise the progress bar is bullshit.

The "system is not hung" signal is dead now due to modern platforms making sure that nothing happens on the UI thread. Now we get buttery smooth 60 fps spinners and loading bars, but if the thread doing the real work hangs, there's no indication.

Exactly this. And spinner gifs are particularly useless, because they're that - gifs. Not progress indicators that need to be explicitly told by code to spin a bit more. Just fire-and-forget animations, that will keep to spin forever even if your processing code dies.

Totally agree. I was rather intentionally using examples from more than a decade ago, where I was using the progress bar to observe whether or not the whole system was hung.

This was back when my best computer had a 500 MHz CPU and 512 MB of RAM.

<fixes his glasses> There was never a time when

>best computer had a 500 MHz CPU and 512 MB of RAM

500 MHz cpus started showing up in servers with 21164 in 1996 in boxes maxing out at 2GB ram, and on desktops with 1999 Pentium 3 plugged into 1998 chipset (440BX) already supporting 1GB.

I didn't say I wasn't a broke kid at the time. ;)

Really all you need is 32 KB of RAM

https://youtu.be/CPRvc2UMeMI?t=85

Will Google pick up the connection again when it's available? And could that theoretically happen at any moment?

If so, it doesn't seem completely unreasonable to communicate in this way. (I agree it could be communicated better)

The system is not quite hung, but it's not doing great.

I had disconnected my router, so I don't think Google was going to pick up the connection again.

At the very least, there's no sense in which the page loading (or map route finding, etc) was farther along at t=2 than it was at t=1 when the connection was removed, so for Google to be telling me it's making progress in that situation is a transparent lie.

Unless the information they're trying to convey with the progress bar is simply that "time is passing", which I'm well aware of.

UI toolkits include "indeterminate" progress bars. Back before AJAX spinners (really, a simplified form of indeterminate progress bars) took over, they were a blob that bounced back and forth, or scrolled left to right repeatedly, within the progress bar's trough. Sometimes, a barber pole. The good ones would only advance the animation so long as actual progress was occurring, so that a hung system was indicated by a hung animation.

There's no reason to lie.

The problem with AJAX spinners is that they’re often just GIFs or CSS animations that will keep on playing even if “the system has hung” (e.g. the AJAX request failed and there’s no client-side error handling logic, no retry, no error display, and no UI cleanup) so in that respect the situation now is worse than it was before.

Yes, I agree with that for the case of AJAX spinners. A lot of web software fails to handle errors (resulting in the AJAX spinner spinning on — I think we've all seen this all the time¹) and most don't connect progress events to the animation in any way. There's no reason web-based libraries couldn't provide utilities for that, other than they don't, the existing code is of poor quality, and the APIs that browsers provide don't really push one towards the high-quality solutions in any way (since you really have to either get this level of functionality from some sort of library, or build it yourself).

My point is that good UI is possible, there is even precedent for it, and that while we definitely need to do better perhaps with available APIs or tooling, that is not an excuse for the moral failing of lying to the user.

¹and I'd say that's even the mild case. A number of high-profile websites that encounter even edge cases — not even errors — just simply fail to render at all.

Alternatively you can flash actions on the screen, even if the user cannot read or understand what these actions correspond to, it conveys the message that work is being done (it’s not hung) without lying on how far you think we are into the process (if you don’t have that visibility).

if you give numbers of any sort, users will try to mentally do the math to convert that to a percentage -- and at that point, you might as well give them a progress bar.

If you instead just show a description of the current task, users will want to know how many tasks are left. if you tell them how many are left, they will revert to thinking of it as an overall percentage.

i'm a fan of "checklists" that get ticked off as the process progresses; possibly with progress bars for specific tasks, if they have a straightforward way of measuring that (like % downloaded). but i almost never include an overall progress bar for a multi-step process. it keeps the user's focus on the current task, while still providing some information about what's to come.

That works for completion status, but I don't think it works for task failure notification. Do you know of any clever way that reliably informs the user whether or not the process is frozen?

I bet $100 Netflix does the same. From my "experiments" during outages, it seems to show you a timer based progression from 0-25% no matter what, while it waits for stuff to queue/load properly, then it takes off to 26-100% in short order.

So when it Netflix is up, it slowly climbs 1-5% then rockets to 100% and plays.

When it's slow, sometimes it goes to 15%, then rockets up.

When it's down, it reaches 25% after 12.5s or whatever it is, then sits there forever/shows an error message.

When my internet connection is down I get 99% sometimes from Netflix. I typically use the PS4 client so maybe that’s the difference.

It's actually representing the users patience level and reflecting that back at them like a mirror.

Yea I've noticed that as well. If it stops on 25% then I know something is broken over at Netflix. If it stops at any other number then it's just something being slow, but will start eventually.

At my first job we made training simulations. One day someone decided to do make our loading bar more accurate by splitting loading into several segments and keeping a local record of the average time to load each segment. The result was a smooth progress bar from 0 to 100. We were proud of it.

Years later I worked on a popular AAA franchise and we had replace our loading screen spinner with a progress bar due to console requirements. We simply estimated a worst case scenario and made the bar driven by a timer from zero to this number, smoothly speeding towards 100 when loading was done. People kept complaining that something felt off and it didn't seem reliable.

The failure mode becomes the bar stops at 99 or 100 but the game doesn't run, or worse, the bar flies off the end of the chart, hitting 101%, 102%, etc...

Neither of those could happen since it was capped at 100 and the time to fill it was just below the timeout.

Neither could happen if nothing went wrong. What if there is a hardware issue that makes it much slower at reading data than usual, like excessive CRC failures that require loads of retries to get a good read?

Lying often reduces complaints. This doesn't mean users like being lied to, it means they don't know they are being lied to.

Users aren't being fooled here. People learn that progress bars aren't accurate, and things like the author mentioned, "when it gets to 75% it will really be done".

First, no, as the other comments here attest, the end result of constant lying is that nobody trusts progress bars at all; if things reliably finished at 75%, progress bars would be easy, but they don't so they aren't. Second, that people soon get used to being lied to does not make lying OK.

I don't think you are in disagreement.

Neither of Jeremy Bank's sentences are relevant to my first comment if you try to contort their interpretation so they do not conflict with me.

To me, JeremyBanks' second sentence clearly implied that users don;'t trust progress bars anymore, and your comment was unnecessary. He is also certainly implying that lying is not OK. Interpreting them otherwise seems like a strange kind of contortion to me.

I think you're clearly misinterpreting, but it's not worth discussing. JeremyBanks can clarify for himself if he wants.

"After feedback from design we hard-coded it to a steadily increasing bar regardless of actual progress, and the complaints all stopped immediately. "

Are you talking about progress bars, that go steadily up to 99 or 100% and then stay there, until the actual progress is done? They can cause big frustration, too ...

The approach for this is to simply restart the bar from 0% and display some bogus message implying it is now doing another task. Always keep moving.

Oh yeah, I love those equally. Getting hopes up - to finally crush them.

Reticulating Splines

The Sims (1, at least) had a fixed set of startup messages, in the same order each time.

The trick is to smoothly animate the filling of a random percentage of the remaining unfilled bar between, say, 30% and 70%, with the timing of the advancements themselves slightly randomized. A sort of Zeno’s progress bar. It will neither peg at 100 nor shoot past, and the pulses feel “organic”. Bonus points for advancing the bar to known fixed points of progress when real feedback is received.

The amount of complexity needed to lie to the user this way is becoming comparable with the amount needed to do the job right in the first place.

> After feedback from design we hard-coded it to a steadily increasing bar regardless of actual progress, and the complaints all stopped immediately.

This seems like a surefire way to end up with a progress bar at 8675309%, or a progress bar that gets to 100% and then sits there waiting for reality to catch up. And I say this from experience, having seen both of these failure cases numerous times in the wild.

If users are frequently reporting that the application's getting stuck at a particular percent, then - to me at least - that's valuable information for whether I should consider doing some optimization to speed up whatever step in the process corresponds with that progress percentage, or to break down that step further into smaller steps to keep things moving, or both.

This is because when I was growing up (Windows 95 era), it was normal for a computer to just completely freeze regularly. If I saw a static "processing", I'd assume the computer froze and would rip out the power after like 5 seconds.

Is the bar exceeds 100% in worst case?

Reply on news.ycombinator.com