Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Progress bars still lie

web.eecs.utk.edu

Post reply on HN
Print view View original

191–200 of 232 posts

Re: Progress bars still lie

#191

Post by dec0dedab0de »

Inityx wrote: post #138
news_to_me wrote: post #61

Earlier quoted context omitted.

I think there's two issues here that are often wrapped up together: 1. what is the status of my task, and 2. did the computer get stuck If we could be sure the computer wouldn't get stuck (which is just a bug), then progress bars and spinners would be fine. If the task is as granular as you suggest, progress bars would be a great visual indicator, much better than text. But since computers do get stuck, additional in…

I'm so sick and tired of seeing spinners that keep spinning, even after the process failed; this is an epidemic in web apps, where failures are often a bit too graceful and application state is silently corrupted.

About 15 years ago a coworker had a spinner that was an animated gif, When I see people doing font awesome spinners it reminds me of that gif and I get just as angry.

Re: Progress bars still lie

#192

Post by throwaway2245 »

jbay808 wrote: post #128
generalizations wrote: post #117

Earlier quoted context omitted.

> 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 n…

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.

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.

Re: Progress bars still lie

#193

Post by siraben »

wyattpeak wrote: post #49

You know what I like for progress bars? The mess that is your average build script. Tell me how many tasks there are to complete, how many you've done, and some rough details of what you're doing (e.g. is it a network request). Don't be shy about commentary ("This may take a while", "If this fails multiple times do X"). These generally contain all of the information that the developer has access to, and rarely am I l…

Nix has had a progress indicator for a few years now[0]. It doesn't provide any time estimates but it does show which part of the build it is on (unpack/patch/configure/build/install), how many dependencies it has built or fetched from a binary cache and how many remain. The full build log is accessible with the nix-log command as well, so it's nice from the both a user and dev viewpoint.

For long builds I have stopped watching build logs live altogether and append `; tput bel` to the command to get audible feedback at the end.

For graphical applications, especially on mobile, I wish progress bars got out of the way more. Users ought to be able to continue using an app while a task occurs in a separate thread, and whose progress bar doesn't take up the entire visual field. Many apps, especially on iOS, seem to still be guilty of this.

[0] The creator shows it off here, to applause: https://youtu.be/XVIKScU7Uf4?t=420

Re: Progress bars still lie

#194

Post by chriswarbo »

A humble request: please don't make spinners (GIFs, CSS animations, whatever) visible in the initial response HTML of a page, if they're meant to indicate some sort of AJAX loading. Lots of sites do this, but it's unfortunately too robust. The spinner will appear, and run forever, even if:

- We forgot to embed the JS that does the AJAX loading

- The JS has an error before it even makes a request

- The src URL of a script doesn't exist

- Some cross-domain issue prevents a script loading

- The user agent doesn't support JS

I accept that it can be tricky to remove a spinner correctly in the face of certain error conditions, but it's trivial to avoid showing it until it's meaningful. So please: only insert/reveal spinners programatically, just before the associated request is made.

In fact, this same logic applies to all UI elements that are only meaningful thanks to JS (e.g. buttons that require an event handler, rather than submitting a form); such things should be inserted/revealed programatically using JS, not visible in the initial response HTML, so we don't end up clicking over and over on a button that's useless, etc.

I get that many Web devs these days don't care about progressive enhancement, and like to assume all users have HTML5+CSS+JS+etc. but even that assumption doesn't excuse spinners that lie when a connection fails, or a server is misconfigured, or a third-party moves some assets, etc.

Re: Progress bars still lie

#195

Post by TeMPOraL »

admax88q wrote: post #142
jbay808 wrote: post #128

Earlier quoted context omitted.

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.

Re: Progress bars still lie

#196

Post by TeMPOraL »

karottenreibe wrote: post #164
eru wrote: post #144

Earlier quoted context omitted.

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

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.

Re: Progress bars still lie

#197

Post by cm2187 »

quacked wrote: post #83
paxys wrote: post #74

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 engineer…

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.

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

Re: Progress bars still lie

#198

Post by TeMPOraL »

redler wrote: post #151
hutzlibu wrote: post #122

Earlier quoted context omitted.

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

Re: Progress bars still lie

#199

Post by coldtea »

karottenreibe wrote: post #164
eru wrote: post #144

Earlier quoted context omitted.

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.

Re: Progress bars still lie

#200

Post by TeMPOraL »

news_to_me wrote: post #61
dwohnitmok wrote: post #34

Proposal 1 is the thing I want. Please just list out a total number of steps and log when each of those steps is completed (with a short message describing what the step is so that we don't end up back on square one with fractional progress bars). If possible make the steps granular enough so that a step can be completed in under a second (so this may be hundreds or thousands of steps depending on the task length). I…

I think there's two issues here that are often wrapped up together: 1. what is the status of my task, and 2. did the computer get stuck If we could be sure the computer wouldn't get stuck (which is just a bug), then progress bars and spinners would be fine. If the task is as granular as you suggest, progress bars would be a great visual indicator, much better than text. But since computers do get stuck, additional in…

> But since computers do get stuck, additional indicators should help with that.

They need to be trustworthy. For that, they need to be wired directly into the process doing the work. So no spinner gifs that are animated by the browser/renderer, and can spin forever even if your application dies. It needs to be something where any visual change is directly related to the operations you're monitoring.

That's why a list with textual descriptions of step is a great idea - it's literally too much work to implement it in a way other than the actual completion of a step displaying/ticking off a corresponding label. So seeing that, I'd know the software isn't lying to me.

Post reply on HN