Reusable blocks and Template parts – try a click-through-to-edit-children UX pattern

[jameskoster]

Recently there has been some chatter around the impracticality of selecting and working with container blocks and their children.

Even with the additional outline effects we added in the Site Editor, selecting a container block sometimes requires too much cursor precision and feels finicky (technical term :D). In some situations it is outright impossible... in the gif below I fight valiantly to select the Columns block inside the Header Template Part in tt1-blocks, before giving up and having to use the parent selector on one of the single Column blocks:

Click through to edit

In #27852 (comment) I explored a potential solution to this problem for Template Parts that involves the user having to click "through" the container to select the children. Similar to how selecting child blocks in "Select" mode works, or how you might select the contents of a "group" in software like Sketch or Figma.

I'm wondering if we might instead implement a reduced version of the above to Reusable Blocks first, since they are a slightly simpler prospect compared with Template Parts.

To kick things off, here's a video detailing how this pattern could work:

Select.a.reusable.block.mp4

• The Reusable Block has a different color treatment to indicate the block type.
  • On hover there is a green outline.
  • An overlay also appears subtly obscuring the contents and suggesting the user must take additional action to edit them.
  • When selected the icon in the Toolbar is also green.
• Regardless of where I click on the container block, the parent is always selected.
• A single click on a child of the selected container block will select it, and from this moment the parent is "unlocked" so that you can select sibling blocks with a single click as normal.
• The "rest" of the canvas is faded out slightly behind an overlay. Clicking that exits the "edit state" of the Reusable Block.

There is a figma prototype here that you can play with yourself to try this out.

Color

Once the user understands the relationship between the color and the block type, the overall UX is improved as upon hover it becomes clear that a simple double-click behaviour can be used to select the child block:

This relationship can of course be extended to template parts, where the same overall pattern can be employed with a different color to indicate the different block type. Likewise other UI elements can also utilise these colors to increase block-type clarity:

Since the purpose of these colors go beyond decoration, they should probably persist between color scheme updates. That way a user will always understand what is a Reusable Block and what is a Template Part even if they change their preferences.

I'm using green for Reusable Blocks in the demonstrations above, but that is not prescriptive. The actual colors we use warrant further investigation, especially if we intend to use them in other applications like List View, the Toolbar, or the Inspector. cc @jasmussen

Less is more

It is worth outlining that this should feel like a very subtle layer of friction, and that:

• All editing is still contained within a single editor.
• Dragging blocks in and out of a Reusable Block should still work.
• Navigating with keyboard should still work.
• List views should always show all contents and all areas.
• Copy and paste from and into should work.
• “Move to” should work.

Wrapping up

I am sure there are many other considerations...

• Should this pattern should cascade down the tree when a Template Part contains a Reusable Block?
• Should the overlay only appear on selection, or hover and selection?
• Are the overlays effective, or overkill? Perhaps outlines alone are adequate...
• Should all parent / child blocks behave this way (not just Template Parts and Reusables)? If so, should we add a hotkey that enables selection of the lowest child in the tree with a single click?

To begin with I think it would be interesting to put a try branch together to explore this in the simplest way possible.

Let's discuss.

[mtias]

Great exploration. I think we should try the full overlay on hover / focus. What I think is excessive is the fading the rest of the canvas once you click through. I'd rather use the proper isolated-mode for that behaviour (an editor that only has the reusable block / template part).

[jameskoster]

Makes sense. I updated the prototype to remove the canvas overlay on the click-through state.

[paaljoachim]

A click through in relation to a reusable block is a good way to go.

In relation to a reusable block. One adds an instance to a page and upon clicking one of the inner blocks is selected. A reusable block needs to be harder to edit. So for a reusable block upon clicking/selecting the first click should be the parent. Then one further clicks to go into to edit one of the inner blocks.

Side track--
As it is too easy to go into a reusable block and make a mistake and have that mistake show up as a dot in the publish button. One might not have noticed one had made a mistake inside the reusable block before later on. Publishing the post and not having an opportunity to back track the save made inside the reusable block is pretty tricky.
Side track end.

Clicking a block is a pretty regular thing. But for a reusable block we should instead have the click once to select and then click again to select one of the inner blocks. --> Let's keep it subtile as in no overlay and no change of color. Keep things as every day as possible. One is just clicking a block but this kind of block does it just a little differently.

It would be nice for the first iteration to just include the click-through-to-edit-children UX pattern with no color changes.
Then if we feel it is needed for the second iteration add some subtile color effects.

[jameskoster]

@paaljoachim without the color change (or the overlay) there is nothing to visually signify that the reusable block is different to any other. If it looks the same but behaves differently couldn't that be very confusing?

[paaljoachim]

A subtile way would be to change the boundary color of a reusable block.

Original blue boundary line.

A suggested green boundary line.

It keeps the same behavior as one is used to, but uses another color for the boundary color.
It does not add an effect not seen anywhere else. It just makes a small change to the existing user interface to reflect that this is another kind of block.

[jameskoster]

It should be easy to try with and without the overlay to see what feels best 🙂

[ridesirat]

I think a more dramatic change would help understandability. A subtle change in color doesn't feel enough - and we have to think of users with low color range.
I think a dashed line would help distinguish them.

[jameskoster]

I think that's something we can also try quickly once we have a PR up and running 👍

[critterverse]

Picking up where @jameskoster left off, I made some small additions to this flow. This version includes the ability to edit the Reusable block in an isolated editing view, which mirrors Template Part editing:

• Navigate to the isolated view via the ellipses menu in the Reusable block toolbar → Edit Reusable block
• The Publish button in top toolbar becomes Save while in the isolated view

This version also reflects recent changes to show inner child blocks toolbars with a parent selector.

overlay.mov

Here’s an updated Figma prototype which includes the isolated view.

[jameskoster]

Yay! I think the trickiest thing to get right here is the positioning of the reusable block in isolated editing view. I understand why you've "locked" it in position, but I wonder how that will behave in practical terms.

What if the reusable block is only half in view when I enter isolated editing? Does the window "snap" in to position? 🤔 Likewise if the reusable block occupies more vertical space than is available on the canvas, how does scrolling work then? What about a combination of those two things? 😅

FWIW I don't think it would be the end of the world if we were to simply position it right in the middle of the canvas.

[critterverse]

Thanks for raising these points @jameskoster! This made me realize a couple of things about the isolated view, re: both the position and width of the Reusable block being edited.

Position:

What if the reusable block is only half in view when I enter isolated editing?
if the reusable block occupies more vertical space than is available on the canvas, how does scrolling work then?

Centering the isolated block makes a lot of sense for these reasons. Here's an updated Figma prototype with a long RB that goes past the fold on the page. In this version, you can scroll within the isolated view to see the full length of the block.

isolated.mov

Width:

Also realized that the narrow width of the Reusable block in this particular layout would most likely come from the Reusable block being placed within a Column block, so I've made the inner contents of the Reusable block 100% of the main column width within the isolated view. Wanted to make sure this kind of transition wasn't jarring/confusing but feels ok to me!

[ridesirat]

Sorry, I'm having difficulty to keep up with these. I have these notes here for a while. I think it's best if I post them now and you filter what is useful or not. Maybe it's more efficient then me trying to analyze all the thread and miss some important point.
I use some Visual Builders and here is my feedback on what I think works & not:

Should the overlay only appear on selection, or hover and selection?
Are the overlays effective, or overkill? Perhaps outlines alone are adequate...

Hover is always nice to have but it has to be super subtle. I think a outline is less tiring and more precise then a overlay.

Should all parent / child blocks behave this way (not just Template Parts and Reusables)? If so, should we add a hotkey that enables selection of the lowest child in the tree with a single click?

Selecting children is one of the most frustrating experiences there can be. Clicking trough all the tree is not good at all. We should always look at things with extreme exemples. What if there are 10 children? More?
I think a "Local level" breadcrumb could be nice. Or a "Local level tree". From the selected block to it's children. And where you can select them.
It could be overlayed on top of the selected block (top: 0, left: 0) and if selected outside it closes, if any child block is selected, it goes to that one - ready to edit, not with the selected Local overlay open, of course.
Selecting parents would be outside the "Local" one, since it's easier.
All the best!

[jameskoster]

Hopefully the persistent list view will help with selecting further down the tree.

If not, I personally find the command modifier in Figma works very well:

modifier.mp4

[Addison-Stavlo]

Testing this idea out on a PR - #30156

[annezazu]

As this continues to be explored, I wanted to bring in some feedback from the third call for testing for the FSE Outreach Program:

The overlap between template parts and reusable blocks might cause users to have trouble differentiating them.

While making these patterns to edit similar between the two makes sense, it might also inadvertently increase confusion around when to use each (template parts carry semantic meaning vs reusable blocks which should exist alongside regular blocks). Something to keep in mind as things move forward!

[Copons]

Closing as fixed by #31109 ✨

[annezazu]

Did this implementation change at all since this was merged? Asking as this feedback came in as part of the twelfth call for testing for the FSE Outreach Program:

Clicking Header or any template section is somewhat difficult, as it easily selects blocks inside of it.

Here's a video of the current experience with WordPress 5.9.1 and Gutenberg 12.7.1. I expect that I would need to click through to edit the Header and that, at first, it would select the overall Header template part rather than the inner blocks within:

template.part.ux.mov

Happy to open an issue but wanted to see if the folks part of the initial implementation knew if anything had intentionally changed before I did so

cc @Addison-Stavlo @Copons

[annezazu]

Apologies -- I just found this issue that covers this exact use case 🤦🏼 #35079 Connecting these so no one else makes the same mistake (I couldn't find it despite everything I was searching).