4 ms·

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 log

by ygra 6y ago

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.

SulfurHexaFluri 6y ago
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 6y ago
  You are a hero. And to the extent you’re unsung, I will sing your praises.
ASalazarMX 6y ago
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.
GordonS 6y ago
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?
- eyelidlessness 6y ago
  Then the `try { ... } catch { heartbeat() }` pattern will emerge.
  - TeMPOraL 6y ago
    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 6y ago
      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
- gregmac 6y ago
  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 6y ago
> 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.

by ygra 6y ago

SulfurHexaFluri 6y ago

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 6y ago
You are a hero. And to the extent you’re unsung, I will sing your praises.

ASalazarMX 6y ago

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.

GordonS 6y ago

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?

eyelidlessness 6y ago
Then the `try { ... } catch { heartbeat() }` pattern will emerge.
- TeMPOraL 6y ago
  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 6y ago
    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
gregmac 6y ago
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 6y ago

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