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

91–100 of 232 posts

Re: Progress bars still lie

#91

Post by eyelidlessness »

saagarjha wrote: post #78
Wowfunhappy wrote: post #29

Earlier quoted context omitted.

> In other words, the actual number is not important...what is important is real feedback that things are still happening and it's worth waiting. And the inverse is that when progress bars are fake , they tell the user that everything is working even when it's not! I MitM my SSL traffic. This causes Figma to fail to load documents in the most annoying way possible —it shows a progress bar that never stops moving, but…

I've gotten real good at recognizing those kinds of progress bars; I think Window Explorer's search had one and it trained me to never trust them.

VSCode has a progress bar (well a throbber) that shows up when the language server has waited long enough that the UI should show some activity. But for my workflows it only shows up when something has gone wrong. So when I see it, it’s a good indicator to either restart TS server or reload the whole window. Not a great experience or solution!

Re: Progress bars still lie

#92

Post by eyelidlessness »

ygra wrote: post #8
ASalazarMX wrote: post #4

Earlier quoted context omitted.

> I don't care about a real time or % progress bar...just something that honestly (to OP's point) let's me know that things aren't screwed. That's where "marquee" progress bars fit in. Those poor abominations that, like Sisyphus, progress without advancing, because a simple activity indicator wasn't user-friendly enough.

Especially fun in Web UIs where the callback that would remove the spinner will never be called because some error occurred somewhere in between and is only logged in the console where no normal user will ever see it ... Personally I feel that to be very much a subversion of the »things are still moving, so stuff is still happening« assumption that has been common in normal desktop applications.

> Especially fun in Web UIs where the callback that would remove the spinner will never be called because some error occurred somewhere in between and is only logged in the console where no normal user will ever see it ...

I know it’s unpopular in these parts but checked exceptions would make this impossible.

Re: Progress bars still lie

#93

Post by dkersten »

fairity wrote: post #62
dkersten wrote: post #58

Earlier quoted context omitted.

What's wrong with using something like a spinner in that case though? The big issue with a lying progress bar is that it not only lies when things are happening, it also lies when things are broken, possibly wasting a lot of your users' time.

The goal isn't to save the user time. It's to maximize user conversion rate.

You mean abandonment? Most progress bars are shown when I'm already using your application.

Re: Progress bars still lie

#94

Post by eyelidlessness »

GordonS wrote: post #42
ygra wrote: post #8

Earlier quoted context omitted.

Especially fun in Web UIs where the callback that would remove the spinner will never be called because some error occurred somewhere in between and is only logged in the console where no normal user will ever see it ... Personally I feel that to be very much a subversion of the »things are still moving, so stuff is still happening« assumption that has been common in normal desktop applications.

Maybe spinners like these need a kind of "dead man's switch", where something needs to keep telling them "yep, still working" every so often, otherwise an error is shown?

Then the `try { ... } catch { heartbeat() }` pattern will emerge.

Re: Progress bars still lie

#95

Post by dkersten »

news_to_me wrote: post #60
dkersten wrote: post #56

Earlier quoted context omitted.

It reminds me of the old (maybe it still does it, I dunno) windows install progress bars vs ones where multiple things are wrapped into one. With multiple things wrapped into one, you often end up in situations where 0-99% (or whatever) might happen super fast but that last 1% takes ages, making the progress bar useless as a "something's happening" indicator. Those old windows installers used two bars: the top one wa…

Yeah, I think I remember those! If it were me, I would turn the segmented bar into a checklist, since you can add a description and I think it looks nicer. But the approach was a good one imo.

Sure, that top bar is a "steps completed" bar, so something other than a normal progress bar may be better. A checklist would work, unless space confined. Depends on the number of items. Maybe a segmented bar where it fills one segment for each item. If there are a lot of items, though, just an "X/Y steps completed" may work best: its simple and easy to understand.

Re: Progress bars still lie

#96

Post by eyelidlessness »

SulfurHexaFluri wrote: post #26
ygra wrote: post #8

Earlier quoted context omitted.

Especially fun in Web UIs where the callback that would remove the spinner will never be called because some error occurred somewhere in between and is only logged in the console where no normal user will ever see it ... Personally I feel that to be very much a subversion of the »things are still moving, so stuff is still happening« assumption that has been common in normal desktop applications.

The app I work on is plagued with this issue. I just wish I was given the time to go around and fix it everywhere. As with so many of the issues in web apps, its not even complex or hard to fix these issues. Its just no one cares enough to schedule time for it.

You are a hero. And to the extent you’re unsung, I will sing your praises.

Re: Progress bars still lie

#98

Post by WorldMaker »

dkersten wrote: post #56
news_to_me wrote: post #41

Earlier quoted context omitted.

A progress bar should not indicate progress over multiple tasks — a segmented progress bar is better, or a series of spinners, or just a single spinner for the whole set. A progress bar should measure exactly one metric, where the total is known.

It reminds me of the old (maybe it still does it, I dunno) windows install progress bars vs ones where multiple things are wrapped into one. With multiple things wrapped into one, you often end up in situations where 0-99% (or whatever) might happen super fast but that last 1% takes ages, making the progress bar useless as a "something's happening" indicator. Those old windows installers used two bars: the top one wa…

I played with the idea of using a singular circular progress bar for composite progress notification. The basic idea was that if you keep the tail chasing the head, and the head always moving clockwise, the progress bar never gives the impression that it "shrinks backwards", it is always forward motion, but in the worst case when the tail catches up with the head (you discover more sub-tasks) it basically becomes a spinner until the tail starts to lag the head again. Tuning the animation parameters for that provided a lot of options to get a good feeling progress bar that reported a heterogeneous source of various tasks, some of which discovered/added while in progress of the overall whole.

My demo has unfortunately fallen to web bit rot and needs to be updated, but the code is here to explore: https://github.com/worldmaker/compradprog

Re: Progress bars still lie

#99

Post by yeetman21 »

jrochkind1 wrote: post #79
wtallis wrote: post #72

Earlier quoted context omitted.

Having some kind of transition to visually indicate a change of state is fine. But that's not what TurboTax does; they have a progress bar that is insultingly superfluous, because there's already a "next" button.

It's worse. They seem to be intentionally slowing things down to make it look like the software is somehow "working harder" because to some people it justifies the high price. A progress bar that takes 5s or more to complete for an operation that actually takes under a second.

People are willing to pay more for meals eaten with heavier silverware

Re: Progress bars still lie

#100

Post by allenu »

gtsop wrote: post #53

I have only implemented progressbars on the web. After various progressbars on different projects my approach is this: - Have an array of tasks - Have a % progressbar - Each task adds (100/total_tasks)% once completed regardless of how fast it is Now comes the fun part. There is this single task that takes up the majority of the time amd your progressbar is stuck at 56% percent for too much time compared to the other…

Good on you. Most progress bars are about user experience and not so much about accuracy. People just want to know that there's a long sequence of work and that progress is being made.

It's often an illusion and showing too much how the sausage is made makes the user start asking questions about what's happening behind the scenes.

That said, a long task that is prone to failure due to external factors should definitely be conveyed in the progress bar. If a bad network connection is affecting a process from finishing, you obviously want the user to know that so they don't blame the software for being slow. :)

Post reply on HN