Ensuring local content is not added at the global scope, and vice versa

[annezazu]

The site editor is now a space where you can now edit your post/page content within the context of a template, giving you a more complete and accurate view of what your site visitors will see. However, this does mean we need to ensure we are clearly communicating the distinction between what is global what is local so as to minimise the likelihood someone adds content to the wrong place.

We have noticed this is a common pain point particularly for end users who may be less technical.

There are four opportunities to improve clarity.

1. Highlight what's editable

At the moment, when editing a page with the template visible, we do not do a great job of highlight which blocks are editable at the local/page level. For example, the post title block, featured image, and post content. This increases the chances of "selecting" a block that exists outside the local scope, which creates possible pathways into the global.

https://github.com/WordPress/gutenberg/assets/1072756/b881b367-6712-4076-807e-76e9ddf2340f

2. Increase the prominence of the post content block when empty

When editing a page with the template visible, the current empty state of the post content block is a single empty paragraph. This is fine for posts that more orientated towards writing, but depending on the layout of your pages, it can get lost amidst everything else in the template. The hypothesis is that if we put more emphasis on the content block when empty, and provide shortcuts to patterns, it will lead to a higher chance of content being added there instead of the surrounding template.

3. Greater visual distinction when editing globally

When switching to editing a template from a page we change the toolbar title to purple but other than that we don't do a lot to tell a user they are about to modify something that may affect more than one page/pattern. Adding stronger visual indicators (along with improved empty states like the above content block) will alleviate this.

• [x] Replicate "focus mode" when to a template from a page (padding around editor)

4. More obvious pathways between local and global scope

When in a site building state you often need to switch quickly between local and global as you refine how the two work together. There are three main ways of doing right now: via the command palette, via the template dropdown within the inspector, and via the toast notifications when clicking on a template. These pathways also act as indicators themselves as to which scope a user is currently in. What can we do to make switching contexts more efficient and visible?

• [ ] Treat "template" much like a synced pattern in that it can be "selected" which provides an edit action in toolbar

https://github.com/WordPress/gutenberg/assets/1072756/b7104935-89c7-4669-b557-e1bb39353e08

• [ ] Show template blocks as locked when in the page scope

Original issue

Currently, very subtle distinctions exist between editing a template vs editing a page when in the Site Editor > Pages experience as shown below: https://github.com/WordPress/gutenberg/assets/26996883/956f670b-d015-49f7-b332-92f1d2edb70e You can see a notice about entering different modes and the Top Toolbar slightly changes but, beyond that, it's a drastic difference. Since the start of the Site Editor, a lack of distinction between editing templates vs content has led to confusion and incorrect actions on the part of users. For example, [removing the post content block](https://github.com/WordPress/gutenberg/issues/28779#issuecomment-1745812720) without understanding the full impact, often because the different views aren't clear (and the post content block doesn't look like their content!). I know a lot of thought went into the notices and changes in the Top Toolbar but I wonder if we should consider something more drastic, similar to what we see in other applications like Keynote. We could also reuse the grey background experience that’s visible in template editing or incorporate more of the purple already used for the template parts to indicate when editing a template how it impacts more than just that page. Curious to hear more thoughts from @WordPress/gutenberg-design and to see how we can continue to iterate here.

[richtabor]

We already have "Edit" and "Select" mode switching in the header, but perhaps exploring a more explicit template/post type select could be interesting.

Here's examples from the safari context switching, and google docs:

[SaxonF]

@richtabor that's an interesting approach I hadn't thought of. In previous iterations and a POC branch we used tabs which felt quite nice in practice but diverged a little from the toolbar thinking.

We could also be super in your face about it when editing something that's global, even if its only when you come from editing a post/page.

Keynote does something similar

[jameskoster]

I agree something like the keynote approach could work for the page <> template flows.

But there are also template-centric edit experiences where it can be easy to lose track of what you're working with (Front Page / Blog Home springs to mind). So it might be nice to explore more intrinsic options that work regardless of context.

The focussed editing view / template editing mode in the post editor does a decent job of indicating that you're editing something removed from any particular page. Applying that treatment to all template editing instances could well be overkill, but may also be worth a try.

[richtabor]

We could also be super in your face about it when editing something that's global, even if its only when you come from editing a post/page.

That's interesting. I like how Keynote has the 'Done' button in there as well. A helpful hint to get you back to the normal editing view. Worth an exploration I'd say. Currently the minor changes in the title bar get lost/are difficult to notice. I basically look for the "< back" to see if I'm editing a template. Or see if I get the annoying snackbar notification indicating the opposite.

[SaxonF]

I played with this a bit today on a branch and the keynote while obvious it maybe feels a little too much.

I think @jameskoster approach is worth exploring possibly in combination with using breadcrumbs instead a "back" button to provide a little more context. I don't like that we default to black for the canvas area surrounding the template as. Would be nice to choose a colour thats either light/dark depending on the background colour of the site.

The only concern I have with this approach is if we ever offer a generic zoom function in future and how that would work here.

[SaxonF]

While we are on this topic. Any thoughts on how to make it more obvious that the parts of a template are disabled when editing a page but still provide easy access to editing? This would replace the snackbar approach right now so possibly allow selection of the template as a "whole" which would be similar to synced patterns / template parts. This treats templates almost like synced patterns with overridable blocks (post title, post content etc).

[paaljoachim]

Sharing thoughts... Hovering and clicking to make it obvious the part being hovered/clicked belongs to another editing experience. Seeing header and footer while in Single post editor. Seeing content while in Full Site editor. Or any other place.

Having a kind of closed area with a mostly transparent notice on top saying something like switch to full site editing, page/post editing etc when hovering/clicked. As it would give the obvious distinction between what is being edited and what can be jumped over to.

I remember that last FSE testing to where one added a portfolio. It was hard to distinguish between post/page content and the template being edited. I really did not know where to add a new block. I asked myself a few times am I inside the page content or in the template now? Am I editing the template or page? These editing views merge too much as a better distinction is needed between the two modes. Having a way to make it really obvious and not something that is hidden away easily missed would be helpful.

[jameskoster]

Making the template a selectable 'block' seems worth exploring. It's not clear to me how the Inspector behaves here though. Is it worth considering three tabs when content editing; Template | Page | Block?

[jarekmorawski]

I'm working on a similar issue on the Woo side, where the Shop page is assigned to the Page Catalog template, but it isn't communicated anywhere in the interface (https://github.com/woocommerce/woocommerce/issues/42152).

It seems that the problem is a bit broader as there's currently some awkward behavior when the user attempts to edit a page assigned to a template.

• When the user clicks edit in the page details, we take them to the template editor (change of context).
• When they save changes and go back, we take them to Templates rather than Pages where they came from (another change of context).
• In the site editor, we display the inserter and other controls for adding blocks, although that's technically impossible and doesn't do anything (broken functionality).

You've already shared many great ideas. I took the liberty of mixing them with a few of my own in an attempt to improve the overall communication around the navigation, system status, etc. Let me know what you think! I'm particularly curious about changes to the inspector and the transition between Page and Template tabs.

Add links to swap and edit template in the page details view This would let people skip one step and quickly jump to the template. Alternatively, we could make the template name clickable and either open the dropdown menu, or enter a new drilldown and let users change or edit the template directly in the sidebar.

We'd only show the ellipsis on hover to reduce visual clutter.

Wrap the template blocks in a group and show in the List View in the page editing view When the user edits a page assigned to a template, we currently don't show any blocks in the List View. It's a bit confusing because the blocks are clearly there. A possible solution is to show the "inherited" blocks but in a locked view. We'd label the parent block as a template to differentiate it from regular blocks, but the user could still select it in the canvas just like a regular group.

Blocks that have editable content could be marked with the partial lock icon in the List View.

Add a Template tab to the inspector For pages connected to a template, we'd show an additional tab in the Inspector. It'd list all included areas as well as settings. In the example below, they're limited to just showing the template parts in the preview, but there may be more in the future.

We would automatically select the Template tab when the user clicks the template parent block in the List View.

The tabs would let the user switch between template options (areas, settings) and other templates. Similar to other explorations I've seen for reshuffling patterns, we'd let people change the template visually from within the inspector.

We'd zoom out the page a bit to give the user a better overview of the template and see the page update in real-time as they switch between templates.

https://github.com/WordPress/gutenberg/assets/79307566/e84e3505-0148-4653-8deb-c85e13ef0bbc

Show a visual cue for locked blocks Similar to Saxon's proposal above, we'd add visual feedback when the user hovers over a block that belongs to a template. We'd show the block toolbar on hover and let the user quickly edit it in the template. In the future, we'd display more options, such as detach/override or additional links to edit not just the template, but also embedded template parts.

Template editing I explored changing the top bar's color to black when the user edits a template, but it was too much. Instead, we'd change the title bar's color to purple and display the previously edited page's title instead of the black button.

Additionally, we'd make the snackbar linking to the page permanent. We currently hide it after a few seconds, but it'd be useful to keep it on the screen until the user dismisses it manually. It'd serve as a way out in case the user entered the template editing mode by accident and can't find another way out.

Lastly, we'd use the inspector to bridge the gap between a template and the pages it's connected to. Arguably, the sidebar in the template details view could be a better place for it, but it'd be useful to jump between templates and pages without exiting the editing mode.

[jameskoster]

Thanks for pushing this Jarek, it's an important one, and you're connecting a lot of different issues with these mockups 💪

In the List view, do you think we could we use the generic layout icon for the template instead of the [template] chip? I think that might solidify the concept, and avoid the need to come up with icons for every type of template.

The template toolbar could probably include a "Swap" action when appropriate.

I'm not sure how I feel about the Template tab in page editing context but regardless; For the shuffle affordance, we'd need to be extra careful about making sure the user understands this would affect any content that uses that template. The zoom-out helps a bit to make that connection, but the UI might also benefit from a notice, ideally with a note about how many pages would be affected.

Presenting the template preview option as a setting of the template doesn't feel quite right. Perhaps that panel should be titled "Preview"? What happens in List view when the template preview is turned off, could those features be connected with an 👁️ button like you find in the Layers panel of most design software?

Since the context is page editing, that might be the more appropriate first tab.

A small detail but; in the details panel, could the "Swap template" action live in the main ellipsis menu? In the template row, the name of the template could act as a shortcut to the template details, just like template parts. That would eliminate the need to add a new pattern to the details panel.

Nice work!

[jasmussen]

@jameskoster @SaxonF @jarekmorawski coming back to this one, do we think we have ideas enough to bring this home and update the issue?

[jameskoster]

I think this one is worth a try.

• Margins on frame when editing a template (similar to the Post editor)
• "Breadcrumb" in title rather than "Back" button
• Purple title accents when editing a template

Making the template a selectable "block" still seems like an interesting idea to me, but there are knock-on effects that make it one to explore separately imo.

[jarekmorawski]

+1 to what Jay said. I explored this a bit on my own in the context of Woo's Shop page and came up with a few extra ideas for extra visual feedback when the user enters the template editing mode (note that this could work for dynamic pages and require additional consideration for regular pages):

1. Changing the primary color in buttons, tabs, and other UI elements to template purple.
2. Change the CTA from Save to Done. Clicking it would take the user back to the previously edited page (if that's where they came from. Otherwise they'd remain in the editor).
3. Removing the inserter and other editing controls from the top bar.
4. Displaying a fixed but dismissable message at the bottom of the frame.
5. Showing the inspector by default and adding a new Used in section that lists all pages linked to this template.

Additionally, we could provide a little more context when the user edits a page linked to an existing template:

1. Show an extra message in the List View with a link to the template.
2. Mark the "inherited" blocks as locked and provide some guidance.
3. Show the block toolbar when the user hovers over an "inherited" block.

The video below captures all of these ideas in a single flow. For Woo, we'll likely make some changes to the template structure and will follow your lead for all other interactions, but I think these enhancements are worth considering. 🙏

https://github.com/WordPress/gutenberg/assets/79307566/7a68d018-54f2-4dc7-8d87-e44be0343094

[jasmussen]

I think https://github.com/WordPress/gutenberg/issues/55025#issuecomment-1750031595 is worth a try.

Want to update the issue and update the labels?

[jameskoster]

Done!

[annezazu]

To add a bit more context to the problems at hand, here are a few repeated concerns that come up in real world feedback when working with folks:

• They go to edit a page in the Site Editor and end up editing the template without realizing this template applies to all pages. After clicking save, they are left confused about why all of their pages have changed. To quote one user after they ran into this situation: "the header cover is on every page now???"
• They go to edit a page in the Site Editor, end up editing the template, and remove the post content block when they enter the template editing section not realizing what the impact is partially because the placeholder state just looks like a paragraph. More on this issue here.
• They go to create a new page or edit a current in the Site Editor and, because the warning about editing a template pops up so easily most places you click, they end up in the template editor without necessarily realizing it. When talking to one person who directly support folks using the Site Editor, they said "I believe some users may be getting to the template and modifying it because we specifically prompt to Edit templates when clicking anything that’s in a template while editing a Post/Page. Users then click on it and ignore all messaging." Here's a video showing that:

https://github.com/WordPress/gutenberg/assets/26996883/df1ae198-d392-45cb-a253-d9e3192d2576

[jameskoster]

@annezazu that looks like a bug. The "Testing" page is using the index template despite the page template existing which shouldn't be possible. Perhaps that page pre-dates the page template, and didn't get updated when it was created? We had a similar bug with the Front Page template recently (cc @youknowriad).

[SaxonF]

to @jarekmorawski point and image below, I think its also worth adding locked template blocks to the block list as another indicator. They would only be visible if the "show preview" option is enabled.

In a follow up issue we can look at template selection on canvas as well as a visible way to show template and its actions in the inspector.

@annezazu I think this is definitely worth adding to 6.5

[paaljoachim]

Adding some more perspective.

I have begun looking at WooCommerce. Added this discussion. https://github.com/woocommerce/woocommerce-blocks/discussions/11929 I am adding it here as it also touches upon template vs page editing.

If I was in a page and saw areas that belonged to the template. Then clicked these areas it would be natural to have a message pop up that asks me if I want to edit the template for all the pages. I would click Yes to move to the site editor or no and move back to editing the page. I would not understand that the specific area belongs to the template. In the template clicking Post/Page content. Having a message show up telling me that the Page content belongs to each page that I should not edit it is helpful. The message seen today is totally alright.

One can today wait a few moments and a mostly full page modal shows up asking if we can to insert a page template. Taking this one step further is to have the template auto inserted into the page, CPT, Learn, WooCommerce etc. I am bringing this in as another thought in how to create a bigger difference between a page/post <-> template.

I made this somewhat messy video. I hope the message come across in an alright way. https://youtu.be/byhaGPdfPUk

[mpkelly]

I like this idea of making template editing distinct by using different colours.

The menu could also be updated so you can see the pages that inherit from the template, as this will help users understand the relationship between the two. It would also give users the option to edit the page instead.

But I think the best solution would be to make theme templates read-only and make it so the pages that use them don't inherit content and style changes. Instead, let users clone templates to quickly create new pages with content detached from the source. This still allows theme designers to ship large chunks of content without the shortcomings of templates, which are quite advanced and I feel are unnecessary with the other abstractions Gutenberg offers.

As a programmer, I am thinking about how web developers turned off the cascading nature of CSS in CSS-in-JS because of all the problems it caused. I am also thinking about the sage advice to favour composition over inheritance.

[SaxonF]

This is an extension of some earlier thoughts. For pattern overrides we are facing similar challenges so ideally we can align on the approach when dealing with global elements that allow the user to edit certain internal blocks.

https://github.com/WordPress/gutenberg/assets/1072756/e6dea5fd-47be-472e-9d42-ce46e5d58764

https://github.com/WordPress/gutenberg/assets/1072756/4b38f8a6-41cb-4880-b810-bf4ed05a97dc

[SaxonF]

I think we can break this work down into four distinct but connected opportunities for improvements under the broader pain point of:

Ensuring local content is not added at the global scope, and vice versa

The site editor is now a space where you can now edit your post/page content within the context of a template, giving you a more complete and accurate view of what your site visitors will see. However, this does mean we need to ensure we are clearly communicating the distinction between what is global what is local so as to minimise the likelihood someone adds content to the wrong place.

We have noticed this is a common pain point particularly for end users who may be less technical.

There are four opportunities to improve clarity.

1. Highlight what's editable

At the moment, when editing a page with the template visible, we do not do a great job of highlight which blocks are editable at the local/page level. For example, the post title block, featured image, and post content. This increases the chances of "selecting" a block that exists outside the local scope, which creates possible pathways into the global.

https://github.com/WordPress/gutenberg/assets/1072756/b881b367-6712-4076-807e-76e9ddf2340f

2. Increase the prominence of the post content block when empty

When editing a page with the template visible, the current empty state of the post content block is a single empty paragraph. This is fine for posts that more orientated towards writing, but depending on the layout of your pages, it can get lost amidst everything else in the template. The hypothesis is that if we put more emphasis on the content block when empty, and provide shortcuts to patterns, it will lead to a higher chance of content being added there instead of the surrounding template.

3. Greater visual distinction when editing globally

When switching to editing a template from a page we change the toolbar title to purple but other than that we don't do a lot to tell a user they are about to modify something that may affect more than one page/pattern. Adding stronger visual indicators (along with improved empty states like the above content block) will alleviate this.

• [ ] Replicate "focus mode" when to a template from a page (padding around editor)

4. More obvious pathways between local and global scope

When in a site building state you often need to switch quickly between local and global as you refine how the two work together. There are three main ways of doing right now: via the command palette, via the template dropdown within the inspector, and via the toast notifications when clicking on a template. These pathways also act as indicators themselves as to which scope a user is currently in. What can we do to make switching contexts more efficient and visible?

• [ ] Treat "template" much like a synced pattern in that it can be "selected" which provides an edit action in toolbar

https://github.com/WordPress/gutenberg/assets/1072756/b7104935-89c7-4669-b557-e1bb39353e08

• [ ] Show template blocks as locked when in the page scope

[jasmussen]

Lots to like there, Saxon, nice work, and it absorbs many of the ideas that @jarekmorawski had as well.

Two nitpicks: the hover edit icon with the blue background, we don't use that style of icon anywhere else. Can it be smaller, or just the icon, or a different style? And at 12s in the video, the height of the document title field increases to fit some help text below. I wonder if we can do something else, it gets a little tight there. Mainly it's the layout shift of the field that makes it feel jumpy.

[jameskoster]

It recently occurred to me that there’s significant overlap between templates and partially synced patterns. Regarding designs for the latter I’m not fully up-to-speed, but I’m curious whether work in that area has influenced the direction you’ve shared here? It looks to be so, but I wanted to check whether these principles might be applicable in both situations with minimal adjustments.

[SaxonF]

@jameskoster Yep I shared the same designs here so ideally we can build in such a way we can reuse for synced patterns

[noisysocks]

Thanks for summarising everything in the issue description @SaxonF. I'll start digging into the four aspects described.

[youknowriad]

One thing we should consider when implementing stuff is that we should stop thinking of the post editor and the site editor as two separate editors. Both should work in the exact same (some small exceptions remain but hopefully we can remove them over time).

[jasmussen]

One thing we should consider when implementing stuff is that we should stop thinking of the post editor and the site editor as two separate editors

Agreed, this is related to the top toolbar conversation as well, CC: @draganescu

[draganescu]

So we should add the chevron back to collapse the top toolbar even if there is nothing hidden behind it.

[richtabor]

Have we explored a less intrusive approach to indicating what can be edited? This is reminiscent of the Customizer edit icons.

I'm not sure about the edit icons. Out of the box, everything on the page is editable, while we use lock icons to depict when something is not. We're doing the opposite here. Also this breaks the visual of this feeling like a front end page, but rather an application that you to fill out.

[noisysocks]

There's been a bit of discussion about this between myself and @SaxonF and between @SaxonF, @richtabor, and @jasmussen. I'll summarise quickly where I think we're at with each of the four parts outlined in the description of this issue.

---

1. Highlight what's editable

https://github.com/WordPress/gutenberg/pull/57901 was merged which implements part of this but we've found it too distracting/overwhelming in practice. Saxon and I will iterate on this to make the outlines less prominent: flash them when the locked container is clicked, and then fade them out. I've started this in https://github.com/WordPress/gutenberg/pull/58159.

https://github.com/WordPress/gutenberg/pull/57992 was opened which began to implement the other part of this but I've found it to be both technically cumbersome to implement Saxon and I agree it's not that urgent. Going to punt this idea for now.

2. Increase the prominence of the post content block when empty

@ramonjd opened https://github.com/WordPress/gutenberg/pull/57572 which uses Placeholder to do this. We think this approach interrupts the writing flow too significantly, though, so we're going to try out some other ideas.

3. Greater visual distinction when editing globally

Still to do.

4. More obvious pathways between local and global scope

Updating the list view to show the template as a selectable element only makes sense if we're also doing https://github.com/WordPress/gutenberg/pull/57992. Therefore going to punt this idea for now, as well.

[annezazu]

In terms of 6.5, I'm going to remove this from the board based on the above. It sounds like most has been punted/the rest still needs more time. If that's incorrect, just let me know or add back onto the board!

[noisysocks]

I think we can prioritise the first two items of this issue for 6.5 (so basically merge https://github.com/WordPress/gutenberg/pull/58159 and https://github.com/WordPress/gutenberg/pull/58232) as they a) address a very common usability pain point, and; b) would benefit from wider testing and feedback. Everything else can wait until 6.6 and beyond 🙂

[annezazu]

Great. I'll add those two to the board.

[annezazu]

Want to cross connect this issue with block outlines being hard to see when we look at the flash of the outlines as a solution: https://github.com/WordPress/gutenberg/issues/41261

[colorful-tones]

Hi folks, We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.

[noisysocks]

We can probably just go ahead and close this out. No doubt we'll keep making tweaks in this space but for now I believe we've merged as much as we have an appetite for.