legumeinfo / website-ui-specs

User interface specification of components built for the Jekyll sites.
Apache License 2.0
0 stars 0 forks source link

How do we signal data being loaded? #5

Closed sammyjava closed 10 months ago

sammyjava commented 1 year ago

We need to establish a site-wide standard for signaling that data is being loaded into the page. This applies to page-load data loading (like populating the gene search selectors) as well as search results. No reason to have different behavior, data loading is data loading.

From @alancleary :

I still need clarification on the behavior of the "Loading form data"/"Form data loaded element", i.e. do we want it to be an alert or will just a spinner do. If we go for the alert, do we want it to close automatically? And if so, should that happen immediately after the form data is loaded or should there be a pause so users will see that the load was successful. Currently you can close it using the close "X" button on the right.

So here's a list of options, chime in @alancleary @adf-ncgr @cann0010 @ctcncgr @jd-campbell and myself:

Abstention: Steven

sammyjava commented 1 year ago

I vote for a standard spinner that vanishes after data load. I'll be happy to find a list of spinners from which to choose the official one.

alancleary commented 1 year ago

I think alerts are the way to go because we can add contextual information, such as what type of data is being loaded or what happened if there aren't any results, i.e. no results were found or something went wrong. Since we want this to be consistent it might make sense to use formatted strings for the messages so they can be context specific. For example, `Loading ${dataType}` and `Successfully loaded ${dataType}`.

I like the idea of the alerts automatically closing after a successful load, perhaps after a brief pause to show a success message just so if the user is watching the loading alert doesn't just disappear without any indication of "exit status". This means the success message probably shouldn't contain any new information, like how much data was loaded.

Regarding the spinner, in general I think we should use whatever we can from UIkit for stylistic consistency, so here it would be UIkit's Spinner element which draws the spinner as an SVG that can be scaled to arbitrary size.

Edit: So my vote is "alert (text box with words) that closes after a standard delay after data loaded"

sammyjava commented 1 year ago

Regarding the spinner, in general I think we should use whatever we can from UIkit for stylistic consistency, so here it would be UIkit's Spinner element which draws the spinner as an SVG that can be scaled to arbitrary size.

Thumbs up on that if we choose to use a spinner.

adf-ncgr commented 1 year ago

I'd vote for a spinner while waiting for query response to be returned and an alert if no data is returned (either because a query produces no results or else an error condition). I don't think a successful query response with data needs further commentary.

StevenCannon-USDA commented 1 year ago

I trust you guys. Low-information voter here with respect to "alert options." (Btw, cann0010 has become StevenCannon-USDA, due to changes afoot with USDA GitHub activity.)

sammyjava commented 1 year ago

I'd vote for a spinner while waiting for query response to be returned and an alert if no data is returned (either because a query produces no results or else an error condition). I don't think a successful query response with data needs further commentary.

The no-data-returned is handled by a "0 results found" text box, not a temporary alert. I think that's what you want. So I'll say you vote for the loading spinner while data is being requested. But the no-data-returned response is, I suppose, something we should standardize as well. I don't think that's very controversial.

image

adf-ncgr commented 1 year ago

OK, thanks- any reason not to just use the same text box for error messages?

sammyjava commented 1 year ago

OK, thanks- any reason not to just use the same text box for error messages?

This issue isn't about error messages. :)

alancleary commented 1 year ago

It sounds like we're leaning towards a spinner with no alert when loading data and only showing an alert with a message when no data is loaded. Any opinions on where this spinner should go in the UI, its size, etc? Having it in place of the alert above the element it corresponds to would be easiest to implement. Covering the part of the page where the content will go once it's loaded with a semiopaque color and a spinner in the middle is an approach I've noticed on websites in general.

alancleary commented 1 year ago

OK, I've implemented a loading component that provides a spinner overlay when loading data and shows alerts when no results are loaded. The code is in the loading-element-prototype branch of the web-components repo. Here's a screenshot showing an example of a spinner being overlaid on the gene search form while the data for its selectors is loading. Similarly, a spinner is being overlaid on the search results as if the user had triggered a new search or clicked the next/previous page button.

Screenshot 2023-04-26 at 12-18-05 LIS Web-Components - lis-gene-search-element lis-linkout-element and lis-modal-element

If a spinner's load event fails or no data is loaded, then an alert will be shown, like what the components are already doing, but I've the loading component uses generic messages. Here's an example where the gene search form's data failed to load and no results were found for a search:

Screenshot 2023-04-26 at 12-25-49 LIS Web-Components - lis-gene-search-element lis-linkout-element and lis-modal-element

Let me know what you think.

adf-ncgr commented 1 year ago

works for me, thanks

alancleary commented 1 year ago

Last call for input on the loading component I prototyped. If it's not shot down by tomorrow then it's getting merged.

sammyjava commented 1 year ago

I like it. I like the fade on the previous results while it's pulling new results as well!

alancleary commented 10 months ago

This has been implemented for a while, and a draft spec has finally been added: issue #17. Please continue the conversation there if necessary. Closing