Re-Introduce Content Editing in the Site Editor

[jameskoster]

Visual

Tasks

• Site Editor: Add ability to focus on editing a page's content vs the page's template #50857 (@noisysocks)
• Add the pages menu to the site editor #50463 (@youknowriad)
• Mark Front page and Posts page according to site's home page settings
• Creation modal for "New Page" #48456
• Add quick links header to the templates and pages site editor sidebars #50500 (@youknowriad)
• Add dynamic templates to pages list #50418
• Blank state for post content block #49086 (@tellthemachines)
• Pages list displays 50 pages, ordered alphabetically
• "Manage" button in the panel header links to wp-admin pages list. Existing "Manage all pages" menu item removed.
• Parent/Child relationships indicated, hopefully using List View components for expanding/collapsing.
• Warn users prior to removal of critical blocks in blog templates #40618
• Empty Post Content in Pages doesn't always contain initial template #50984
• Site Editor: clicking on page in Navigation section and returning brings you to Pages section #50676

[jameskoster]

One option (which overlaps with Browse Mode) would be to present the web site in a frame upon entering the Site Editor (a concept first introduced in https://make.wordpress.org/design/2022/06/13/thinking-through-the-wordpress-admin-experience/). The frame could feature a dynamic address bar, allowing folks to search for content to display and edit:

browse.mp4

One problem with the previous drill-down approach was the fatigue it caused when navigating deep into content trees. The dynamic address bar solves this. Another benefit is the obfuscation between content and some templates, for example it seems reasonable to surface the 404 template if one were to search for it here.

[jasmussen]

I like that minimal browse mode for allowing you to choose content to edit, if we pair it with an explicit "Templates" item in the sidebar for when editing that is your intent.

The bigger win would be to not drop you directly into editing your "Home" template, rather to allow you to make a choice first in the open-by-default sidebar.

Should we try and prototype a minimal version of that? Someting like:

• Site editor with sidebar open by default and your homepage loaded with content in a minimal browse mode on the right.
• All content inside browse mode non-interactive though a Disabled overlay. Click "Edit" to edit, or perhaps click the entire overlay, tbd.
• Still shows options for Site, Templates and Template Parts on the left.
• Site still takes you to the home page, but the dropdown and search allow you to load a particular template/post content combo.

This would let us still have a generic template list as it exists today, and could be a small step towards true browse mode where links in the viewport actually become clickable.

What do you think?

[jameskoster]

The bigger win would be to not drop you directly into editing your "Home" template

100%. I think it's vitally important that we place template editing / management at an appropriate altitude in the UX. It's over-emphasis one of the biggest overall sources of confusion in the site editor.

Should we try and prototype a minimal version of that?

That's certainly an option, though I find the "Site" button a little awkward, and it's quite buggy (#42807, #36821).

We might place Templates in a drill-down instead. That is aligned with the de-emphasisation of template management mentioned above, and would eliminate the need for the buggy "Site" button. As an added bonus it'd create space for us to delineate different template (and part) types, which is something that has come up in #42325.

Here's a demo:

templates.mp4

If that leap is too large, then your suggestion sounds like a good middle-ground to me.

[jasmussen]

I like the idea that you see the viewport and are able to click "Edit" to edit the content.

I think it's too early to put Templates inside the "Library", I would intuit mainly custom stuff be placed there. Which yes, arguably you can create custom templates, but it still feels as stretch, so to reduce drilldown we should probably keep templates top level for now, IMO.

[jasmussen]

As a small update, a navigation interface was recently merged:

The feature isn't yet implemented, but clicking a navigation item in the sidebar on the left, is also meant to load that page in the view on the right. It's a nascent taster of "browse mode", as the view on the right should similarly be navigable. It also doesn't preclude a separate "Content" drilldown to let us search pages, posts, or otherwise. But nevertheless, it's a small status update for this one.

[fabiankaegy]

I mentioned this in today's Core Editor Chat, but I wanted to also share it here for the record.

Given how close we are to the feature freeze of 6.2, introducing this without the ability to test it in a few Gutenberg plugin release cycles would be rushing it.

I really want this feature to be available asap. But less than a week before the feature freeze doesn't leave much time for testing & fine tuning the experience.

Happy to be proven wrong though if anyone disagrees.

[ndiego]

Thanks @fabiankaegy, I have moved this to "In discussion, needs decision" on the board.

cc @Mamaduka @ntsekouras

[jameskoster]

To expand on @jasmussen's earlier comment, one idea that has bubbled up in design discussions around #36667 is that a document-level panel in the drilldown menu area could be a useful design pattern.

Clicking a page in the Navigation panel does two things:

1. Updates the 'frame' to display that page
2. Drills into a panel containing meta controls for that page

To begin with the panel can start simple – perhaps it only contains the title, publish date, and Edit button. But as demonstrated in the diagram above, in the future we can expand this to include high-level edit capabilities such as changing the template, featured image, etc.

By allowing the document-level panel to contextualise what is visible in the frame, the burden on the 'site hub' is lessened so that it can probably revert back to displaying the site title.

---

If this pattern works well we can use it in other sections like Templates. A template drilldown could (for example) offer quick ways to change the header / footer, or select a pattern for the entire template, without having to engage the 'full' editor.

cc @youknowriad

[Mamaduka]

@jameskoster, now that #47387 is merged and #47777 is in progress. What are the remaining items for this feature?

[jameskoster]

I think the final piece required to close this issue will be a method of accessing content that is not represented in the main navigation. For example editing an individual post. I've seen 'command palette' concepts shared elsewhere, e.g:

command.palette.mp4

But I don't know if we're 100% ready to commit to that yet.

[Mamaduka]

The command bar would be cool but also as a general assistant for the editors 🤩

[noisysocks]

Another remaining item is that users should be able to click on links within the preview on the right hand side, yeah?

[jasmussen]

Another remaining item is that users should be able to click on links within the preview on the right hand side, yeah?

Possibly/probably in some form eventually yes! During 6.2 development, we shelved this aspect of browse mode in favor of title plus edit icon in the left navigation, with the frame preview as one big additional edit button. I do see URL navigation returning at some point, whether it's like originally envisioned, or perhaps when holding ⌘. But after the refocus, that aspect should probably not hold up this issue.

[ramonjd]

To be honest, I'm personally not convinced why we should show pages on "hover". It's a weird behavior since one might think, he can go and click the page as it's visible but as soon as you leave the page itself, you'll be back to the home page causing frustration. What's the reasoning for

I've been playing around with it and have come to the same conclusion. The work involved to get it to the point where we'd be able to load full templates and page content (and their styles) in unison with mouse movements is, in my opinion, not a great investment.

If it was something that we desperately had to do, then I'd speculate that we'd want to have an alternative way to load the previews — separate to the editor — so we could better manage preloading and so on.

[annezazu]

I see needs design has been removed. Adding this as needs dev and moving it forward in the respective project board. Feel free to change back as needed!

[SaxonF]

@youknowriad one of the main benefits of the side by side / frame paradigm we've adopted here is it gives us a way to quickly preview content without having to dive in and out. Since we now drill down on click we aren't making full use of that paradigm. What is the benefit of side by side view vs a table if we don't have a way to preview? We might as well just take people to a table. MacOS finder offers the ability to switch between view types because they are each ideal for a certain use case.

[youknowriad]

I can't speak about the benefits of the side by side view, but I'm talking more about the UX feeling when hovering these menu items, I don't really expect what's on the right to change, especially since I can't interact with it. Anyway, it would be cool to get some more testing on the related PRs to experience it and see how it feels. I just now that it feels very confusing to me.

[SaxonF]

That's fair. @ramonjd disregarding performance, if we could get a demo branch up to play with that contains just hover I think that would be worthwhile. We can even just copy the code from the branch I linked to above.

[tellthemachines]

I agree that the hover thing feels very awkward. I wonder, if the problem is finding a way to view contents without drilling down, do we really need the detail view for each page/template?
This

has no useful information.

If instead of showing the detail view, clicking on a page or template just showed it in the main area while keeping the list of pages/templates in the sidebar, navigation would be so much easier.

[ramonjd]

disregarding performance, if we could get a demo branch up to play with that contains just hover I think that would be worthwhile. We can even just copy the code from the branch I linked to above.

No worries at all 👍

Here's something folks can play around with get a feel for whether it works or not:

• Site Editor Sidebar: display preview in the frame when hovering mouse over a page #50647

As for the implementation I'd say we'd need to find a different way given the way it affects the browser history.

[jameskoster]

Just a note to say I've updated the OP to include the latest designs, and added a couple of tasks to the list.

[jasmussen]

We're discussing a bit in #49597 (comment), but I'm not too sure about the "Manage" links in the title. It doesn't seem like a pattern that will scale to translations. Everything else looks good to me.

[jameskoster]

I think the shortcut is useful as the page list in the panel is not exhaustive.

Perhaps it can be a contextual item in the command palette (related: #50407)? What do you think @richtabor?

[richtabor]

Perhaps it can be a contextual item in the command palette (related: #50407)? What do you think @richtabor?

I’m not quite following?

[jameskoster]

Apologies. I was suggesting that "Manage pages" could be a contextual shortcut in the command palette, when you're viewing the Pages panel in the Site Editor. It would link to wp-admin page list.

[mtias]

It looks like the main work here is done, the follow ups are either not strictly related (add new page modal) or further improvements. I'm going to close this. Let's make sure to open issues for things that are relevant and don't have issues open yet.

[porg]

🤔 This issue is closed? Really?

I'm wondering because I tested Gutenberg 16.1.2 today, but saw no possibility to edit a page and template combined (as it was possible til until 15.9.1)

• Yes, there is a meanwhile more seamless and clearer possibility to SWITCH between page editing and template editing.

• But adapting e.g. H2 font size with an optimistic "Sample" heading is simply not the same as with a "Realistic Headline which may break the Layout" and tweaking the Styles or block settings or colors in the Site Editor with that — Showing you how styles work with REAL content.

So where is that possibility now?

[noisysocks]

Based on feedback it was very confusing for users to edit both template and page at the same time hence the split. I appreciate it's useful for theme authors to preview with real content though. #28466 looks like a good way to address that.

[porg]

Thx, had followed up there meanwhile.