Writing and contentOnly modes

[SaxonF]

Brief

Editing in Gutenberg can be complicated for non technical users partly because of how challenging it can be navigating/selecting the block tree (going down and up the tree), and how granular editing is. We are enhancing the zoomed out view which helps to alleviate some complexity when composing pages by emphasizing sections and not their inner blocks, but editing still remains a challenge. A prime example is the act of editing a site's navigation.

Visual

https://github.com/WordPress/gutenberg/assets/1072756/77bfc27c-9646-4db8-8487-c1eb70b691eb

Tasks to stabilize Write mode

To ensure a smoother roll out of Write mode, the following tasks need to be addressed:

• [ ] #65778
• [ ] #66480
• [ ] #65699
• [ ] #66614
• [ ] #66684
• [ ] #66823
• [ ] #65504
• [ ] #66875
• [ ] #66054
• [ ] #66463

Future tasks to evolve Write mode

• [ ] #65702
• [ ] #65503
• [ ] #52018
• [ ] Should block outlines be available in Write mode? Perhaps not, as the post editor does not (and it's a "writing mode")

Completed work

• [x] #65204
• [x] #65485
• [x] #65611
• [x] #65819
• [x] #66802
• [x] #66803
• [x] Consider implementing the possibility to "focus" a section to fine tune its content. (not planned)

[bacoords]

I'm a big fan of this - it can bring synced patterns into a place similar to say ACF Blocks where the control over content editing is granular and anything non-editable is purely stripped away. There's probably a bunch of group blocks in these patterns but we don't have to see them in this view 👌 because they're not editable.

A few philosophical thoughts that are just my opinion as a user/developer:

• The BlockToolbar and InspectorControls for innerBlocks should function exactly as they would normally- except everything non-editable should be stripped away. I believe that's what I'm seeing here but wanted to reiterate it because of the comment about the "alt text". I would not add that to the block toolbar if it's not on the block toolbar normally. That sort of consistent behavior (and taking what we have and just stripping away what is locked) is key for education and future extensibility (custom block extensions from developers that modify controls/toolbar)
• Having a list view of blocks inside the Pattern in InspectorControls seems antithetical (why not have it in the List view?) but I understand it's a design we're seeing in templates as well, so maybe that's what it is.
• Eventually tying the "Simple" content editing mode to user roles would be amazing.

[mikemcalister]

This is excellent. Even as an advanced user, I can see the benefit of hopping into the simple mode to make some quick changes without being inundated with UI. This is also starting to feel more like the simplified interface many are anticipating.

Agree with all of Brian's points, especially being able to eventually tie it to user roles. I'm also excited to see a simplified experience for the navigation. Honestly, it feels like that should be the default experience for navigation editing.

The only thing I'm not sure about is tying it to the zoomed out view. If users are editing content, editing text, etc., it may be fatiguing doing it on a zoomed out view. I see why it would be tied to it, but just want to call that out.

[richtabor]

and open inspector by default when switching into this mode.

I'm not sure about forcing the Inspector open. For instance, when inserting patterns, the Inserter + Patterns category sidebar + the Inspector makes the canvas much too tight to lean into composing. That's why I wanted to explore https://github.com/WordPress/gutenberg/issues/59963 (perhaps it can re-open the Inspector when disengaged as well).

I'm also not confident in direct inline canvas editing when zoomed out. It may feel more intuitive to try having fields associated with content, that are exposed in the content-only view, like you're thinking for the Image block alt-text—but for any content attributes (much like Block Connections may end up like).

I would also think the standard List View could be leveraged on the left, rather than a mode-specific list view.

[bacoords]

I'm also not confident in direct inline canvas editing when zoomed out. It may feel more intuitive to try having fields associated with content, that are exposed in the content-only view, like you're thinking for the Image block alt-text—but for any content attributes (much like Block Connections may end up like).

If users are going to start editing actual content in InspectorControls text input fields, we're really negating the entire premise of a visual editor and introducing a new (old) paradigm (with all associated baggage for users/educators). Feels like a really second-class experience to be typing text into a input form field when we have a functional block editor. (Though I agree with the point about the zoomed out view both @richtabor and @mikemcalister seem to be making.)

[richtabor]

If users are going to start editing actual content in InspectorControls text input fields, we're really negating the entire premise of a visual editor and introducing a new (old) paradigm (with all associated baggage for users/educators). Feels like a really second-class experience to be typing text into a input form field when we have a functional block editor.

There's a balance.

If you're zoomed out (in this mode), I wouldn't expect to be able to edit tiny text. Instead I'd expect a clear indication of what I can edit, from a top-down view. Sure, when not in this view, granular controls like we have now are great.

[richtabor]

Related to https://github.com/WordPress/gutenberg/pull/59249, as it enables zoom out mode to select top-level blocks only. Could use more testing.

[richtabor]

@SaxonF is the next step to explore turning on contentOnly for top-level blocks (same logic as #59249) when zoomed out is engaged?

[aurooba]

I'm also not confident in direct inline canvas editing when zoomed out. It may feel more intuitive to try having fields associated with content, that are exposed in the content-only view, like you're thinking for the Image block alt-text—but for any content attributes (much like Block Connections may end up like).

What happens to Rich Text? What happens if you want to add a link, bold something, etc? Are we bringing back the TinyMCE editor for this scenario?

It makes sense that you shouldn't edit tiny text. Maybe clicking on something you can edit inline zooms you back in?

---

Overall this is awesome. I agree with both Brian and Mike's points. And this is such amazing progress in the right direction! 😊 and thank you for the walkthrough video, super helpful!

[fabiankaegy]

Just wanted to share these two relevant issues:

• 57911

• 52018

Regarding the conversation about fields becoming editable in the sidebar only. I think there is a clear difference between the zoomed-out mode and the regular content editing where content-only locking also is used. I feel strongly that we should not move to a sidebar editing experience for the regular mode. For that, I think what we have today for inline & toolbar settings works. But we need to extend it to also support certain sidebar features as outlined in #57911 The zoomed out mode is a different story any I'm glad we are experimenting with different options here :)

[richtabor]

The zoomed out mode is a different story any I'm glad we are experimenting with different options here :)

Agreed. My thought was along if zoom out and content only were the same experience—as you wouldn't expect to select and edit granularly while zoomed out. At this point I'm not thinking zoom out and content only are to be combined.

[SaxonF]

Makes sense to me. Zoom can be treated as its own thing .

[talldan]

I'm testing out some changes to contentOnly mode in #60412 along these lines.

[jhmonroe]

(Like synced pattern overrides #59607) content-only editing does not work with the Details block at all. :-(

See attached, when content-only is applied to a group containing the details block, there is no way to edit the first line (coded as summary instead of paragraph or heading) of the detail block

[mtias]

I think we need to rename this set of features, maybe by making it the default "pattern editing" experience and calling it that.

[fabiankaegy]

@mtias when you say rename do you mean the actual code reference (blockEditingMode) or end user facing references?

I don’t think we currently showcase the name content only anywhere in the UI.

But the blockEditingMode is a public API that is used for more things than just patterns.

The newer preview template mode that now exists for all users in block themes inside the post editor uses that feature under the hood. I know of many custom blocks that use this feature.

I’m concerned that renaming would cause more confusion and breaking changes. And personally am not too sure what problem renaming it would actually solve.

[jasmussen]

My read: it's only for anything user-facing. There isn't much, if any, UI yet, but we've been needing to build that out for a long while: how do you enable it, how do you disable it, what's its relationship with locking, etc. I tentatively think there's a good idea hidden in the idea of patterns being inserted in this state by default. Conceptually it's similar to synced patterns with overrides—these are just not synced, it's just patterns with overrides. That would let us use the same "detach" interface. All of this would need an exploration, but knowing that we'd not have to call it "contentOnly" or "Content only" would be useful in those explorations, even if under the hood the props name stayed the same.

[mtias]

@fabiankaegy yeah, I mean in terms of how we refer to it when we discuss iterations and the evolution of the related features—"Content only" is a bit clunky and doesn't capture the breadth of the experience behind it. We tend to get stuck with the naming of some of the underlying props and then that goes directly into the general user updates and communications we put out, which is not ideal.

[bacoords]

I think we need to rename this set of features, maybe by making it the default "pattern editing" experience and calling it that.

Perhaps before we get another round of renaming features- which comes with the side effects of making our content out-dated, making it harder to refer to features in training materials, and just increasing general community frustration- it would be worth generating an issue that provides some sort of end vision for what these disparate features (block locking, contentOnly, template locking, pattern overrides, etc) are hoping to look like as a complete & coherent "feature" inside of WordPress. As @fabiankaegy mentioned, pattern editing is only one use for this, but versions of it are also used in custom blocks, with the block bindings API, with CPTs with templateLock, etc.

Once an actual vision for where these features are headed, for what end-users might be expected to do with them, is articulated, then I think the naming should be addressed.

[noisysocks]

I think something like this is really important to improving the experience for new users. Right now it's overwhelming when you're dropped into the site editor and have full control of everything straight away—we need a gentler on-ramp.

In general I'd love to see deeper design explorations of how this and https://github.com/WordPress/gutenberg/issues/50739 could be combined into an interface that helps an inexperienced user build a new page from scratch using patterns and contentOnly editing.

Apply contentOnly to all sections when zoomed out, and open inspector by default when switching into this mode. This mode becomes more of a "simple editing" mode.

I don't think it makes sense to be able to edit the content, even in contentOnly mode, while zoomed out. The text will be very small. I think it would work better to have a mechanism where, from zoomed out mode, you click on a section to zoom in on it and then edit the content (using contentOnly) within that section. Clicking outside the section could zoom back out.

The end result would look something like below.

One thought I had while watching the mockup is that the List View on the right could in theory be merged with the List View on the left. The combined List View would contain all of the sections and then, nested within them, the editable blocks of content that are in that section. That frees up the right sidebar for something else, or gives us more horizontal space for the pattern inserter to be opened as well.

I think this mockup was also put together before we implemented the current behaviour of flashing the outlines of blocks that are editable when the container is contentOnly locked. That would work well for this use case.

[getdave]

I've experimented with the content only drill down in this experimental PR.

[noisysocks]

👋 Going to work on a v0 of this with @getdave and @richtabor behind an experimental flag.

For the first pass, I'm picturing:

• Replace Edit / Select toggle with a Simple / Advanced (name tbd) toggle.
• In Simple mode, the entire editor has a contentOnly lock.
• Audit which blocks are editable in contentOnly. For example, Site Title should be editable.
• Enhancements to the contentOnly UX:
  • https://github.com/WordPress/gutenberg/pull/64866#issuecomment-2321369510
  • https://github.com/WordPress/gutenberg/pull/64872
  • https://github.com/WordPress/gutenberg/issues/64727
  • https://github.com/WordPress/gutenberg/issues/64661
    • https://github.com/WordPress/gutenberg/pull/64917
  • https://github.com/WordPress/gutenberg/issues/64663

[bacoords]

Any chance of including the two issues mentioned above in this comment: https://github.com/WordPress/gutenberg/issues/60021#issuecomment-2028084525

These are big ones for agency/extender community.

[talldan]

Audit which blocks are editable in contentOnly. For example, Site Title should be editable.

This one is interesting, as the block doesn't have any attributes that'd be suitable for role: 'content'. 😬

Options:

• Add an unused content attribute.
  • An alternative of this is to make the block use the content attribute via block bindings, or go even further and migrate site title to be a heading block variation that uses block bindings (which I don't think we're ready for)
• Add a contentOnlyEditing block supports. (What I don't like about this is it doesn't declare which of the editable parts of the block are content, so it limits future possibilities for things like Block API: try separate controls registration)

Any others?

[noisysocks]

Any chance of including the two issues mentioned above in this comment: https://github.com/WordPress/gutenberg/issues/60021#issuecomment-2028084525

Sure! I didn't mean my list above to sound exhaustive. The key thing is that we should iterate on the contentOnly UX.

This one is interesting, as the block doesn't have any attributes that'd be suitable for role: 'content'. 😬

Ah that's a good point. I don't hate the idea of adding an unused content attribute. Or maybe role: "content" isn't the right approach and it should be somehow handled in the block's edit function.

The design of role: "content", templateLock: "contentOnly" and useBlockEditingMode can be awkward, I'm more than happy to make API changes if we can sit down and think of something cohesive.

[jeryj]

how challenging it can be navigating/selecting the block tree (going down and up the tree)

Are there some user studies around this? I don't disagree that it's challenging to navigate/select, but I'd be interested to see where and how people commonly get stuck. Then, we can re-run some initial user tests on the various ideas that are being worked on (https://github.com/WordPress/gutenberg/pull/65055, https://github.com/WordPress/gutenberg/pull/65027) to see if it is an easier entry into the editor.

Also, the video shows content navigation via the sidebar, would items on the page also be clickable to select? I.e. clicking a navigation item to make an edit?

[Sirjazzfeetz]

Before another round of renaming features [..] it could be worth generating an issue that provides some sort of end vision. Once an actual vision for where these features are headed, articulated, then address the naming.

For the first pass, I'm picturing: Replace Edit / Select toggle with a Simple / Advanced (name tbd) toggle. In Simple mode, the entire editor has a contentOnly lock... [ then we ] audit which blocks are editable in contentOnly.

The names seem fine, as for their description; 'simple' to me means editing content; specific parts of the page which help focus the attention of myself or my client. So the meaning of 'simple' can be simply defined, as "content" here refers to a single level of information. Whereas 'advanced' deals with the entire design; total structure and style, multiple meanings and patterns. How content is specifically configured in FSE is of secondary concern to full control of "content", broadly defined as the entire page.

[youknowriad]

As we work on these new interactions, one important realization for me from all this work and discussions around these is the following:

The modes and tools are secondary. What we're building is a new interaction model for "container blocks". Let's call them sections. When a container is considered a section, the following behaviors are applied to it (not exhaustive, this is what is being built/iterated on):

• Its block tree is flattened.
• Only content blocks are selectable and editable.
• Inspector panel only shows the "content" panel
• List view flattens the tree as well

The important bit in my message is that it's not the "mode" or the "tool" that should dictate how the editor and blocks should be have, it's whether a block is considered a section. In this PR, this is codified in the isContentLockingParent private selector.

Right now, a container block can be in that mode for one of the following reasons:

• Reusable blocks are always sections
• Container blocks with "contentOnly" template lock are also sections.
• All children of the "main" sections container in "edit/zoom-out" mode are also sections.
• Later we might decide that template parts are also sections.

I think this is important for us to understand because it means that the "code" in the block editor package shouldn't have to check modes, lock... it should just check whether a container block is a section and apply the right behavior. It also means that we can iterate on the modes/flows/blocks easily... Once the interaction model is solid and in place, it becomes a matter of changing the implementation detail of that selector to enable it or disable it in other flows/modes.

[youknowriad]

As we start gaining clarify of where we want to take this. I've updated the issue and added a todo list at the end. This will serve as an overview issue for all the needed follow-ups for this new select tool.

[bacoords]

@youknowriad Would also love to see if this issue could be included in the scope. Allowing theme devs to tie contentonly editing to a user role/cap would be a big win:

https://github.com/WordPress/gutenberg/issues/65503

[youknowriad]

Hi! I can see how that can be useful for site builders to control the experience of the clients. To be honest, I think it's a bit early for that though, we're not even sure what's the ideal contentonly experience is. I think we should first focus on the experience itself but if we get to a point where we're satisfied, I think it's definitely something we can consider.

That said, I'm adding it to the todo list.

[richtabor]

Consider implementing the possibility to "focus" a section in the "select" mode to fine tune its content. Like a double click to enter "advanced" mode but only focused on the current section.

I'm not thinking this is necessary, at least in the current implementation. Perhaps something to explore in the future.

[annezazu]

Quick update that in light of user testing and known issues outlined in this issue, I have opened an issue to change Write mode to an experiment that can be turned on/off for future testing: https://github.com/WordPress/gutenberg/issues/66881 I've also done my best to update this issue with clear next steps needed to move it back out of an experiment. Feedback welcomed!