Load the template list within the Site Editor without page reloads

[priethor]

Follow-up to #36379

What problem does this address?

In WordPress 5.9 Beta 1, the template list meant to allow for quick navigation between templates within the Site Editor is not loaded on the same page as the Site Editor; there is a page reload both when navigating from the Editor to the template list and when clicking on a template and going back to the Editor. This implementation is not cohesive with the rest of the Editor, which works as a single page with no reloads (e.g., when entering the Template Editor in the Post Editor, or the previous Site Editor sidebar implementation), and degrades the user experience with blank loading screens with no loading indicators.

The example below demonstrates the flow running a brand new local site with WordPress 5.9 Beta 1 and TT2:

Grabacion.de.pantalla.2021-12-02.a.las.19.51.18.mov

What is your proposed solution?

The template list design represents a good first iteration, so it should be researched how feasible it is to load the template list inside the Editor for WP 5.9, even if it is as a modal window but always without leaving the Editor. One of the constraints considered in the current approach is the need for a specific URL for the template list (context in #29630), although it is not a requirement right now and should not be considered when considering this for 5.9.

Because of the time constraints of fixing this during the WP 5.9 beta, if the above doesn't seem feasible for this release, we should aim at enabling back the original W menu in the Site Editor and polish the design to focus on implementing the above as the next iteration for WP 6.0.

---

This issue is a follow-up to #36379, a blocker of the original WP 5.9 Beta release. Contributors worked hard in a crunch to have an MVP ready for the revised Beta 1 date, and this issue aims to fix the UX concerns found as a direct result of the beta testing of this MVP and should therefore be addressed for WP 5.9.

To be mindful of the adjusted WP 5.9 timeline, we should make a decision on which approach to take during Beta 1.

---

cc @noisysocks @youknowriad @mtias @hellofromtonya

[noisysocks]

Sorry, I don't understand. Why is this a blocker for WP 5.9? There is a page refresh when navigating between all other pages in WP Admin. I don't find the experience of navigating between the site editor and template list to be any worse than the experience of navigating between the post editor and post list.

The transition could be improved by improving the loading state of the site editor and by implementing client side routing. (See #36488.) We could address the former in WP 5.9 and continue work on the latter via the Gutenberg plugin.

The template list design represents a good first iteration, so it should be researched how feasible it is to load the template list inside the Editor for WP 5.9, even if it is as a modal window but always without leaving the Editor. One of the constraints considered in the current approach is the need for a specific URL for the template list (context in #29630), although it is not a requirement right now and should not be considered when considering this for 5.9.

A modal would be yet another new interface for this and as such would take time to design and implement. We could re-jig the current design to work as if it were a modal but I don't think this is appropriate because, in the current design, the two screens are very clearly different pages. Every design element is different. As a user I'd expect to be able to link to each page separately and to be able to use the browser's back button. This is how all web pages work.

[mtias]

@noisysocks it looks there was a disconnect along the way regarding what is the aim of this interface that we need to address properly — this should be replacing, conceptually and practically, the sidebar menu under the "W / Site icon" that existed for some time as a quick access mechanism to template structure and template creation. As such, it's not meant to function as a full wp-admin screen with a post list table view.

It is crucial for the full site editor experience to be able to navigate effortlessly between templates while building, tweaking, and designing a site. It's important, for many of the upcoming features (mosaic view, browse mode, global styles zooming out, etc) that the experience of browsing templates is fluid and part of the same session architecturally. It is drastically different in terms of expectations to that of navigating between the post editor and the post list. It's not that it needs client routing or loading states, it's that it needs to be conceived of as part of the natural flow of the editor rather than a separate administration screen.

If the proposed design doesn't work well for this purpose, or is vastly misleading, then the design is flawed and needs to be revisited or fall back to the W sidebar implementation in some way. Should the list of templates be its own screen, it would also need to come to terms with why it's loading so much of the site editor in the first place, since it should be unnecessary to do so. The lack of server-rendering would also be less palatable in a scenario where it stands alone as a separate screen.

[jameskoster]

Because of the time constraints of fixing this during the WP 5.9 beta, if the above doesn't seem feasible for this release, we should aim at enabling back the original W menu in the Site Editor and polish the design to focus on implementing the above as the next iteration for WP 6.0.

A criticism of the 'old' W menu implementation was that it made navigating back to the WP dashboard tedious when you drilled down to access nested templates / template parts. The inconsistent behaviour of the W button between post and site editors was also a little problematic.

In case we cannot find a solution for plan A, one option that addresses both issues would be a dedicated tool for accessing the old template panel:

template-panel.mp4

This frees the W button to behave as it does in the post editor.

[noisysocks]

It is crucial for the full site editor experience to be able to navigate effortlessly between templates while building, tweaking, and designing a site. It's important, for many of the upcoming features (mosaic view, browse mode, global styles zooming out, etc) that the experience of browsing templates is fluid and part of the same session architecturally.

This all makes sense, and I agree, but why is this a blocker for WP 5.9 specifically? This release does not contain any of those upcoming features. As it stands, in WP 5.9 beta 2, one can use the site editor and switch between templates and template parts without any issue. I don't see why we can't release what we have and continue to improve the experience in the Gutenberg plugin and in WP 6.0, WP 6.1, etc.

We are currently midway between beta 2 and beta 3. There are two more betas before the first release candidate. It is too late for further design and development. We need to work with what we have.

#36488 is in good shape and addresses this issue. I would prefer to land it only in the Gutenberg plugin for now so that it receives more testing and so that we aren't creating further stress to the release team. We could then include it in WP 5.9.1, for example.

If you insist that this is a WP 5.9 blocker 🙂 then I would feel more comfortable with including #36488 in WP 5.9 if it received a lot of testing this week including accessibility testing.

Restoring the old W menu is also an option. I'd like to note though that, for this to happen in 5.9 beta 3, we need to open, test, and merge a PR that implements this by Friday. It is not as simple as reverting #36194 as many code changes have been made since that PR landed on 5 November.

[alexstine]

I really wish this could slow down a bit. I've never been a fan of rushing features in and if this technically works, 5.9.1 could provide a much better timeline for testing and ensuring it is done 100% right. It would be different if this was some huge bug, but it seems like an enhancement, yes?

I will try to get my feedback on the PR no later than tomorrow but if this isn't necessary to have, it would be great to get it in to Gutenberg plugin and introduce in 5.9.1 if all is good.

Thanks.

[priethor]

@noisysocks what's your comfort level with including #36488, provided it gets thorough testing vs. restoring the W, considering it's not as easy as reverting, as you correctly pointed out?

In any case, if this is not considered a blocker for 5.9, it would make more sense to me not to compromise by shipping it in 5.9.1 but to take the opportunity to ship a more refined version directly in 6.0.

[noisysocks]

@noisysocks what's your comfort level with including #36488, provided it gets thorough testing vs. restoring the W, considering it's not as easy as reverting, as you correctly pointed out?

I think the former, since there's already a PR for it. That's one less unknown 😀

I'm happy that #36488 has now received lots of testing over in the PR from a variety of perspectives (accessibility, technical, etc). It's definitely ready for the plugin. I'd say let's include it in 5.9 and then un-include it (but NOT hold back the release) if there are problems.

[priethor]

It's definitely ready for the plugin. I'd say let's include it in 5.9 and then un-include it

I agree! Let's aim for Beta 3 on December 14th so that we still have the optional Beta 4 as a buffer before RC. If that feels too rushed with #36488, we could still ship it in Gutenberg 12.2 on December 15th and test it for a few days before Beta 4 on December 21st.