Gutenberg: Site Editor: Improve template part visibility

[carolinan]

Is your feature request related to a problem? Please describe.
When editing a full page template, it is not possible to see where a template part begins and ends.

When adding new blocks or moving blocks, the only way to know for sure that you are editing the correct template part, is to hover over the preview in the template part drop down menu.

I would like to be able to move blocks with ease by just dragging them from one template part to another. This is nearly impossible today.

Describe the solution you'd like
Add a border to indicate where the template parts are.
This needs to be visible but not distracting, and it needs to work with themes with different background colors.

Describe alternatives you've considered
Selecting a template part and editing that alone is an option, but it is slower and it does not give you the overview of the full page.

[vindl]

Agreed. It's very hard for me to tell whether the content that I'm adding belongs to the template part or the regular page content. I usually have to resort to scanning the block breadcrumb at the bottom or the block navigator.

I was thinking that something like spotlight mode could work, but that's already taken and works on a block level. We probably need a different visual indicator for this that will allow us to easily discern that we are editing a reusable/global area. I think it should only be toggled when blocks that belong to template part are focused.

cc @MichaelArestad @olaolusoga @joanrho

[Addison-Stavlo]

I wonder if the same sort of style used in 'spotlight mode' would work well for this (or maybe that + an extra border/outline)?

Say that for template parts, the spotlight wouldn't be a toggle setting and that style would always be triggered with the template part selected. Then if the user chooses to enable spotlight mode as well the border would still give some sense of the template part visibility.

[MichaelArestad]

@Addison-Stavlo This is something I'm exploring, but it's not my highest priority yet. I would like to see template parts built to function like the prototype here first.

Not being able to select the block is a problem with more than just the template part block as well. Really any parent block. There are a few features that have been added to help (like the parent selector) and I've even proposed a persistent sidebar for the block navigator that would aid greatly.

What I'm exploring is more around stylistic differences to potentially help communicate the user is modifying something different than the usual block.

[noahtallen]

Now that we have the inserter design mostly working like that, do we have any more ideas about how to improve visibility?

help communicate the user is modifying something different than the usual block

It's definitely very tough to tell which entity you are editing between page content/template/template part, so I definitely agree that a broader change might be helpful 🤔

[MichaelArestad]

Now that we have the inserter design mostly working like that, do we have any more ideas about how to improve visibility?

Not yet. I've experimented with some color changes, borders, and intermediary states (like an edit button), but nothing I've worked on feels quite right just yet.

[olaolusoga]

Spent a moment creating a prototype of how this could work. This leverages bits from Gutenberg—spotlight mode, select mode pattern—and introduces a new mode: browse Hover. BrowseHover mode provides a way for folks to browse pieces (templates, blocks) in the editor.

Here's a link to a GIF that shows all the elements at work—it was too large to add to GH.

---

Here are static shots of hover states for template parts (header/content/footer)

Header

Content area

Footer

Editing template part selection

Again, here's a link to a GIF that shows all the elements at work—it was too large to add to GH.

---

Things happening in GIF

• A hover state is introduced into the editor for template parts— and maybe blocks. A site layout is composed of different template parts (header, content, footer, sidebar). When a person first views a layout in the editor they they can hover over the different template parts to select each part they want to edit.
• When they select a template part, it uses spotlight mode to reduce the visibility of the rest of the layout—so the selected template part is focused. While in the template part a person can make modifications with said template part.
• Once completing edits, a person can select outside of the template part to exit back into the layout.

A few more things are added to the prototype

• The topbar has a label at the center of the topbar. This is the document title. There is work happening to place document level settings behind the label via a dropdown.
• When a person enters a template part, the label changes to reflect the template part a person is in. This is to provide context/wayfinding.

On color:

• The hover state border is blue at the moment, but think we can explore a better color (black?). This shouldn't detract from moving forward with a direction. What is important here is the interaction pattern, and UX to go in and out of a template part.

[shaunandrews]

browse (this might already be in the works). Browse mode provides a way for folks to browse pieces (templates, blocks) in the editor.

There's an existing issue for a Browse mode, which is unrelated to what you're suggesting.

It seems you're describing Select mode, and your screenshots/GIF seems to reflect the visual design of blocks in Select mode.

[olaolusoga]

There's an existing issue for a Browse mode, which is unrelated to what you're suggesting.

Yeah. What's in the GIF is the select mode pattern activated on hover, not click. Thanks for sending over a link to the Browse mode issue. It is unrelated. We need to figure out a more seamless way to handle switching between these mode.

The mode in the work above is a step between select and edit mode. It needs a name. Hover mode? Ideally hover is just baked into edit and select mode where a person can be in edit mode, hovers over to another block which displays the block label using the select mode pattern , selects it, and lands in edit. So edit, hover, and select work in concert.

[enriquesanchez]

These are really great explorations @olaolusoga, thank you! 🎉

What's in the GIF is the select mode pattern activated on hover, not click

Would I only be able to hover over template parts in this mode? If I want to select an inner block, I'd have to click on the template part first?

I do agree that visualizing the template parts helps tremendously, and being able to "zoom into" a template part and go into "spotlight" mode feels right, but I do worry that there'll be a lot of clicking in order to be able to edit something, as opposed to just a direct click-to-edit anything. But maybe that's OK and provides the necessary affordance for folks to understand that they're editing inside a template part?

If we do some kind of spotlight mode though, would you still be able to drag a block from one template part to another?

Re: the "select mode" selection style, I do like that reusing it here avoids the need to learn yet another focus/selection type. I'm however concerned that this could break user expectations, given that "select mode" is a different thing in the editor.

If we lean toward a spotlight effect, we could consider using that as the hover interaction as well? Something like this:

[Addison-Stavlo]

it uses spotlight mode to reduce the visibility of the rest of the layout

My concern here is that spotlight mode may already be enabled in a user's editor preferences. In which case only the selected block inside the the template part with be spotlighted (not the entire template part).

This means that leveraging spotlight mode to improve template part editing visibility will only be effective when the user is not using the current 'spotlight mode.' How do we want this to behave when spotlight mode is turned on?

• We could make the standard spotlight mode not work inside template parts when a template part is selected? - Although this doesn't seem ideal, as users may want to have the current block-based spotlight mode available while editing a larger template part.
• We could accept this limitation. If spotlight mode is turned on, then block based spotlight as shown above will prevail and the spotlight will not contribute to the template part's visibility.
• We find some other way of highlighting the selected template part / fading the remainder of the page.

One basic idea would be to cast a semi-transparent box-shadow from the selected template part. This would both help to highlight the template part and still play nice with the current implementation of 'spotlight mode':

Although this may not be very visible with darker themes, in which case we may need to adjust the color/transparency value of the shadow based on the theme's background color. 🤔

@olaolusoga - any thoughts about how enabled spotlight mode would conflict with trying to use the same mechanism to highlight template parts and other options to get around this?

[olaolusoga]

@enriquesanchez

Would I only be able to hover over template parts in this mode? If I want to select an inner block, I'd have to click on the template part first?

Depends what layer a person is viewing. Template parts are essential grouped blocks, or a container for blocks that can be used "globally" (across multiple layouts/pages). IMO, template parts are a step above blocks in hierarchy, and having the click-in interaction denotes that order. If we lean into entropy, meaning there is no order, then I don't see the value of a template part—if all blocks are selectable at all levels. We can always build this to feel it out, and iterate. At the moment we have no order, which is leading to a lack of visibility in hierarchy, so we should lean towards introducing hierarchy, which is what the "click-in" step does.

In terms of the hover mode, that can be applicable across all levels, meaning I see value at a block level of having hover mode. Reason: "hover" is pretty much "select" mode without the click.

but I do worry that there'll be a lot of clicking in order to be able to edit something, as opposed to just a direct click-to-edit anything. But maybe that's OK and provides the necessary affordance for folks to understand that they're editing inside a template part?

Yup, affordance is key. Entropy is hard to contextualize. We should lean toward affordance, hierarchy, learnable patterns—anti-entropy.

If we do some kind of spotlight mode though, would you still be able to drag a block from one template part to another?

Maybe we don't need spotlight mode. It does help with isolation, but it does make movement between templates more tricky. We can remove spotlight mode idea, while retaining the rest.

Re: the "select mode" selection style, I do like that reusing it here avoids the need to learn yet another focus/selection type. I'm however concerned that this could break user expectations, given that "select mode" is a different thing in the editor.

Yeah, I think we need to think through the modes more. What is the use case for select mode? What value does it provide users? atm, I don't know/see what use case it's solving for, and it seems low value.

If we lean toward a spotlight effect, we could consider using that as the hover interaction as well? Something like this:

Adding spotlight during hover feels heavy. Would rather not use the spotlight mode than put it into hover. Also, the placement of the label container in what I shared was intentional. It follows same placement of select mode. I think we need to decide if the label container is outside the frame, or inside, not in between. We also need to solve for when a person hovers over the header template part or any block that's flush with the topbar. There was an exploration that bumped everything in the editor down, but we should not do that.

[noahtallen]

I really enjoy the border around the template part on hover. That said, once a user gets into "edit" mode, that would go away (right?). Should this hover/select mode be always turned on for things like the template part block?

E.g. I'm editing my header, but then mouse over the footer. the footer, being hovered, still shows a border and label even though we are not in select mode any longer

[noahtallen]

What is the use case for select mode? What value does it provide users? atm, I don't know/see what use case it's solving for, and it seems low value.

this can also describe "spotlight mode", since very often you aren't focusing on a single block, but a group of blocks at once 🤔 Why would I just want to focus one single paragraph of my essay, fox example.

[dubielzyk]

For now I intend on leaving the modes and other behavior as close to "as is" as possible while improve the Template Part visibility. (In the background I've been looking to potentially combine the modes and improve the block highlighting, but that's for another issue.)

Let's start with:

In _Select_ mode

In _Edit_ mode

_Notes_

• That basically means that the Template Part gets a more subtle highlight border as the child block is selected or editable. This is to highlight that when you're editing a block, you're also editing something that's bigger than just that block.
• We should have _Select mode_ active by default as users open the Editor

Here are some other explorations we should discuss and potentially prototype up to see how they feel:

Less intrusive selection label

Focus/Spotlight mode
If we want to make it more apparent we could add a scrim/overlay to the content outside the template part.

Template part notice
If we wanted to be even more explicit, we could add a notice telling users that changes will affect other sites.

There's a lot of different combinations here, so there's always the possibility to mix and match.

Also it'd be great if we could get a prototype/PR and tweak it as we go. I've prototyped a bunch but it's hard for me to emulate the editor properly. The approach was to start minimally and reuse as much as we can, then build from there. So if we find that things aren't clear enough, we can add to it.

Would love feedback and thoughts on this 😃

[noahtallen]

In "edit" mode, is any interaction shown when hovering over the header block? I feel like it could be confusing to not have that. Also, in "edit" mode, is the "focus" state for the template part block activated when clicking the block for the first time? I think typically, it by default focuses wherever you click rather than the parent block.

Also, I really like the "less intrusive label" and the notice about changes applying everywhere :)

I think the default of select mode makes a ton of sense in the site editor (which is more about layout than content), but I do worry that after the user starts editing things, it would be hard for them to get back into select mode. So I definitely look forward to seeing more iteration on that in the future too.

Great stuff, though!

[jeyip]

I started working on template part notice design # 2 today and saw a UX oddity when rendering notices alongside the template part name panel. It seems like information is duplicated for the user.

It looks like the preference might be to remove and relocate template part name functionality, as described here, and I wanted to call this out to keep everyone in the loop. @dubielzyk

[noahtallen]

Totally agree. Somehow the hover name and rename panel need to be combined to make things consistent and to avoid duplication

[dubielzyk]

Yeah. As mentioned above we should start with just the border hover and active states. Issue (#23871) kinda sorts the label situation already, but I didn't know when it'd be implemented so I made the label explorations as a backup. The idea was that the label would morph into the block toolbar, but for now, just remove the label :)

[Addison-Stavlo]

Thinking more about the notice options listed in - https://github.com/WordPress/gutenberg/issues/22064#issuecomment-667084051:

I think the preferred notice format would be the 1st, the snackbar style notice. Attaching notices to the bottom of the template part could be problematic as it may not be visible in a handful of circumstances. Consider scrolling down to start editing the first few blocks in a large footer, the user may leave the bottom of the footer still scrolled off the screen and the notices would never be seen. Similarly, if there are excessively long template parts that have height greater than that of the editor, it would not be likely that they would be scrolled down for the bottom to be visible to see the notice when they start making edits. This may also be the case for similar blocks like Post Content that may require similar notices. The snackbar style is also part of Gutenberg's notices package, and there would definitely be some benefits to use this package and improve on it with extra options where necessary.

[jeyip]

I think the preferred notice format would be the 1st, the snackbar style notice.

Consider scrolling down to start editing the first few blocks in a large footer, the user may leave the bottom of the footer still scrolled off the screen and the notices would never be seen.

It sounds like Jon had plans to integrate the notice into the block toolbar, which would address this problem.

The snackbar style is also part of Gutenberg's notices package, and there would definitely be some benefits to use this package and improve on it with extra options where necessary.

This makes sense to me 👍. I could see this being a big benefit depending on what the notice in the block toolbar looks like, especially in regards to a11y friendliness. I think the snack bar style notice would be a good start (I think some notification is better than no notification) which we could iterate on if desired.

[Addison-Stavlo]

It sounds like Jon had plans to integrate the notice into the block toolbar, which would address this problem.

Thats an interesting thought but Id have some concerns there as well (aside from being separate from the notices package). If we are putting the notice on the toolbar we will need the notice on the toolbar when a child block is selected, but perhaps some child blocks may require similar notices (like site-title or others whose changes persist across all instances) which would create a huge clutter or another entirely new notice interaction. Also with this comes concerns of available real-estate for the toolbar, especially for mobile views as well as when using the 'top toolbar' option.

[noahtallen]

great observations about the options for noticed, @Addison-Stavlo. I totally buy into your thoughts for the main text notice about changes applying broadly.

I think there is still an opportunity to show something near the template part that helps make it feel more... reusable, I guess. For example, these icons in some off Jon's designs were really interesting to me:

Just having that "reusable" icon in more places helped make me feel like the block was "different" than normal

Additionally, once the block toolbar goes away, there is no indication that this is the "header" we are editing (after moving the template part name into the block toolbar, anyways). I feel like there's also an opportunity to have that text always attached to the border, or something along those lines. (maybe even on hover.)

That feels different from the main notice, IMO, we aren't "notifying the user about something".

[Addison-Stavlo]

Just having that "reusable" icon in more places helped make me feel like the block was "different" than normal

True! That is an interesting idea. I wonder if the "reusable" icon could be confused with reusable blocks or anything else that may use it? But I think its a solid idea. Maybe it should be added to the beginning of the main text notice as well if it is fitting.

once the block toolbar goes away, there is no indication that this is the "header" we are editing

If we have a snackbar notice the name will be in there, although I agree it's a bit less apparent. Pinning it to the bottom of the template part seems good for a short header, it might feel a little odd pinned to the bottom of a footer as the last item on a page. And as noted above in various circumstances it will not be seen when the bottom of the template part is not in view, but if we have a snackbar text notice as well that edge case may not be a big deal?

[noahtallen]

it will not be seen when the bottom of the template part is not in view, but if we have a snackbar text notice as well that may not be a big deal?

Yeah, that would definitely be a challenge. I wonder if "top-right" would work as a location instead

[jeyip]

we will need the notice on the toolbar when a child block is selected

Also with this comes concerns of available real-estate for the toolbar, especially for mobile views as well as the 'top toolbar' option

These are great callouts. I totally agree. I wonder if @dubielzyk has any thoughts about these as well.

[dubielzyk]

It sounds like Jon had plans to integrate the notice into the block toolbar, which would address this problem.

My bad on the communication. I don't have any plans on integrating the notice in the block toolbar. I've tried and it doesn't work well. I agree with @Addison-Stavlo that if we go for a notice, the snackbar is the best alternative. Scales nicely. Though like I've said before, I don't think we should go that far just yet :)

As for the label and the reusable icon. We should not use the reusable icon itself, but it might be nice to have a _template part_ icon, or something to differentiate it like some of you've mentioned above. By having the icon in the label, it could also scale nicely up to the block toolbar (especially when the block name is in the toolbar also).

[Addison-Stavlo]

We should not use the reusable icon itself, but it might be nice to have a template part icon

I think it would be nice to settle on some specific icon that would go beyond the template part specifically and represent that altering the block will effect everywhere it is used and/or save changes to specific site data. That way it can be used not only for the template part, but post content, site title, site tagline, and other blocks where altering the data alters more than just the instance of the block. It would create a visual consistency that users could recognize and easily differentiate between these blocks and the standard ones.

[jeyip]

Current Priorities

After Noah, Addison, and I met yesterday, we settled on a few important features or design ideas that we can implement or explore further:

1. Investigate labeling and icon to identify which template part the user is focusing on. Consider exploring what it might look like on other blocks with similar behavior as well. (Site title, site description, etc.)

1. Create a production-ready PR for the focus and hover border on template part blocks. We feel like we can move forward on this because the borders exist in all proposed designs.

[dubielzyk]

Investigate labeling and icon to identify which template part the user is focusing on. Consider exploring what it might look like on other blocks with similar behavior as well. (Site title, site description, etc.)

I'd love to see how this could work on blocks too, but I recon we'll end up starting with template parts only since it'll be a bigger change to do this for blocks. Also makes less sense on blocks when the label will be in the Block toolbar at some point anyways (#23871)

Create a production-ready PR for the focus and hover border on template part blocks. We feel like we can move forward on this because the borders exist in all proposed designs.

Awesome. I'm currently getting set up to test locally, so I'll be able to test and give feedback as you make some fresh PRs 🍞 😃

[jeyip]

I'd love to see how this could work on blocks too, but I recon we'll end up starting with template parts only since it'll be a bigger change to do this for blocks.

Starting with template parts makes sense to me, especially given the context that we're trying to get consensus with the core community with smaller, iterative changes.

We bring up applying this to other blocks because Addison, Noah, and I were discussing another related problem earlier. It would be great, if we move forward with template part labeling, to find iconography that applies to both template parts and site blocks.

To explain more, modifying a header template part, for example, modifies all other instances of the template part throughout the site. The same can be said of site description and site title. A paragraph block, in contrast, _does not_ behave this way. (more info under the Current UI heading). We were playing around with the idea that the icon might be used to convey this distinct behavior of site blocks to the user.

Also makes less sense on blocks when the label will be in the Block toolbar at some point anyways

Would you mind elaborating on this point @dubielzyk ? I might be missing something, but #23871 seems to only refer to the template part block. Given that, it still seems like we may need a label because when a template part child is selected, the label in the block toolbar goes away.

[jeyip]

To explain more, modifying a header template part, for example, modifies all other instances of the template part throughout the site. The same can be said of site description and site title. A paragraph block, in contrast, does not behave this way. We were playing around with the idea that an icon might be used to convey this distinct behavior of site blocks to the user.

Expanding on this further, it seems like Wix's approach is to convey site block behavior through color. The site builder uses orange borders, background color, and text, to identify entity updates that will persist wherever the header is displayed. I think a shared site block icon would be easier to implement, but I wonder how feasible this is as an alternative?

Selecting the header

Selecting header children

Selecting site content

[dubielzyk]

Yeah, I recon we should experiment with putting the label in. It seems as though the bordered approach is too minimal and not explanatory enough. If we can prototype something up (using the above mock you referenced) we can have a play with it.

Would you mind elaborating on this point @dubielzyk ?

I was referring to if we showed a label on the block as well as the block toolbar, but this doesn't make sense. We would show a label on the template part, when a child block is selected.

[jeyip]

If we can prototype something up (using the above mock you referenced) we can have a play with it.

@dubielzyk I've created a prototype you can checkout here. Some notes:

• The icon is a placeholder until we can find a better one.
• The border color isn't as dark as in the mocks. This is because I matched the border color of the label to the border color of the template part.

[dubielzyk]

Added a comment there. The issue we have now is that we're getting two visually different labels which I don't like. We'll need to figure out a way to handle this as I ideally don't wanna create another pattern for this.

[dubielzyk]

Looks like the label and border is introducing more issues than it's solving. Can we try and create a PR with the spotlight mode instead? No label, border, or notice :) @noahshrader @jeyip @Addison-Stavlo Thoughts?

[Addison-Stavlo]

Can we try and create a PR with the spotlight mode instead? No label, border, or notice :)

Could you clarify the pictures and what you mean by spotlight mode here? Your picture on the left is the box shadow, and the picture on the right is the opacity reduction as enabled by spotlight mode. Do we want both of those to happen at the same time? We did try this previously and I thought the argument was that it was too 'heavy handed'.

[dubielzyk]

Apologies. In both versions I've used a scrim/overlay on top of the content. Left one uses dark, right one uses light. You can achieve a similar result to the white by reducing the opacity like you mention. So there's technically three solutions:

• Dark scrim over inactive content
• Light scrim over inactive content
• Reduced opacity of the inactive content

I assume that todays Spotlight mode works by reducing the content (?). If it's easy to code the three scenarios up, we could try them out and figure out which work best. I personally prefer the dark scrim, but I'm assuming that it might make more sense to use Spotlight mode since that's something we already have in place. Does that make sense? :)

I made a prototype of the dark and light scrim, but this is one of those things where it's better to make a decision when you can test it in the product :)

[noahtallen]

I assume that todays Spotlight mode works by reducing the content

Yeah, it sets the opacity to 0.5 for all blocks which are not selected, making the selected one stand out :)

[Addison-Stavlo]

In both versions I've used a scrim/overlay on top of the content. Left one uses dark, right one uses light.

Ah, thanks for clarifying. When I mentioned trying 'both' before, that was dark scrim + opacity content reduction (using a non-sustainable 'hack' on spotlight mode for testing):

I'm assuming that it might make more sense to use Spotlight mode since that's something we already have in place.

Not necessarily. Although it does apply an opacity reduction, spotlight mode is designed to work in a different way across blocks. So if we really wanted to use it here, we would basically have to re-implement it and probably remove the standard spotlight mode from the site editor as it would conflict in behavior.

I personally prefer the dark scrim

I agree the scrim highlights the area best, is a bit more simple in theory, wouldn't conflict with spotlight mode, and could work well if done right. But I think we need to think beyond 'dark' and 'light' scrim. The visual effect the scrim has on the content depends on the background and font colors in the editor. Just trying 'color A' and 'color B' against the standard white background will only give us an idea of how they work on a white background. But then if the themes background is gray, tan, black, etc., with different font colors it will not have the same effect.

If we really want to use a scrim, I suggest we come up with a way to determine the color as a static setting will not work well across variety. The scrim that is applied's color could to depend on the background color, could be the same as the default font color (as the dark scrim in your example), or perhaps the same as the background color (as the light scrim in your example). If we have a couple ideas of how the RGB values should map from the font/background to the scrim, we could try those across multiple backgrounds/themes to see what works the best. This would be a neat exploration!

However, with all that said, that might be a bit to jump into considering there was still a bit of debate concerning whether or not applying these types of backgrounds is too heavy handed (as noted by @jameskoster here - https://github.com/WordPress/gutenberg/pull/24557#issuecomment-681849420 - as well as others elsewhere). Similarly, discussions regarding the need for visible indicators (such as the label) seem to be advised to be 'on hold' until the persistent block navigator is in place and its effectiveness can be determined alongside the other tools in the editor.

[shaunandrews]

The visual effect the scrim has on the content depends on the background and font colors in the editor.

This is the main reason I keep referring back to the existing Spotlight mode, which reduces the opacity of elements, rather than a scrim.

[dubielzyk]

Really good point @Addison-Stavlo and yeah, what @shaunandrews is saying makes sense. Spotlight mode will work for all colors and also not clash with the current Spotlight mode, so let's try that out 😊

[Addison-Stavlo]

Spotlight mode will work for all colors and also not clash with the current Spotlight mode

I mean, it will "not clash" if we take the current mode out of the site editor.. which it sounds like we might be ok with? 🤔

I will say the scrim does have the benefit of better highlighting the template part's area (which I do like), while the opacity reduction on its own is a bit more 'fuzzy'. That is, its clear by the reduced opacity that a block is not part of the template part, but is not clear where certain things may take effect such as changing the background color in or around the template part, etc.

[dubielzyk]

I mean, it will "not clash" if we take the current mode out of the site editor.. which it sounds like we might be ok with? 🤔

I'm not sure if we should mess with the current Spotlight mode for now. What benefit do we get from removing it from the site editor? I don't have enough context to make a decision in removing it personally.

while the opacity reduction on its own is a bit more 'fuzzy'.

100%. I personally prefer the dark scrim for this reason too, but I think there's a few others who think it's heavy-handed. Would love to get @shaunandrews @jameskoster @MichaelArestad @olaolusoga thoughts on which of the spotlight modes you prefer. Dark scrim or light scrim/spotlight mode?

[jameskoster]

If we've decided to go with a spotlight-esque execution then I think the existing spotlight mode effect of reducing the unfocussed blocks opacity seems to be the most flexible - as @shaunandrews mentioned above. It is the most sympathetic approach considering the rainbow of colors that might exist on the canvas.

We _could_ do something like use the background_color theme_mod for the scrim color as @Addison-Stavlo touched on, but I think that's going to essentially end up in the same place as using opacity on the blocks themselves.

One concern for me is that if we implement the spotlight-mode effect here, might the purpose of this feature (highlighting a template part) be easily missed by those who already have spotlight mode enabled? What affordances can we make to ensure the effect is just as clear regardless of whether you have spotlight mode enabled or not?

I can't help but wonder if there are still unexplored design patterns we might employ here 🤔

[jameskoster]

I can't help but wonder if there are still unexplored design patterns we might employ here 🤔

How about something like #25085

[olaolusoga]

Can we start with spotlight for now, and improve over time? If we begin with spotlight, we'll then need to respond to any issues that come up as we use (good thing).

Also using spotlight seems to be a recurring theme (see comment here from Jul ). If we polled, sentiment would be in favor of spotlight first, and then iterating over time.

How about something like #25085

That looks good—the spotlight mode usage. Left some feedback .

[Addison-Stavlo]

Also using spotlight seems to be a recurring theme

Yes, however with every time it is proposed this conflict is raised:

One concern for me is that if we implement the spotlight-mode effect here, might the purpose of this feature (highlighting a template part) be easily missed by those who already have spotlight mode enabled? What affordances can we make to ensure the effect is just as clear regardless of whether you have spotlight mode enabled or not?

Using the spotlight effect will not play nice with spotlight. There is already 'spotlight mode' so using its visual effect to highlight template parts will conflict unless there is a consensus that we can remove the mode setting altogether.

[jameskoster]

Yeah I think the breadcrumb template indicator in the top bar would be a requirement for total clarity when spotlight mode is enabled. But if implemented as per @shaunandrews' design, I think we could close this issue? :)

[olaolusoga]

@Addison-Stavlo brings up a good point. We need to address the dynamic when spotlight mode is active and inactive. If inactive, using spotlight feels in conflict with the setting, and vise versa.

[noahtallen]

if implemented as per @shaunandrews' design, I think we could close this issue

I think there are some other aspects here that are still difficult to work with. For example, how do you know where the template part begins and ends? There would be no indication of this while editing other than directly clicking every block to figure out the first one which is under a different parent.

I actually think some of my thoughts in this comment could be helpful. TLDR is that we could rework the block inserter that shows up "at the end of the current block container" to also indicate more clearly where the end of the container lies.

Additionally, we don't plan to revisit spotlight mode at this time, nor borders/labels/etc, since we are mostly blocked by discussion. I'm beyond happy to see discussions and design prototypes continuing in issues like this, though! I really think we need to continue iterating to grow consensus before we continue coding.

FSE is a tough concept. Unless our users have a good grasp on how it technically works, I worry that they will be thoroughly confused by our current and even upcoming UX. (And we already know that people including ourselves are completely confused by the current UX.) Most people won't have that sort of technical grasp without a lot of research and education. I'm really not seeing us make strides towards UX which is easier for new users to understand. I think we are erring towards _not_ showing information with the goal of a less-cluttered interface. My personal opinion is that we should be showing more information so that folks understand what they are working with. That was the motivation for things like the border, label, spotlight mode, and other experiments. :)

At any rate, @Addison-Stavlo, @jeyip, and myself will start looking into the document settings in the top toolbar (#20877). We'll also look into @shaunandrews' design in #25085. Our hope is that these changes (along with the possible persistent block navigation sidebar) could help clarify some aspects of template part usage. As a result, we'll still be making progress on this issue even though we'll be focusing on other things.

[paaljoachim]

There are a lot of great ideas here! It would be great to create a PR with a MVP and get it out into the wild for testing and feedback. As it would make it possible for a broader range of people to test it out.

Is it possible to create a kind of gutenberg.run where one tests out multiple draft PR's to gather feedback?

Kinda like a prototype car. One can probably drive it and in general test it and it might or might not get into the general production. Having a kind of gutenberg.run to test out multiple features being built would be very helpful and make it easier for additional people to test out the draft features that will likely in one way make itself into the general Gutenberg plugin.

[noahtallen]

_Note: when I say we, I mean myself, @Addison-Stavlo, and @jeyip. We are working together as a squad. :)_

@paaljoachim we've created multiple PRs to test these ideas over the past several weeks :)

• https://github.com/WordPress/gutenberg/pull/24394
• https://github.com/WordPress/gutenberg/pull/24557
• https://github.com/WordPress/gutenberg/pull/24498

This PR combined several of the ideas into one "prototype car," as you say: https://github.com/WordPress/gutenberg/pull/23406

A lot of folks gave feedback on those prototypes, and we weren't able to get enough consensus to move forward with most of the propositions. So we're going to look at the document settings in header proposal in hopes that:

1. The document settings in header can help address this problem
2. More people discuss and propose designs and more options for fixing this problem
3. Other things (like the persistent block navigation proposal) also contribute towards fixing teh problem

[jameskoster]

For example, how do you know where the template part begins and ends?

To illustrate the boundaries of the template part, it looks like a spotlight effect is employed when blocks inside are focussed.

[dubielzyk]

Sounds like we're more in agreement that spotlight mode is a better solution to this problem. I agree with @noahtallen that it's still not 100% clear where the boundaries of the template part begin/end. Is it possible to get a PR with what we've discussed above? That way we could all have a play with it and hopefully reach a conclusion?

[noahtallen]

A rough spotlight mode version was implemented in #23406 which theoretically still works :) So I think you could use that to play with it. "proper" support for this interaction would take a lot longer, and we're shifting to a different project so I don't think we can commit to that right now. I'm not convinced we'll be able to reach consensus on a spotlight mode solution at this point, especially since other improvements (like the document settings in the header) aren't in place yet. So it would be tough to see how it fits in.

But obviously, if anyone wants to pick this up, go for it!

[vindl]

I think this issue can now be closed given that spotlight mode (https://github.com/WordPress/gutenberg/pull/25656) for template parts and document settings subtext have been merged (https://github.com/WordPress/gutenberg/pull/25544).