Refine the Site Editor loading state

[jameskoster]

Here's the current experience loading the site editor:

loading.mp4

A couple of issues to address:

• The FOWPA (Flash of wp-admin) is awkward. Can we hide it?
• The light grey background feels a bit broken. Can we use the dark grey background from the template editor, and isolated template part editor? Use a dark background for the site editor #35520
• The "Loading..." label in the top bar is easily missed. Something on the canvas would be more obvious.

[mtias]

Also the way different template parts can load at different times can be disorienting. I think we should consider loading everything before showing anything so that there are no jumps. Maybe also treat the gray as an overlay so we render in the background and then fade it out.

[talldan]

I created an issue for discussing the preloading of site editor content over here: #35942

That would get rid of the disorienting nature of loading the editor. It might not be a quick win for 5.9, but could be something to consider in the longer term.

[jameskoster]

I worked on a few full-screen loading graphics here and assembled my favorites in to some prototypes that demonstrate the full flow here.

[shaunandrews]

I like the simplicity of the "Indeterminate bar" option, and I think it would work really well with Matías' suggestion of loading the pieces in bit-by-bit with an overlay.

There's something off about the geometry of the "Layout" options; I think it has to do with the border radii and line-widths being different from the Gutenberg icon language. Perhaps it could work better if it felt more like a large icon, rather than its own thing.

--

I think there's an important bit to consider in this design: How does this handle things when it never actually loads for some reason?

[jameskoster]

I suppose it depends on what exactly doesn't load. Hypothetical scenarios:

• Nothing loading at all – total timeout
• Editor chrome (top bar, breadcrumbs, etc) loads – but nothing else
• Editor chrome + template loads, but template part(s) fail

I'm not sure how likely each of these are, or if I'm missing any?

Doesn't seem like there's much we could do in the first scenario. For the others, a modal / placeholder with "Try again" action might work?

failure.to.load.mp4

[mtias]

@youknowriad and I discussed a broader issue of patterns and templates loading in stages that we should aim to address holistically. The end goal should be that things load like a "screenshot"; all fully loaded when you start interacting.

[shaunandrews]

The end goal should be that things load like a "screenshot"; all fully loaded when you start interacting.

Not sure I know what this means... are you suggesting something like progressive loading, where things are loaded as a low-resolutions (literally and figuratively) at first, and detail is added over time until complete?

[mtias]

Sorry, I mean render the final state and don't show tearing (in progress, half-rendered states). Wait until everything is loaded.

[jameskoster]

If we're able to determine how many things there are to load, and the status of each one, we could perhaps display a determinate loading indicator. Something like:

loader.mp4

We may want to embellish it with a logo, or some accompanying text, but I kind of like the simplicity of the bar on its own.

Errors could be handled like so (with a better error message, obviously :)):

loader-error.mp4

[mtias]

@youknowriad @jsnajdr I believe the work on suspense at the data layer is in a place that can unlock working on this?

[youknowriad]

@mtias Yes, I think now that the API is in, the next step would be to add the SuspenseProvider to the editors (edit-post, edit-site...) and start switching some useSelects to this and see the impact.

[tyxla]

I tinkered a bit today with useSuspenseSelect with the site editor, here's a proof-of-concept:

#42525

I'm heading AFK until the end of next week, but when I'm back I'm happy to continue experimenting with this.

[annezazu]

Noting that upgrading to React 18 was merged in #45235, marking a big step forward to unblock this work!

[tyxla]

Latest update: In #46467 we're now working to enable concurrent rendering features, which is the last step before we're able to experiment with startTransition / useTransition and altering useSelect to use useSyncExternalStore.

[tyxla]

I've been working on another version of the experiment today:

#47612

Here I tried another approach, which I'm hoping to be better and more flexible in terms of us being able to declare the dependencies for each suspense boundary.

[talldan]

It seems like the post editor also needs some work now, possibly since the iframe was introduced:

Kapture.2023-02-02.at.11.56.57.mp4

It might be a different problem though, it's more likely that the styles in the iframe are not ready immediately, and that's causing a flash of unstyled content.

I can make a separate issue if you think that's best.

[tyxla]

If you ask me, this is worth a separate issue. Not only that it's in the post content, but it might be solved with a different approach - for example by waiting for the iframe to fully load before showing it.

[talldan]

I've made an issue for it - #47724.

[annezazu]

As WordPress 6.2 gets underway, I wanted to quickly offer a recap of the work that's been done on this issue and why it remains open for now.

• A PR was merged to Update the site editor for better initialization.
• A PR was merged to enable concurrent mode by implementing mount/unmount with createRoot.

Finally, an additional PR is underway-Site Editor: Improve loading experience. For WordPress 6.2, meaningful progress in this area has been made where there's enough confidence to move forward with removing the beta label. Improving the loading state, similar to areas like performance, are iterative and continual in many ways. As a result, this issue is remaining open since there is more that can be done with access to various APIs after the React 18 upgrade that can smooth the experience even more in an iterative manner for the next major WordPress release.

[tyxla]

Thanks for the recap, @annezazu 👍 More experimentation will come in this area in the following weeks, likely in the form of new PRs, as suggested here for example. Will keep everyone posted. We'll find a good way to improve the loading experience for everyone 👍

[annezazu]

👋🏼 Checking in here to see if this experimental PR is still active and where work stands for the overall refining the site editor loading experience as it's been two months since the last update for 6.2 related items. I want to make sure I'm not missing anything in the phase 2 monthly updates :)

[tyxla]

Thanks for checking in @annezazu - it hasn't been a priority over the past weeks, but there's still some experimentation that we'd like to do, albeit it not being on top of our list.

[tyxla]

I've been working on a third version of the experiment, which I believe might be the one we end up using.

Still need to polish it, fix tests, add demos, etc. but it looks promising so far: #50222.

[tyxla]

#50222 has just landed, improving the site editor loading a lot, particularly the editor canvas loading:

Screen.Recording.2023-05-10.at.10.52.17.mov

We still have to work on improving the zoomed-out view loading state, so I suggest that we keep this issue open as we're working on that.

[mtias]

I'm fine closing this one since it's our main tracker for 6.3 and it's useful to see it's covered. We should break down followups and further improvements more granularly into a tracking issues.