4 ms·

…although in many cases you kind of don’t have a choice here, right? If you’re waiting for some API to return data, there’s basically no way to know whether it

…although in many cases you kind of don’t have a choice here, right? If you’re waiting for some API to return data, there’s basically no way to know whether it has stalled. Presumably there will be a timeout, but if the timeout is broken for some reason, the spinner will just spin.

pessimizer 1y ago
You can't figure out how to fix that? Does that problem seem impossible to you? Maybe don't start an animation, and instead advance a spinner when a thing happens, and when an API doesn't come back, the thing doesn't get advanced?
- frotaur 1y ago
  Solve the halting problem to show accurate spinners
- wrs 1y ago
  Long ago (I first remember doing it in about 1985 with the original Mac watch cursor) this was the standard way to do spinners: somewhere in your processing you incremented the spinner. It was hard to put the increments in the right places to keep the spinner going even when progress was happening, and nearly impossible to make it animate smoothly. This technique is even harder to get right when the processing in question is multithreaded, or if the spinner is part of the UI (as opposed to a cursor) so it has to trigger a redisplay to show up. So programmers didn’t like it because it was complex, and designers didn’t like it because the animation was jerky. As a result, the standard way now is to have an independent animation that you just turn on and off, which means you can’t tell if there’s actually any progress being made. Indeed, in modern MacOS, the wait cursor, aka beach ball, comes up if the program stops telling the system not to show it (that is, if it takes too long to process incoming system events). This is nice because it’s completely automatic, but as a result there’s no difference between showing that the program is busy doing something and that the program is permanently frozen.
  - zestyping 1y ago
    You have a strange idea of what "right" means. Showing a true reflection of the actual, irregular, progress is getting it right. It's honest and informative.
    - wrs 1y ago
      That’s exactly what I’m saying is hard to do when progress is being made on multiple threads.
  - kevinventullo 1y ago
    What’s funny is the jerky animation actually communicates so much more than the smooth animation.
    - wrs 1y ago
      Yeah, same with progress bars — especially the Windows Installer progress bar that goes backwards when it’s backing out after a failure! Of course, progress bars based on increments have a whole other failure mode, the eternally 99% progress bar…
  - sthatipamala 1y ago
    In the context of the web, it is not feasible to make distributed systems 'tick' their progress just to have realistic progress spinners.
- Wowfunhappy 1y ago
  But if you expect the request to take some amount of time, how do you communicate that to the user? Even if you don’t know the actual progress, the spinning cursor still provides useful information, namely “this is normal”. Edit: Fwiw, I would agree with you if we were discussing progress bars as opposed to spinners. Fake progress bars suck.

pessimizer 1y ago

You can't figure out how to fix that? Does that problem seem impossible to you? Maybe don't start an animation, and instead advance a spinner when a thing happens, and when an API doesn't come back, the thing doesn't get advanced?

frotaur 1y ago
Solve the halting problem to show accurate spinners
wrs 1y ago
Long ago (I first remember doing it in about 1985 with the original Mac watch cursor) this was the standard way to do spinners: somewhere in your processing you incremented the spinner. It was hard to put the increments in the right places to keep the spinner going even when progress was happening, and nearly impossible to make it animate smoothly. This technique is even harder to get right when the processing in question is multithreaded, or if the spinner is part of the UI (as opposed to a cursor) so it has to trigger a redisplay to show up. So programmers didn’t like it because it was complex, and designers didn’t like it because the animation was jerky. As a result, the standard way now is to have an independent animation that you just turn on and off, which means you can’t tell if there’s actually any progress being made. Indeed, in modern MacOS, the wait cursor, aka beach ball, comes up if the program stops telling the system not to show it (that is, if it takes too long to process incoming system events). This is nice because it’s completely automatic, but as a result there’s no difference between showing that the program is busy doing something and that the program is permanently frozen.
- zestyping 1y ago
  You have a strange idea of what "right" means. Showing a true reflection of the actual, irregular, progress is getting it right. It's honest and informative.
  - wrs 1y ago
    That’s exactly what I’m saying is hard to do when progress is being made on multiple threads.
- kevinventullo 1y ago
  What’s funny is the jerky animation actually communicates so much more than the smooth animation.
  - wrs 1y ago
    Yeah, same with progress bars — especially the Windows Installer progress bar that goes backwards when it’s backing out after a failure! Of course, progress bars based on increments have a whole other failure mode, the eternally 99% progress bar…
- sthatipamala 1y ago
  In the context of the web, it is not feasible to make distributed systems 'tick' their progress just to have realistic progress spinners.
Wowfunhappy 1y ago
But if you expect the request to take some amount of time, how do you communicate that to the user? Even if you don’t know the actual progress, the spinning cursor still provides useful information, namely “this is normal”. Edit: Fwiw, I would agree with you if we were discussing progress bars as opposed to spinners. Fake progress bars suck.