3 ms·

I absolutely HATE the loading spinner. Even if a dev has no idea how long something is going to take, at least attach a number that increments in response to a

I absolutely HATE the loading spinner. Even if a dev has no idea how long something is going to take, at least attach a number that increments in response to a listener event indicating some additional "tick" of work was done - otherwise there is zero visual difference between a process that is hung and one that is simply slow. It boggles my mind how many UI/UX people don't understand this.

willsmith72 3y ago
Is it so trivial to know if "some additional tick of work was done" without knowing how long something is going to take?
- orhmeh09 3y ago
  you are right -- it is not trivial, and heavily dependent on your use case. on my own scripts that run some kind of process on a CSV or Parquet file of a great deal of rows -- whose length I know, or can guess approximately based on file size and row width -- I passed a number and a function argument that would trigger after every so many rows. by default it would just print i/N every sqrt(N) times. this was ideal for my use case to keep an eye on it running in a tmux session.
klysm 3y ago
Adding more complex loading states than spinners takes work and it’s not free.
deleted 3y ago
[deleted]
GuB-42 3y ago
It is one of the hardest things to get right in programming. and sometimes, like when you are waiting on a network and your connection is unreliable, just impossible. It is hard because the blocking operation may be very deep in the call stack, and each element must collaborate. Not all APIs support asynchronous progress events. Proper progress bars are abstraction breakers. For example, your API may abstract away the fact you are on a network or doing things locally, except that if you want progress, these are very different cases, so you want to know the underlying situation. Ideally you should also know how good your connection is: an overcrowded airport Wi-Fi doesn't act the same as wired LAN. UI/UX people can only do with what their back-end provides. The back-end can only do with what the APIs they use provide. The APIs can only do with what the system provides. So sometimes, a spinner is the only thing that can be done within a reasonable budget.

willsmith72 3y ago

Is it so trivial to know if "some additional tick of work was done" without knowing how long something is going to take?

orhmeh09 3y ago
you are right -- it is not trivial, and heavily dependent on your use case. on my own scripts that run some kind of process on a CSV or Parquet file of a great deal of rows -- whose length I know, or can guess approximately based on file size and row width -- I passed a number and a function argument that would trigger after every so many rows. by default it would just print i/N every sqrt(N) times. this was ideal for my use case to keep an eye on it running in a tmux session.

klysm 3y ago

Adding more complex loading states than spinners takes work and it’s not free.

deleted 3y ago

[deleted]

GuB-42 3y ago

It is one of the hardest things to get right in programming. and sometimes, like when you are waiting on a network and your connection is unreliable, just impossible. It is hard because the blocking operation may be very deep in the call stack, and each element must collaborate. Not all APIs support asynchronous progress events. Proper progress bars are abstraction breakers. For example, your API may abstract away the fact you are on a network or doing things locally, except that if you want progress, these are very different cases, so you want to know the underlying situation. Ideally you should also know how good your connection is: an overcrowded airport Wi-Fi doesn't act the same as wired LAN. UI/UX people can only do with what their back-end provides. The back-end can only do with what the APIs they use provide. The APIs can only do with what the system provides. So sometimes, a spinner is the only thing that can be done within a reasonable budget.