Skip to content
This repository has been archived by the owner on Mar 5, 2018. It is now read-only.

Busy indicator #410

Open
jonathanconway opened this issue Oct 10, 2016 · 2 comments
Open

Busy indicator #410

jonathanconway opened this issue Oct 10, 2016 · 2 comments

Comments

@jonathanconway
Copy link
Contributor

In case processing a user's request takes a long time (due to factors within or outside our control), we should visually indicate that processing is underway.

Since it's difficult to predict how long web requests will take to be serviced, we can start using an indeterminate progress indicator, such as a progress ring.

image

We could also show a CSS wait cursor, which was intended for this purpose.

The above could be applied to any element using a simple class, e.g. .busy.


Note: Research has shown that determinate progress indicators give a better user experience. However, this could be tricky given the asynchronous nature of the web. Perhaps we can gradually iterate and improve how we do this so that, in cases where we can roughly predict how long something will take, we show a determinate indicator, and in other times, we give the user a broad estimate and redirect them to help if the process ends up taking way too long, e.g. more than 1 minute to complete, rather than just leaving them hanging.

@elisechant
Copy link

I don't mind the idea of progress indicators inside buttons but page level progress indicators are a big no no in the current climate with a bunch of appropriate alternatives https://uxplanet.org/progress-indicators-in-mobile-ux-design-a141e22f3ea0 cc @gazhands

@jonathanconway
Copy link
Contributor Author

jonathanconway commented Oct 19, 2016

@elisechant, perhaps like this...?

image

Agree about no page-level indicators.

I can imagine maybe wanting to block off one portion of the page, such as the "new comment box" when you post a comment to GitHub.

image

But maybe prefer keeping it to a button unless there's a specific reason to block off a portion.


It would super-nice if we allowed cancel/retry, though that might be a bit beyond the scope of this issue. (Tidwell, "Designing Interfaces", 2010, pp. 269)

At the very least, I think we should cancel the busy indicator if the system crashes, e.g. the Ajax request returns a non-OK response. (Myers, B., 1985, "CHI '85 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems", pp. 12)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants