I'm absolutely right

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

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?

Solve the halting problem to show accurate spinners

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.

What’s funny is the jerky animation actually communicates so much more than the smooth animation.

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.

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…

In the context of the web, it is not feasible to make distributed systems 'tick' their progress just to have realistic progress spinners.

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.

That’s exactly what I’m saying is hard to do when progress is being made on multiple threads.