Pattern Editing and contentOnly interactivity

[mtias]

Note

Expanding on #60021

Over the past couple years we’ve been iterating on a series of related systems with the hope of arriving at a more streamlined editing experience of composite blocks and design patterns.

The block editor began as a writing tool and evolved around blocks as the basic compositional primitive. When it comes to page building, this is a design system optimized for flexibility at the expense of broader usability. The block editor’s nested block architecture enables beautiful, complex layouts. But that same architecture can make simple editing complex for regular users.

Through iterations on the pattern mechanics we have been building towards a complementary model in which multiple blocks can be subsumed by these higher level abstractions—offering at the same time predefined layouts, easier editing, and preserving the integrity of designs.

To achieve that we cannot take shortcuts as we need to checkmark the following requirements:

• Patterns are not custom blocks, they don't have custom functionality, but are always made out of simpler and more basic blocks.
• Basic editing needs to be restricted to certain attributes (role: content), achieving separation of content and design.
• They need to support theme.json structures to govern the local look and allow for a degree of style expression.
• Interacting with them should feel closer to interacting with a single block from a UX perspective while still leveraging all the block tree affordances.

The process to get there also allowed us to reconcile and share the basic mechanics between three important initiatives:

• Patterns as design sections for page building, including zoom-out.
• Transformations between patterns.
• Data bindings to connect to external data sources and meta fields.
• Partially synced patterns to allow reusing a design and layout with different content.

All these work by relying on the same basic mechanisms, which is that blocks that compose patterns expose content attributes for editing and retain other attributes locked.

Improving contentOnly

Now a last piece that remains to be improved is the simplification of the interaction layer. Both contentOnly and partially synced patterns expose its building blocks as a selection list in the sidebar.

This is a crude first version that only allows selecting the individual blocks that make a pattern. The proposal here is to expand this presentation and expose the editable fields coming from the content role of the blocks contained in the pattern directly in the inspector:

This would allow the pattern to feel even more like a single object with a series of attributes (that happen to be blocks).

• Inspector split between “content” and “styles”. No “settings”.
• Styles should render the visual style cards we use in global styles, not the buttons.
• In Content, all blocks are listed with its role “content” attributes present as fields.
• We show block icon and block name.
• When we have more than one editable attribute (like alt text or captions on images) we collapse into an item group with a flyout menu or drilldown.
• Text fields should be rich text powered but not show toolbars (shortcuts like command+b should still work).
• Content blocks that are also wrappers (List, Quote, Gallery) could also be presented as a single item and open in a flyout or drilldown. Maybe we need some heuristics on number of children there.
• Bonus: we could include toggles to hide a block from a pattern like we do with block hooks, maybe only on hover or behind an ellipsis menu to not pollute too much. This would allow users to slightly customize how things look but with easy access to restore.

Use contentOnly as the default editing mode for patterns

Instead of introducing Write/Design modes (#71340), or perhaps complementary to it, we could then make pattern editing default to contentOnly always. This would afford the simpler editing experience that we know is needed, without adding more complexity or modes to switch between—it’s just a function of a pattern.

To fully edit the contents of a pattern permanently the user would "detach" it, essentially exposing all its building blocks normally. If editing the content globally they would edit the pattern in isolation like it happens today.

More designs

[talldan]

Thanks for writing up this issue @mtias. I have some questions:

The proposal here is to expand this presentation and expose the editable fields coming from the content role of the blocks contained in the pattern directly in the inspector

Is your feeling that the canvas remains interactive at the same time as being able to edit in the inspector?

I'd also love to know if the Template Part block is being considered as part of these changes?

When we have more than one editable attribute (like alt text or captions on images) we collapse into an item group with a flyout menu or drilldown.

The existing ToolsPanel UI could be a good fit. It's still not the perfect experience, but it's the closest fit I think we have if we want to re-use (and possibly improve) existing parts.

Content blocks that are also wrappers (List, Quote, Gallery) could also be presented as a single item and open in a flyout or drilldown. Maybe we need some heuristics on number of children there.

This feels like the most unclear part to me. List is difficult to represent in the inspector because of the nesting of list items. Quote also allows quite a wide range of inner blocks. We've tried a few things in the past but nothing has worked. How it works in trunk right now is the closest we've come, but if we're switching to editing in the inspector that creates a range of new problems to solve.

To fully edit the contents of a pattern permanently the user would "detach" it, essentially exposing all its building blocks normally.

Detaching is usually a one-way street, should the user be able to go back to the contentOnly mode after making changes?

[ramonjd]

Instead of introducing Write/Design modes (#71340), or perhaps complementary to it, we could then make pattern editing default to contentOnly always.

Would contentOnly mode for patterns/templates/nav block make the Write/Design modes switcher redundant? Given Write/Design is still behind an experimental flag, it doesn't need to be activated for the patterns/content only feature to work, right?

[mtias]

Is your feeling that the canvas remains interactive at the same time as being able to edit in the inspector?

Yes!

I'd also love to know if the Template Part block is being considered as part of these changes?

Totally. The experience of editing the Header should feel similar to editing a patterns, and it's part of why we are doing the contentOnly navigation block work (exposing the nav block at the top level of a template part):

• Template parts should follow the Synced Pattern interaction model #65698
• Expose "block hooks" at the section level #65676
• Navigation Block: develop a content-only representation #65699

One difference is the "synced" status, which means "edit original" takes a slightly different approach in normal patterns and template parts, with the former being the "detach" / "edit content" and in template parts it's the "edit" that takes you to focused mode.

The existing ToolsPanel UI could be a good fit. It's still not the perfect experience, but it's the closest fit I think we have if we want to re-use (and possibly improve) existing parts.

Yes, I think we can start there and see how it scales.

List is difficult to represent in the inspector because of the nesting of list items.

Generally, I think if it becomes complex we can defer to canvas editing. Most lists in patterns are not going to have nesting, they are just outlining things like "top three features". Same with Quotes—in almost all the cases with patterns they just have a single paragraph and sometimes a source. That'd be easy to represent as fields. If a quote happens to have more blocks we could just collapse it into a single item and defer to canvas editing.

Detaching is usually a one-way street, should the user be able to go back to the contentOnly mode after making changes?

You "create a pattern" to do that, I'd say.

Would contentOnly mode for patterns/templates/nav block make the Write/Design modes switcher redundant?

Possibly, depends on how well this idea works in practice. Modes are a good instrument to model interactions that we need, encapsulating a lot of code without disturbing the base experience, but then as we find where to attach them in more intuitive ways it's usually better to get rid of modes altogether.

[ramonjd]

Possibly, depends on how well this idea works in practice. Modes are a good instrument to model interactions that we need, encapsulating a lot of code without disturbing the base experience, but then as we find where to attach them in more intuitive ways it's usually better to get rid of modes altogether.

Thanks for the reply! What I'm understanding is:

• If Patterns+ contentOnly overlaps and covers similar or the same UX scenarios as the Write/Design switcher then it's a case for redundancy. We'd probably need concrete examples where the switcher would still be needed even with Patterns + contentOnly by default to decide.
• Users still need a mechanism toggle between editing content and adjusting layout regardless