Progress bars still lie • Hacker News Board

Re: Progress bars still lie

#151

Post by redler » Wed, Nov 25, 2020, 4:21 AM UTC

hutzlibu wrote: post #122

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…

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

Re: Progress bars still lie

#152

Post by liminalsunset » Wed, Nov 25, 2020, 4:22 AM UTC

When it comes to progress bars that lie, I think of two major examples:

1) Apple software updates or OS installs usually never have the bar progress past 30% or so. I don't think they lie, so much as 100% is actually at 40%.

2) Windows installation. Copying Windows files jumps straight to 100%, Expanding Windows files is the only one that provides meaningful indication, installing features and installing updates happen instantly.

Then, it goes into a period of indeterminate loading spinner after a reboot.

These days, where possible (i.e. on VM, or if I'm in the OS already) I just use iStat menus or other monitoring software to check if things are using the processor by checking the CPU usage, CPU power consumption, disk read/write, and network activity. If something's happening, I let it sit. If not, the process needs to be restarted.

Re: Progress bars still lie

#153

Post by [deleted] » Wed, Nov 25, 2020, 4:33 AM UTC

quelsolaar wrote: post #75

fgdelcueto wrote: post #13

When progress bars are not useful it is because the underlying problem is hard to extrapolate faithfully. If you are doing just a few tasks where each one takes a significant different time to execute, it will be hard to estimate. More often than not, they work fine, IMO. When they don't, it is because for that particular problem it is genuinely hard to do. It isn't programmer's laziness, I think, in most cases.

Most users don't understand that making an accurate progress bar is incredibly hard, for most tasks. Is not very intuitive, but once you start looking in to it you realize that almost nothing in a computer is deterministic. Task switching, cashes, file system buffers, disk fragmentation, variable clock frequencies, and loads of other factors, make the speed of a computer very hard to estimate. I do favor progress bar…

[deleted]

Re: Progress bars still lie

#154

Post by netcoyote » Wed, Nov 25, 2020, 4:49 AM UTC

Frost1x wrote: post #30

fgdelcueto wrote: post #13

When progress bars are not useful it is because the underlying problem is hard to extrapolate faithfully. If you are doing just a few tasks where each one takes a significant different time to execute, it will be hard to estimate. More often than not, they work fine, IMO. When they don't, it is because for that particular problem it is genuinely hard to do. It isn't programmer's laziness, I think, in most cases.

I often see the suggestion to display spin animations instead since estimation is often incredibly difficult if not impossible. I prefer progress bars because even if they aren't accurate, the relative directional growth shows me that something is actually executing. With a spin animation, for all I know, somethings caught in a loop.

In the old days of 68K Mac, it could be even worse. The spinning hourglass was often animated during a timer interrupt, while the main application might have died altogether.

Re: Progress bars still lie

#155

Post by smichel17 » Wed, Nov 25, 2020, 5:09 AM UTC

srgpqt wrote: post #137

xwdv wrote: post #123

Earlier quoted context omitted.

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.

Reticulating Splines

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

Re: Progress bars still lie

#156

Post by cridenour » Wed, Nov 25, 2020, 5:13 AM UTC

allenu wrote: post #69

I actually don't mind the occasional lying progress bar. I think TurboTax is famous for this, where they just toss in fake progress bars to indicate that they are crunching some numbers, which really just take milliseconds, if that. The goal is just to convey that "heavy work is happening". I ended up using this strategy recently because I wanted to convey that my app was "doing work on your behalf", so I tossed in a…

When we built a real estate search site that worked on a more "lifestyle search" we had to do something similar. We could return results in about 250ms, but a large portion of beta testers gave feedback that it felt "shallow". Added a 4-5 second animation and loading bar, and people gave better feedback on the actual results, etc. Small sample bias? Maybe. But no one ever complained about the speed in the two years we ran it.

Re: Progress bars still lie

#157

Post by quickthrower2 » Wed, Nov 25, 2020, 5:17 AM UTC

Here is a universal progress bar in pure CSS (no need for any annoying JS code that needs to know what is actually going on), similar to the old lying IE bar:

    .progress {
      height: 100px;
      background-color: red;
      animation-name: example;
      animation-duration: 10000s;
    }

    @keyframes example {
      0% {width: 0%;}
      0.1% {width: 50%;}
      2% {width: 90%;}
      100% {width: 99%;}
    }

Re: Progress bars still lie

#158

Post by wruza » Wed, Nov 25, 2020, 5:26 AM UTC

The problem with progress bars is us. We expect different behavior and the most population has wrong idea about how systems work. While an average Joe likes pulsing bars that advance regardless, other people hate it, because with time (years of experience) it obviously feels bogus.

Best (honest) progress bars are still those of software package managers, because they simply update on a percentage, have no step/idle animations and always show where you are exactly.

Surprisingly, MS has recently done a great job with explorer's copy progress by showing a graph. Filesystems and disks have nonlinear performance and rather than trying to extrapolate, they allow you to see when caches exhaust and the speed falls to its final value. When it stops or starts to degrade, you see that too and may try to pause a competing/interfering process.

Re: Progress bars still lie

#159

Post by jancsika » Wed, Nov 25, 2020, 5:29 AM UTC

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.

Hell, the standard everybody seems to have converged upon is a mendacious progress bar where the user is not told what the percentage refers to (e.g., total install time? Number of files processed? Data left to be copied?). The frontend developer could show changing Matrix glyphs instead and the widget would be functionally equivalent but without giving the user false impressions.[1]

Given that as a standard, it's difficult for me to find more outrage for Turbotax misusing this already mendacious widget.

1: Some smarty pants is going to say that at least the percentage is directional and shifting Matrix glyphs are not. Unfortunately, even that isn't true-- UIs have a long history of multiple sequential progress bars with no indication how many there are in total-- see Office Space. So progress widgets have burned through user trust long ago-- even if I've experienced Windows 10 having a single percentage counter that persists across restarts, perhaps the next update will be the time they break that pattern.

Re: Progress bars still lie

#160

Post by jancsika » Wed, Nov 25, 2020, 5:36 AM UTC

This is the one place where dark patterns would come in handy.

During the task, hook me up in another thread with a ML chat buddy that baits me with political statements chosen to maximize my outrage. Since my attention has been fully captured for the duration-- regardless of the length-- the programmer doesn't have to waste any time trying to measure how long the task takes to complete.