[generalizations]

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

[jbay808]

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.

[admax88q]

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.

[TeMPOraL]

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.

[denkmoon]

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

[generalizations]

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.

[rasz]

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

[generalizations]

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

[themaninthedark]

Really all you need is 32 KB of RAM

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

[throwaway2245]

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.

[jbay808]

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.

[ploxiln]

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

[deathanatos]

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.

[DaiPlusPlus]

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.

[deathanatos]

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.

[hutzlibu]

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

[generalizations]

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

[rini17]

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]