Client: App loading: replace the loading bar by a full screen loader

[bpierre]

A thin loading bar at the top works well when a user is moving from a screen to another one that need to be loaded. It allows the user to keep seeing and using the current screen while the next one is loaded, and also having a chance to cancel it. That’s what YouTube and GitHub are doing with their links, or Safari with its navigation (outside the viewport, in the address bar).

In our case, we replace entirely the screen when another app is being selected, leaving an empty screen without providing information about what is happening.

A solution to improve this could be to keep displaying the previous app screen, until the next one is loaded. It would require managing two AppIFrame instances when switching from an external app to another one.

But before we do that, I think we could use the Ethereum loading animation we already use for loading apps metadata, only replacing the text by “Loading [name of app]…” https://github.com/aragon/aragon/pull/354

@luisivan @sohkai @jounih thoughts?

[sohkai]

A solution to improve this could be to keep displaying the previous app screen, until the next one is loaded. It would require managing two AppIFrame instances when switching from an external app to another one.

I'd find this odd, as the sidebar will have already switched but the app would still be the last app for a few seconds. I think users would find this really confusing and wonder if they had selected the right app.

But before we do that, I think we could use the Ethereum loading animation we already use for loading apps metadata, only replacing the text by “Loading [name of app]…”

Do you think having both the progress bar and the animation would make this loader too noisy? I like how the progress bar signifies progress, even if it's kind of fake, although we could try transitioning the Ethereum logo based on the loading progress...

[bpierre]

I'd find this odd, as the sidebar will have already switched but the app would still be the last app for a few seconds. I think users would find this really confusing and wonder if they had selected the right app.

That’s a very good point. I have one app in mind (App Store on macOS) that is doing that (no bar but the loading screen is selected in the menu while the previous screen is displayed), and I personally find it to fail at creating a responsive feel.

Do you think having both the progress bar and the animation would make this loader too noisy? I like how the progress bar signifies progress, even if it's kind of fake, although we could try transitioning the Ethereum logo based on the loading progress...

Maybe we could have a progress bar integrated into the loader (e.g. a small bar below, like when macOS is booting)? Talking about this, I am still not convinced it’s a good idea to give a fake feedback about the loading time if we don’t know: as a user, I want to know when a loading time is indeterminate. If we keep the a progress bar, one thing we could do would be to always measure the time it takes to load an app, and use this time as a base for the loading progress of the next app.

[luisivan]

That may be too complex -- we shouldn't focus on creating a very advanced progress bar, since we could instead focus on caching and service workers so there's no load time.

[jounih]

I think the pattern a lot of people are using for this is Skeleton screens. It feels more responsive than a progress bar (which we don't know the duration of) or a loading animation (which doesn't give any idea of the page contents).

Caching is a good option for many cases but can sometimes be weird if the data changes suddenly after loading, and doesn't work for first use

They all work to some degree though so maybe we can keep this on the back burner :)

[luisivan]

True, we could put skeleton screens as a should-do for developers creating their apps. Otherwise, we could create a very basic skeleton ourselves, just with the appbar on the top

[bpierre]

Skeleton screens wouldn’t be possible here, this loading time is happening when we get the app itself (we don’t have any information about the app frontend at this point).

But it’s something that apps could use if they need to fetch some data after their initial rendering, if the data is usually loading fast enough. Skeletons are really good at “almost instant” loadings, but can feel quite bad if it takes more than a few seconds, since they don’t give any indication about the status of the app: is it loading something, or is it stuck?

[bpierre]

Otherwise, we could create a very basic skeleton ourselves, just with the appbar on the top

We could do that since it’s the only element that we can assume to be in an app (at least in most cases), but it could also give a sense that this top part is controlled by the wrapper (the app being loaded below), which can be a problem if we want to communicate that this area belong to the app. I’m also not sure how it would feel to use a skeleton but only for one element, and having everything else blank.

[john-light]

I just loaded an organization that was opened two days ago and had a token holder added today via the web app. When I opened the organization in my desktop app, it took 1min 34sec (I timed it) to load the new token holder in the Token Manager app. Two questions:

1. Will this issue address this by at least giving me some indication that something is loading? Although I knew the organization had a new tokenholder approved, if I didn't then coming upon this organization I would have assumed it had less tokenholders than it actually did unless I waited a minute and a half for everything to load. A loading animation would at least indicate that I should wait to see if anything will change once it's done loading.

2. Can anything be done to speed this loading up? (Probably a separate issue, but thought I'd ask while I'm here.)

[sohkai]

There are some in-flight changes that will make the token holder loading be much, much faster, but it's a bit stalled right now due to aragon.js (hopefully landing in 0.6.5).

As for a loading indicator, that will also be coming soon^TM once we start doing a bit more work on aragon.js. In particular, we'll be able to know if we're waiting for the initial events request (which can take minutes) or processing subscriptions (based on how fast a node keeps up with the network but generally faster than metamask).

[sohkai]

Completed with https://github.com/aragon/aragon/pull/770.