Live editing post data inside a Query block – whilst editing something else like a page – requires some demanding mental gymnastics in terms of the UX. Users are required to understand that editing block properties (like position and alignment) are local to the page, while any data changes (like updating the publish date or the post title) are global. None of this is made very clear in the current experience as you are able to fluidly perform either action.Me – https://github.com/WordPress/gutenberg/issues/32317
Today I explored a solution that adds a layer of friction between editing two global entities within the same view. There’s nothing really new here, I’m essentially building upon a concept I’ve shared before for the template editor. The use case is virtually identical.
- Clicking anywhere on the Query will select it
- Only when the Query has been selected can you interact with its children
- Selected children exhibit some unique characteristics:
- A semi-transparent overlay indicates that the block contents cannot be edited directly
- Other blocks of the same type in the Query are highlighted with a dashed outline
- The parent container exhibits a dotted outline
- Content editing is accessed via:
- Click the more menu in the toolbar and select the “Edit” option
- Click the lock icon in List view
- Double-clicking the block
- While a child block contents are being edited the following visual treatments are used to indicate it is a separate entity
- Other blocks outside of the scope of that post are dimmed significantly
- The post itself displays the
- The document title in the top bar is updated. This is based on the notion of displaying the document title in the top bar (#27093) and the existing pattern in the template editor of moving back to a referring entity.
There is quite a lot of redundancy built in to this concept, and some of it may be overkill. For now I’m throwing everything at the wall to see what sticks. Perhaps we can exercise some subtraction as we separated the wheat from the chaff.