learningequality
User Auth: Fix ambiguous loading states
Observed behavior
@pcenov noted in #10455 that he spotted ambiguity in the loading states in the login screen (note, the first half of the comment is not relevant here, about halfway down the comment is)
As there is no AppBar, our sort of "global" KLinearLoader loading state isn't available. We could use a KCircularLoader, perhaps, to better indicate activity here. Currently, the only thing indicating that something is happening is that the "Submit" button is disabled during the authentication call to the API.
Would appreciate any additional thoughts from @jtamiace / @tomiwaoLE on how to improve this here.
Expected behavior
User should have clear active indicator that something is loading and happening in the background after the user attempts to sign in.
User-facing consequences
Potentially unclear that something is happening after a login attempt.
@jtamiace and I agree that exploring a skeleton loader would be the least obtrusive solution for our current user flow.
We also considered alternative options such as incorporating a version of the KCircularLoader animation in the submit button or displaying an active empty state on the user's home page during or after the authentication call to the API.
@jtamiace is working on screens in this flow that re-incorporate previously designed skeleton loaders to see if it is a workable solution.
We discussed this and decided that a quick fix for this issue can be to use the linear loader as a subtle loading indicator for the sign in page, attached to the top of the sign in container:
For skeleton loaders, they don't necessarily need to be implemented at the same time and maybe more helpful to follow up on in a separate issue, but here is an exploration of how skeleton loaders can be used for landing pages with heavy load times, such as the library page for guests or a home page with many items. More specs here in the Figma, and a gif example of how the skeleton loader can appear
Some questions came up that would be helpful to have an engineer's input:
- Are any of the landing pages known for having long loading times that would benefit from this type of loader? It generally isn't recommended to use them for all pages in an app, but only those that we expect to have long load times to help create a perception of meaningful progress. Pages I can imagine this might apply to are the different variations of the home pages in Learn and the coach dashboard. Although, I guess this would be helpful in any UI with content cards.
- Is there a way to make the number of skeleton loaded items match up with what it’s actually fetching? So that it’s not more or less than what actually is. For example, it would create a slightly jarring experience if the skeleton loader showed a full page of items loading, when there was actually only 1 or 2 items that were going to show up.
@jtamiace and @tomiwaoLE thank you for your work on this
To your question about other places, I think that some places in Device would be good - also this would be a nicer handling of the "loading" state in all of the UserTables (or all of our tables for that matter) because currently we show a short content block w/ a circular loader and then pop a bunch of rows into the table I think it'd look pretty schnazzy.
I have never implemented a Skeleton loader so my main concerns around that are performance related. It's a lot of things to show and animate (assuming they're animated to show something is happening) so I think maybe we'd want to go into that feature with some preceding tests of what the performance would look like in a low-resource context.
In any case, the stop gap measure of putting a KLinearLoader atop the login box sounds great to me.