Hacker News Reader

Comment by quacked | Hacker News Reader

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.

View on HN

> 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.

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.

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.

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

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.

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

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.

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]

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.

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.

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

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.

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.

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 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?

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).

Reply on news.ycombinator.com