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

simple-mode.mp4

Tasks to stabilize Write mode

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

• Audit blocks for writing and contentOnly modes #65778
• Improve Write/Design mode switch discoverability #66480
• Navigation Block: develop a content-only representation #65699
• Query Loop Block: develop a content-only representation #66614
• Remove design-oriented controls from Cover block toolbar while in Write mode #66823
• Edit content mode (select mode): Ellipsis menu button in list view is empty #65504
• Image block should not have the "Add text over image" control when in Write mode #66875
• Template part selecting and editing unavailable in “Write” mode #66463
• Post content block should not be selectable in write mode with template rendered #67129
• Write mode: swapping Query Loop patterns sometimes then reveals Group block controls #67763

Future tasks to evolve Write mode

• Edit Mode: Prevent editable text selection on first click #65702
• ContentOnly Write Mode: enable as a capability / role assignment #65503
• Add new mode to contentOnly locking to allow insertion of new inner blocks #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

• Use the previous "select mode" dark toolbar style for Write mode #66054
• Remove parent block selector while in Write mode #66684
• Select Mode: Use the content-only behavior in select mode #65204
• Select Mode: Updates to the block toolbar #65485
• Inserter: Always show the list of all patterns in the inserter #65611
• Testing: Add an e2e test to check the interactions in write mode #65819
• List View: automatically update after switching between Write and Design modes #66802
• Write mode: some group blocks/patterns can't be edited after switching into Write mode #66803
• 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 #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 #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:

• Content Only mode should allow controls in the Inspector to still be reachable if they are content related #57911
• Add new mode to contentOnly locking to allow insertion of new inner blocks #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 .