Improving the preloading experience

[marcinbauer-ohf]

Goal

• Make the loading experience of HA on web or native app a smoother experience
• Incorporate the Open Home Foundation logo in the viewing experience

[matthiasdebaat]

We have a Discord thread about the iOS loading experience. The discussion is about improving the loading experience across web and mobile, since the current one feels a bit jumpy and inconsistent. There is general agreement that this is worth fixing and that we should start with simple improvements like removing visual glitches, aligning layouts, and smoothing transitions between loading and content.

Some more advanced ideas like animated logos and stronger OHF branding were explored, but they raised concerns around performance, visual noise, platform limitations, and needing marketing input. There are also some technical constraints on iOS and ongoing work on Android that affect what can be done right now.

Open questions

• Should the loading experience live in the frontend or in the native apps?
• How should it behave for fast vs slow loads?
• How much animation or branding should we include?
• Do we need marketing approval for logo animations?

[matthiasdebaat]

For reference. I mapped out the iOS loading animation. There are a few small tweaks we could make to make it feel more seamless, for example by removing the jump during loading or getting rid of some blank states.

[TimoPtr]

Just for history home-assistant/frontend#25563

[bgoncal]

Should the loading experience live in the frontend or in the native apps?

It needs to exist in frontend anyways since user may access from browsers, so I would start from there and add app layer if/when needed.

[timmo001]

IMO the frontend (browser) should do this for overall consistency, as soon as the app is ready with a webview it should hand off to tha. Any animation, loading, etc. should be handled there.

We spoke of a short and fast animation for the logo, which would transition into the fully loaded UI.

There's a lot of work needed for the last part, especially when it comes to dashboards, we need to be able to trigger an event when everything is loaded in, however we currently have no way of knowing this as everything is async.

This is mostly implementation not design side, but I would say most of the situations I find are within a second or two. I would love to be able to hide that pop in effect also while doing this in the same regard.

I would also like to see a logo animation everywhere, so would be good to share that so we see it on the website and other content (livestreams already do this now)

[TimoPtr]

IMO the frontend (browser) should do this for overall consistency, as soon as the app is ready with a webview it should hand off to tha. Any animation, loading, etc. should be handled there.

We spoke of a short and fast animation for the logo, which would transition into the fully loaded UI.

There's a lot of work needed for the last part, especially when it comes to dashboards, we need to be able to trigger an event when everything is loaded in, however we currently have no way of knowing this as everything is async.

This is mostly implementation not design side, but I would say most of the situations I find are within a second or two. I would love to be able to hide that pop in effect also while doing this in the same regard.

I would also like to see a logo animation everywhere, so would be good to share that so we see it on the website and other content (livestreams already do this now)

The issue on the app is that we have a splashscreen in any case and align it with the frontend is just impossible, because of all the devices we have to support. If you are able to make this event that you are talking about we can hide completely from the frontend from the app. We should indeed share the animation.

[TimoPtr]

But I do agree with @bgoncal that it's a second step, first let's make it happen on the frontend.

[krsilas]

This may be a bit off-topic, but when I looked into the loading time of my instance, the biggest bottleneck was that the CSS is loaded via WebSockets every time, including themes that are not in use. Since these rarely change, it would help a lot to load the styles via HTTP so they can be cached.

[bgoncal]

Regarding having it in the app as well as in the frontend, at some point we will need to check how it behaves in slow networks.

Currently in a slow network the user sees a blank WebView (not even the web loader appears for a while).

So I would say:

• Implement in frontend, make it exactly how we want
• Plan an app implementation (perhaps we can share animation logic using Lottie or such a thing)

[marcinbauer-ohf]

Linking the version with the animated logo: https://www.figma.com/board/Q9ukHxdSs5k97mXtlB4jFW/Home-Assistant-loading-experience?node-id=44-75&t=Y6xQIAKTMJCO3MXx-11

Demo of desktop: https://cloud.protopie.io/p/19ef79ed0792b69c97f21996
Demo on mobile: https://cloud.protopie.io/p/bd3651aba8bb54fb3ab175b5

@GuySie we're discussing should we use the animated OHF -> HA logo that I've proposed and whether that would be ok with branding.