4 ms·

I thought this was going to be a site about how to get rid of spinners. Our goal should be to get people to their content quicker, not satiate them with a perf

I thought this was going to be a site about how to get rid of spinners. Our goal should be to get people to their content quicker, not satiate them with a perfect spinner, right?

duxup 4y ago
I find if I don’t give a bit of a loading indicator that users get suspicious if the action worked or not. A loading indicator does a nice job of indicating work being done.
drewcoo 4y ago
> Our goal should be to get people to their content quicker, not satiate them with a perfect spinner, right? Yes, this. Every spinner is a band-aid over a bug. I've dealt with C-suite (typically not engineering!) in tiny startups who were very interested in every detail of their spinners . . . but unwilling to consider the very fact that they needed a spinner to be a problem.
- wizofaus 4y ago
  A bug? The reality is there are plenty of times it's simply not feasible to complete a user request instantly (particularly if you're depending on 3rd party services), but it's not likely to take so long you need to redesign the UX to make it clear a background task has been started that will finish later on (in fact some users have real difficulty with such interfaces anyway). Whereas you can always respond to a user action with some instant feedback that indicates work is in progress, and ideally give the user some indication of how long they might have to wait and that the request is still being worked on. I say this having recently developed such a feature - in fact the customer was fine that the requested action might take up to 10 minutes to complete, but their preference was that a modal dialog showing the progress of said task with an explicit warning not to close it should be shown, despite the fact we'd implemented it to allow the dialog to be closed and the app to be fully functional while the task ran. And yes, every effort was made to reduce the time needed to complete the request but ultimately we were constrained by 3rd party libraries, the large amount of processing needed (image processing on very large documents, well over 1gb) and the fact the customer was unwilling to pay for more compute resources.

I thought this was going to be a site about how to get rid of spinners. Our goal should be to get people to their content quicker, not satiate them with a perfect spinner, right?

duxup 4y ago

I find if I don’t give a bit of a loading indicator that users get suspicious if the action worked or not. A loading indicator does a nice job of indicating work being done.

drewcoo 4y ago

> Our goal should be to get people to their content quicker, not satiate them with a perfect spinner, right? Yes, this. Every spinner is a band-aid over a bug. I've dealt with C-suite (typically not engineering!) in tiny startups who were very interested in every detail of their spinners . . . but unwilling to consider the very fact that they needed a spinner to be a problem.

wizofaus 4y ago
A bug? The reality is there are plenty of times it's simply not feasible to complete a user request instantly (particularly if you're depending on 3rd party services), but it's not likely to take so long you need to redesign the UX to make it clear a background task has been started that will finish later on (in fact some users have real difficulty with such interfaces anyway). Whereas you can always respond to a user action with some instant feedback that indicates work is in progress, and ideally give the user some indication of how long they might have to wait and that the request is still being worked on. I say this having recently developed such a feature - in fact the customer was fine that the requested action might take up to 10 minutes to complete, but their preference was that a modal dialog showing the progress of said task with an explicit warning not to close it should be shown, despite the fact we'd implemented it to allow the dialog to be closed and the app to be fully functional while the task ran. And yes, every effort was made to reduce the time needed to complete the request but ultimately we were constrained by 3rd party libraries, the large amount of processing needed (image processing on very large documents, well over 1gb) and the fact the customer was unwilling to pay for more compute resources.