Don't get me started on the progress bar of Apple's Time-machine ...
Progress bars still lie
71–80 of 232 posts
Re: Progress bars still lie
#72I 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…
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.
Re: Progress bars still lie
#73Here's a "watermelon" bar—just need to collect the first tick on each job and then the last recorded tick or tick on complete. Then you can show a nice visualization that shows the current time and distribution of expecting wait times.
https://twitter.com/breckyunits/status/1331381360397672448?s...
And you could break it down recursively by task as well.
Re: Progress bars still lie
#74Progress 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 engineering effort to build a good progress system for a heavy, multi-step background task to show to our users, and the overwhelming feedback was - "it always gets stuck on a certain percent", "it is too slow" and "it is unreliable". After feedback from design we hard-coded it to a steadily increasing bar regardless of actual progress, and the complaints all stopped immediately.
Re: Progress bars still lie
#75When 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 bars that say things like "you have downloaded 47% of file X", because its a statement of fact, not an estimation of future performance.
Re: Progress bars still lie
#76Earlier quoted context omitted.
Can confirm, they work great for users. We had a system where some old things were traditional POST+redirect and the rest was all React with progress bars, disabling buttons when submitting, etc. Users demanded we make everything use progress bars because it's "faster". Our p95 DOM render was 400ms so it wasn't "slow" to begin with. I'm confident it really was the progress bar.
> Our p95 DOM render was 400ms so it wasn't "slow" to begin with. Not sure why exactly you put quotation marks there, but 400ms is incredibly slow, at least relative to human perception and what computers should be able to do. Consider what AAA games can render in 16ms.
Would love to see a web app you've built that does a HTTPS GET round-trip plus browser render in 16ms.
Re: Progress bars still lie
#77Reminds me of a prank I pulled years ago. The company I worked for had some sort of enterprise encryption on the laptop on the hard drives. A friend had some reason to decrypt his to resolve an issue. Progress was very slow on a large progress bar and hard to determine actual progress as the estimated time was over 8 hours so he put a post it to mark the progress and would check intermittently. I spent the day moving the post it and he was convinced it was progressing, pretty sure it never finished. I guess the lesson is maybe progress bars should state a percentage as well.
Re: Progress bars still lie
#78Progress bars are great when they convey meaningful information... sometimes it's nice to know if you have time to grab a coffee, or actually eat lunch. In my experience (when having to supply said bars) is that they serve primarily to tell the hapless user that things are still happening. In other words, the actual number is not important...what is important is real feedback that things are still happening and it's…
> 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.
Re: Progress bars still lie
#79I 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…
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.
Re: Progress bars still lie
#80Earlier quoted context omitted.
This seems a little funny to me, since the purpose of the spinner is so that you know the computer isn't caught in a loop — it's "busy". It's true, though, that the computer could still be stuck even though it updates the spinner. This is a hard problem to solve. Abusing progress bars are not a good response to this, though. I would rather trust progress bars for what they are meant to show rather than as an indicati…
>This seems a little funny to me, since the purpose of the spinner is so that you know the computer isn't caught in a loop — it's "busy". It's true, though, that the computer could still be stuck even though it updates the spinner. This is a hard problem to solve. The problem that people might assume the computer is stuck in a loop or at any rate that the animation is not going to stop is related to spinner animation…
That's because spinners used to show that the main thread was still responsive, but these days are used in different contexts where this isn't really something that it applies to anymore.