Better loading states

[bedeho]

Context:

There are two distinct loading states being used currently

1. a large text Loading...
2. a large black dialog with an illustration inside of it.
   Neither of these work particularly well, I think we need a consistent way to show this which is better.

scope:

🎨
Update Loading states for Olympia scope in accordance to this design upd

✅

• Better Loading States - Forum #2007
• Loading states: Search and Filters #2008
• Better Loading States - My Accounts #2009
• Better Loading States - Council and Elections #2010
• Better Loading States - Members #2012
• Proposals List

⛔ OOS

• Overview #2013
• Financials #2014
• Bounties

[natiwa]

Hi,

My explorations are below:

Please select from the list (left sidebar) one of the flows. Link to the prototypes

1. Large loading text
   WAS:
   
   New proposition:
   a) skeleton loader example
   b) Subtle loader

2. Dialog with an illustration.
   a. Pending transaction 1
   b. Pending TRnasaction 2

3. Searching for Past proposals

[bedeho]

Feedback

Pending Transactions

Both have the following issues

• Should the user really be able to exit? I am not sure, but I would guess not? please share your thinking if you think it should be the other way around
• The small text is not really going to be readable, nor is it clear what to put there.
• The failure variation of trying to submit a transaction needs to be consistent with the progress indicator.
• I think there needs to be some sort of a transition to success state also.
• The visuals of either were not that appealing, and the fact that the look so distinct from everything else felt like it emphasized just how risky and scary this operation was. Going for something more consistent would help make a risky interaction a bit more pleasant.

Page Loaders

I think the table data loaders was quite promising, lets go with that. Keep in mind that the number of categories 3 and Latest threads 10 is data that returns as the result of very similar asynchronous queries, so they need to have loaders just like everything else. It also needs to be explained what the policy is in terms of when things are displayed: do you wait until the images for all the avatars have been fetched, or do those load by themselves? I think the simplest policy is just to wait until absolutely everything is ready, because as a designer you will not have an easy time knowing what data sources resolve independently and what resolve together.

We also need these loaders for tons of places, such as viewing threads, posts, and virtually every screen in the app. Will you redo this for every screen, or should the developers just figure out how to do this for the other screens?

It is also the case that the loaders need to be triggered not only when loading the page, but also if you are adjusting a possible filtering setting on the page that fires off a new query. This needs to be described in the designs some how.

Searching

I don't think we need a modal like that to block the screen, can't we just go for the same page loading approach as above? Also the consistency is a benefit. I think there may be a need to have some sort of spinner state or something for the search box, to prevent firing off a new search before the last one is done.

[traumschule]

It can be tiring to see loading ... everywhere, sometimes it is better to see cached values first.
Pioneer needs a smart indicator how old displayed values are to know when to reload (for example proposals page: proposal states are usually not updated autoamtically).
Great would be an easy way to reload data relevant for the current view (something intuitive like r as keybindng or a decent refresh button in a corner somewhere. In the future this could be automated with regular QN requests.

[bedeho]

Great would be an easy way to reload data relevant for the current view (something intuitive like r as keybindng or a decent refresh button in a corner somewhere. In the future this could be automated with regular QN requests.

This seems too rough to me. People don't expect webapps, like gmail, Fb, Slack etc., to work like this. It think we just need

• better caching
• better loading states
• lower query latency

because I agree this is a bad experience.

[traumschule]

This seems too rough to me. People don't expect webapps, like gmail, Fb, Slack etc., to work like this.

Agreed. Less user having to fiddle with things is favorable.
Also agree the requirement for having less loading is more caching. I experimented with this on joystreamstats.live a bit and ran into storage limitations (as expected).

With a global 'chain state' skeleton just referencing IDs and some metadata including proposal and thread titles would reduce user waiting time already. With sensible (age) limits to avoid infinite growth over time.

This way some queries (find in title) could become instant and only full-text searches need to hit QN which could also reduce load on our infrastructure.

[dmtrjsg]

@traumschule just a note that this epic is focussed on the Better Loading States, just visual scaffolding .. For the performance and page load optimisations please do feel free to raise separate targeted issues with tech-debt label and they will be triaged in the duly manner. Thank you in advance 🙏