21–30 of 232 posts
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.
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.
Basically: tell me how long it took other people.
Lying progress bars are one of those ubiquitous anti-features which make me suspect the people who write the apps that have it or who decide what features they are to have never actually use their own software, or they'd realize in a heartbeat how incredibly annoying and frustrating lying progress bars are. I'd love to hear an HN reader who is brave enough to own up to implementing one of these explain the rationale…
Made one for an internal feature using an overly simple algorithm (% of tasks completed). I was the only one using the tool so I understood the tradeoffs of the progress bar. After a while this tool made it into wider use, but the progress bar remained.
Progress bars work worst when they are combining extremely disparate steps. You might need to run 10 functions, but if one takes 0.1 seconds and one takes 45 seconds, it makes little sense for each step to be counted the same atomically or to present each as 10% of a progress bar.
The absolute worst case scenario is when you depend on an external resource about which availability is unknown but highly variable.
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.
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.
I think I'd rather just have predetermined steps/milestones. Think about it...what does 71 percent really mean? Would you get excited when it goes it 72? It's just an opaque, useless metric. If instead I can see something like...step 1/5, downloading package... that's far more meaningful, at least to me.
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.
Progress 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…
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 becomes increasingly slow as it nears the end. I suspect the bar is programmed to never increase by more than half the remaining distance, or something like that.
After half an hour, I finally realized something had to be wrong, and I tried whitelisting figma.com in my proxy. The document loaded immediately.
If Figma hadn't lied to me with a fake progress bar, it would have saved so much time...
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.