Design idea: Pattern editing and contentOnly interactivity

[fcoveram]

Note

Expanding on #71517

@jasmussen and I took a deep look at the work done for this project, the overall approach to each feature, and how those features integrate into the overall experience. We identified and discussed several points that could improve the understanding and usage of the features. Below are the main pain points and a proposal to enhance the ongoing implementation.

Heuristic concerns

There are three areas in the heuristic that I think jeopardize the user experience with the Editor and make the UI unnecessarily complicated by not leveraging existing concepts and patterns. My concern is that this creates a more difficult path to undo because it places affordances in UI areas that confuse their purpose, and therefore, anticipate where controls are. The three areas are:

• Entity navigation: When editing a pattern in context, the way to enter and exit the entity introduces a new navigation experience (Patterns: in the sidebar, standardize representation of edit controls across blocks and patterns #71557 Pattern: patterns in content only mode need a way to be "unlocked" or "detached" #71558). This pattern competes with the current document bar in the header as it's not clear the entity user is editing. Placing the in and out toggle in the block panel feels insufficient to convey what the user is editing. If we aim for a single navigation structure, this can be easily used in focus mode when editing a pattern in isolation.
• Block navigation: The editable fields version introduces another navigation experience, but now to enter and leave child blocks (concept in ContentOnly Patterns experiment: Add content only inspector fields #71730 interaction in Patterns editable fields: replace toolspanel and drilldown menus with flyouts #73274). This navigation tree affordance already exists in the ListView by displaying one or more levels at once, so it doesn't require the user to relearn it. Similar to the previous point, this double navigation makes the block panel more complex by adding a new way of interaction. This might not scale well and in deep inserted blocks, I envision several drilldowns and clicks to go back.
• Content edit affordances: Having editable fields in the inspector (in Content Only Pattern experiment: Split inspector controls into tabs for patterns #71626) opens a new path for adding controls that modify content, which is primarily done in the Editor's canvas. This interaction diverges from the WYSWYG approach and pulls in an abstraction level that better suits the admin and the data-managing layer of content modification. In the Editor, the block panel controls the selected block capabilities, and expanding it to modify other blocks adds extra ingredients. Another potential risk of the same path is expanding the editing capabilities (like inserting links, Patterns editable rich text fields: ensure Cmd/Ctrl-K shortcut works to insert links #73270) that then will require more controls. I envision an input field in the panel with style controls inside.
• Blocks visibility: If editing a pattern dims out the unrelated blocks in the Canvas, then it’s not clear why those blocks disappear in the ListView (Patterns: obscure pattern internals in the list view when a pattern is in content only mode #72019). This 1:1 relationship is fundamental for connecting both UI areas and providing different edition levels. The interaction could also frustrate users by altering the layout, repositioning visible blocks, and missing the target area, especially when the ListView hosts many full-content and content-only blocks.

Improvement areas

On the other hand, two areas are working great and can evolve even more to polish the experience.

1. A single editor: In this idea shared a few days ago, I’m mainly proposing to reinforce the context of which entity the user is editing by reusing the existing structure of Editor’s UI. Instead of adding actions and patterns in the right panel, the Editor remains the same but adapts to both “inserted” and “focus" contexts.
2. Improve spotting block capabilities: Similarly to recognizing blocked blocks, the ListView could convey more quickly which blocks are content only and which have all the features to tweak. That should prevent possible frustrations when realizing that some blocks have more editing capabilities than others. And reinforcing the visual identity of entities, anticipating the tools is a matter of muscle memory.**

Design proposal

When considering paths that simplify the editing experience, I strongly believe it’s essential to reuse existing patterns as much as possible and avoid introducing new ones that disrupt the purpose of the Editor’s areas. Before listing the proposed changes, the following two recordings highlight a few interactions.

editing.nonsync.pattern.mp4

editing.sync.and.detach.mp4

The attributes in the proposals above are:

• ListView shows the entity icon to convey edition capabilities.
• Block toolbar shows the pattern name to convey entity type and its capabilities.
• Editable blocks are actions in the block panel that select the block in both ListView and Canvas.
• Editing a pattern updates the Editor’s header to communicate the content type where the user is at.
• When editing a pattern, ListView updates to reflect the block tree.
• When editing a pattern while a child block is selected, ListView updates the block tree while keeping the block selected.
• Header’s back action is the exit point to return to the previous context.
• When a child block with editable content is selected, the user can insert more of the same block.
• When detaching a pattern, ListView updates the block type to reflect edition capabilities.

Content panel

Most ideas explored long ago suggest the need for a new abstraction layer where editing content is separated from the block-selection-and-editing experience. In the designs iterated, there is significant value in consolidating all content controls on a single surface that adapts to any of the wp-admin contexts, but our current approach to this editing level mixes interaction patterns from different areas, which undermines the existing heuristics.

With a new UI area dedicated to this abstraction level, it would be possible to make content adjustments via DataForm both in the data management approach of the Admin and at the block level that Editor offers; similar to how the inspector panel functions in QuickEdit.

The recording below is very simple, but it shows some key interactions.

Site editor	Block editor

new.content.panel.mp4

---

What do you think of this @WordPress/gutenberg-design ?

[getdave]

Thank you for the proposal. I’ve read through it several times to make sure I’m understanding it correctly.

Understanding of the Proposal

From what I can tell, the key idea is to introduce a document-wide Content panel.

This would provide a top-level view of all editable content in the document, with a panel for each “Section” (pattern) exposing its fields.

Also, if I’m interpreting this correctly, that would also replace the existing pattern-level contentOnly controls currently shown in the experiment.

Where I'm confused

Where I’m struggling a little is understanding the underlying rationale for moving to this model. You mentioned:

…there is significant value in consolidating all content controls on a single surface

I can see where the idea is coming from, but I wasn’t able to clearly understand the specific user value this approach is intended to address, so I’d appreciate a bit more detail.

Has the current pattern-level contentOnly approach been tested and shown to be problematic, or is this more of a forward-looking architectural change?

I’m also curious what benefits the top-level panel provides for users beyond the synergy with ongoing DataForm work. For example, what does this approach enable that the existing pattern-scoped controls cannot?

Please forgive me if I’ve missed something here – I may well be lacking context – and I’d really appreciate understanding the motivation in a bit more depth.

UX patterns

I also had a question around this point:

…our current approach to this editing level mixes interaction patterns from different areas, which undermines the existing heuristics.

The current approach treats patterns as the primary unit of content, which is why the controls live at the pattern level and why the List View plays such a key role in identifying editable sections. This has been a guiding principle throughout this work as it has been identified that users tend to find it easier to work with predefined "sections" of content, rather than having to manage things at levels of abstraction that are either too high (e.g. a UI containing lots of form fields) or too low level (e.g. individual blocks).

You’ve identified that certain flows may need normalising – such as entering and exiting pattern editing – which I agree is sensible. However, I wasn’t fully clear on how these interactions undermine the broader heuristics and necessitate moving away from the Pattern/Section-centric model.

Is there a deeper rationale here that could help clarify the direction?

Visualising more complex examples

One consideration: when we visualise contentOnly interactions, we often use the simplest patterns.

I wonder if it might help to start instead from the more complex cases – for example patterns containing deeply nested blocks (lists) or highly structured elements (like Navigation).

If a model holds up under those conditions, we can feel more confident that it scales. I appreciate this is an early proposal, but not addressing these cases upfront might create challenges for engineers later in the release cycle.

DataForm + wp-admin benefits?

Finally, regarding:

...it would be possible to make content adjustments via DataForm both in the data management approach of the Admin and at the block level that the Editor offers

It sounds like this might be a core motivation behind the proposal. Could you elaborate a little on why enabling this kind of admin-style editing inside the Editor would benefit end-users?

I’m particularly interested in understanding how this compares with editing directly in the canvas, which is generally where users expect to interact with content.

Thank you again for sharing this and for helping me to build a fuller picture so I can better understand the intent behind the design direction.

[fcoveram]

Thanks for sharing your thoughts @getdave

The proposal is composed of three main ideas

1. When editing a pattern or template part, keep the blocks that belong to the document user is coming from in the ListView panel.
2. When editing a pattern or template part, use the Editor’s header and faded blocks in ListView panel as exit points to go back to the previous document.
3. Update the use of icons in patterns. symbol for not synced, and syncedFilled for synced.
4. Provocative idea: Move the content controls currently in the Block inspector to a new Content panel.

Regarding the Content panel, you understood it correctly.

The idea of having a separate panel is to address my concern with the complexity that Block inspector is taking so far. Adding a navigation pattern to dive into child blocks doesn’t seem to scale well. This concern doesn’t come from insights obtained from user tests, but conclusions after revisiting the heuristics we’re following in each of the Editor’s UI parts.

Another significant benefit I see here, and if I understand your question correctly, is that the panel can scale effectively by being reused in the Admin as another layer of abstraction. The current wp-admin has two levels of editing: document and block, but I see an implicit suggestion in #71517 to provide a control that falls between these two. The current document level offers a quick-edit approach that surfaces relevant data for users to tweak, but the document lacks this block-agnostic instance. By introducing that tweak level within the Block inspector, the design starts to require interaction patterns that already exist in ListView (browsing and controlling blocks in the tree) and content controls that are affordable in the Canvas (rich text modification).

In the image below, the left designs are current WIP implementations. The panel has two navigation patterns: one in the block info and one to dive into child blocks (Menu block). With a content panel, all fields are flattened in a single level per panel.

To expand the same idea, if you’re editing a Template document that has deep editable blocks from patterns and template parts, the outcome should look like this.

To your points in the DataForm + wp-admin benefits, not sure if my point above responds to your question

I’m particularly interested in understanding how this compares with editing directly in the canvas, which is generally where users expect to interact with content.

I share this entirely. And because of that, gathering all block controls into a single area suggests we’re aiming for an abstraction-editing approach that spans the whole document.

I hope the above helps to clarify.

[robmcclel]

If you just remove ContentOnly and let users edit what they want, directly in the block editor like any other content, this entire problem goes away.

This proposal, and all of the others like it, are adding function on top of function, creating more and more overhead and jamming more fields and options into an already overly complicated editor - all to preserve ContentOnly/synched patterns.

Remove those and this entire problem goes away, along with many other user frustrations.

Simplify. Less is more.