Arvados

Here's a sample guideline for loading indicators, mostly codifies what we already have but the important things are the recent decision to not use the page spinner for background / partial page updates and a reminder not to use toasts to notify when an action is starting:

Loading indicator use-case guidelines¶

Page Navigation¶

• Navigation between pages should be indicated using progressIndicatorActions.START_WORKING and progressIndicatorActions.STOP_WORKING to show the global top-of-page pulser
• Only the initial load or refresh of the full page (eg. triggered by the upper right refresh button) should use this indicator. Partial refreshes should use a more local indicator.
  • Refreshes of only one section of a page should only show its own loading indicator in that section
• Full page refreshes where the location is unchanged should avoid using the initial full-page spinner in favor of the top-of-page spinner, with updated values substituting in the UI when loaded

User Actions¶

• Form submissions or user actions should be indicated by both the progressIndicatorActions.START_WORKING and by enabling the spinner on the submit button of the form (if the action takes place through a form AND if the form stays open for the duration of the action in order to show errors). If the form closes immediately then the page spinner is the only indicator.
• Toasts should not be used to notify the user of an in-progress action but only completion / error

Lazy-loaded fields¶

• Fields that load after the main view should use a spinner/pulser icon while loading - if the request for extra data fails, a placeholder icon should show with a hint (text or tooltip) indicating that the data failed to load.
• Open question: Should fields that show one value but update with more info (eg uuid that gets updated with a name) show a loading indicator? Or only fields that would be empty otherwise?
• (Suggested loading indicator for inline fields: https://mhnpd.github.io/react-loader-spinner/docs/components/three-dots)

And here are a few places where I found toasts being used to indicate an in progress action:

• Add/remove favorites
• Add/remove public favorites
• Remove process

We haven't implemented this anywhere, but when a navigation action happens, I would like to experiment with putting a semi-opaque overlay that blocks clicks (but possibly allows scrolling?) over the main panel to indicate the previous contents are not available while the new contents are being loaded. This would prevent confusion (especially when navigating between projects) about what is the correct contents in situations where the old content remains visible while the new content is loaded -- while avoiding the flicker that would happen with clearing the data table contents while loading.

On the other hand, when the URL bar doesn't change, the old content should remain visible while the new content is loading (keeping current behavior).

Open question: Should fields that show one value but update with more info (eg uuid that gets updated with a name) show a loading indicator? Or only fields that would be empty otherwise?

What about a delayed loading indicator? A field that is pending update would show the existing value (or stay blank) for the first 3-5 seconds, but if the value still isn't ready after 3-5 seconds, the loading indicator shows up. This would reduce flicker in the case where the load quickly, while still signaling to the user that something is happening in situations where it's being slow.

This could be used for navigation as well -- delay applying an opaque layer for 3-5 seconds for situations where navigation is quick, to minimize flicker.

Let me know what you think of these ideas. Otherwise, go ahead and add the guidelines to the WB2 user interface guidelines and resolve the ticket.

I added a follow-up story to go through and make loading indicators behave consistently: #21634