[canadian_tired]

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 worth waiting. Or things are b0rked and you should start over. I don't care about a real time or % progress bar...just something that honestly (to OP's point) lets me know that things aren't screwed.

Edit: typos

[Wowfunhappy]

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

[saagarjha]

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.

[jacobwilliamroy]

I recently found out that you can prepend your search with "name:" and windows search will only match against filenames which is the behavior most users expect by default and much faster than whatever nonsense windows explorer search normally does. Example:

    name:search-term

[vulcan01]

Windows Explorer, IIRC (I don't use Windows anymore), searches the content and title of most(?) files.

[TeMPOraL]

It's not just search when the progress bar appears, though. Also when trying to enumerate contents of a folder - e.g. when you're accessing a networked resource, or one that may not be viewable with your privileges. You then get this bullshit progress bar that speeds through the first 3/4, and asymptotically approaches 100%.

[eyelidlessness]

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!

[ASalazarMX]

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

[ygra]

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.

[GordonS]

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?

[gregmac]

Many APIs don't have that - for example with most IO operations you get a return value when complete or an exception on failure, and that's it.

Getting something like a callback for progress would require modifications all the way down the stack, akin to what's needed for fully async code.

[eyelidlessness]

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

[TeMPOraL]

Which is a sane pattern if a language has proper destructors (a seemingly non-existent thing in GC-enabled languages, unfortunately).

In C++, you'd stack-allocate an object representing a spinner, that spawns said spinner in its constructor, and deletes it in its destructor. Then the spinner doesn't outlive the processing code, no matter what path execution took to end the processing.

There are similar patterns in GC-enabled languages ("with" idiom). Async does throw a wrench into this a bit, though.

[eyelidlessness]

That’s a different pattern than I was trying to illustrate. I was demonstrating unsafely catching/ignoring/hiding errors and asserting health when it’s demonstrably not true

[SulfurHexaFluri]

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.

[eyelidlessness]

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

[ASalazarMX]

My ideal spinner would be a decreasing arch, telling the user how much time remains until their request timeouts and fails. Uses the same space as a spinner, but conveys more information.

[eyelidlessness]

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

[dkersten]

> the actual number is not important...what is important is real feedback that things are still happening

Absolutely agree, but then, don't make it a percentage progress bar. Make it one of those "amount unknown" bars, or better yet, a spinner or game-like loading screen. Something with movement that tells me things are happening. Don't pretend to know "how done" it is if you don't know.

[laumars]

The web has ruined those feedback widgets for me. Now every time I see one of those spinners I think “oh look, a gif that will keep spinning even if the process I’m waiting on has failed”.

[dkersten]

That is a good point and rather unfortunate...