Query block: Disable editing of content by default

[jameskoster]

Part of #30910.

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.

We should explore some designs that add a just enough friction to the global editing experience in order to differentiate between the results of these actions.

[jameskoster]

Here's an option for this one, mostly based on concepts we need in the template editor; content-locked blocks (#30156) and the click-through pattern (#31109).

posts.mp4

Notes:

• 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 properties:
  • 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:
    1. Click the more menu in the toolbar and select the "Edit" option
    2. Click the lock icon in List view
    3. 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 isHiglighted treatment
    • The document title in the top bar is updated. This is based on the notion of displaying the document title in the top bar (Move post/page title to the top bar. #27093) and the existing pattern in the template editor of moving back to a referring entity.

[paaljoachim]

Associated:
On Locking and TemplateLocking
#29864

This looks very interesting, James!

Another suggestion would actually be to add a lock to the toolbar, or perhaps a mix of a lock in the toolbar (and List View) and the approach you suggest.

@jameskoster James it would be great to have a Figma prototype to test out. To get a hands-on feel.

[jameskoster]

Unlocking via the toolbar could definitely be an option. But we may need to leave it for later (#31461 (comment)).

it would be great to have a Figma prototype to test out. To get a hands-on feel.

It's very hard to make a single prototype for this that feels natural since there are so many flows to account for. Double-clicking is not available as a recognisable action either so you have to spoof it. It might be better to split the interactions into separate prototypes.

Here's moving and editing the Post Title block: https://www.figma.com/proto/i6yFoDYQdSx8G44thFDd9M/Query-block?page-id=2827%3A0&node-id=2827%3A7&viewport=568%2C480%2C0.22870875895023346&scaling=min-zoom

Here's block selection: https://www.figma.com/proto/i6yFoDYQdSx8G44thFDd9M/Query-block?page-id=2827%3A1431&node-id=2827%3A1643&viewport=582%2C626%2C0.1394118368625641&scaling=min-zoom

[ntsekouras]

What about the Post blocks that exist in a page that are not inside a Query block? For example in post editor if we add the Post date block should this be locked in the same way?

[ntsekouras]

Also in a Query block if we unlock a Post Title block for example, this means that we have unlocked it for other posts as well? Or the user will have to unlock the title for another post?

[jameskoster]

What about the Post blocks that exist in a page that are not inside a Query block? For example in post editor if we add the Post date block should this be locked in the same way?

I think it depends whether you're editing the post or its template. The UX issues arise when you begin editing something outside of the local scope.

So if you're editing a post, it's probably fine for a Post Date block at the root level of the tree to be directly manipulated because doing so would update the publish date for that specific post. But if you're editing a template then the context is lost, and so the block should be locked. This second part is what I made a crude PR for over in #31461 (and has significant overlap with the concepts shared here).

FWIW, I do think there's a discussion to be had around whether these blocks should even be surfaced in the post editor at all. Personally I don't think they should. See: #31830.

Also in a Query block if we unlock a Post Title block for example, this means that we have unlocked it for other posts as well? Or the user will have to unlock the title for another post?

That's a good question.

I think the unlocking and editing flow should be a closed loop, local to the entity being edited. IE you select the block, unlock, edit, then when you click anywhere outside the block it locks again. So you can only edit one Post Title at a time.

editing.mp4

This does pose an interesting question though: If you select the Post Title block in List View, which one get's selected on the Canvas? Currently it's the first one, and that's probably fine for now.

[paaljoachim]

I would say that List View reflects what is seen in the Gutenberg layout/canvas area. Which means that having a Lock in List View there could also be a lock icon in the toolbar of the specific block.

Example above would be having the lock in the Post Title seen in List View. There could also be a lock in the Post Title toolbar. Unlock in List View or in the toolbar and one will see both locks open (creates an association between List View and block). Giving the lock have a higher degree of visibility for the user. List View would continue to reflect what is seen on the canvas. As locking/unlocking can be a vague process and it becomes important to create the association between List View, Block toolbar and the action the user selected.

[jameskoster]

Another important consideration here is how the Post Content block behaves. If I'm editing a template with a Query that contains the Post Content block, I am currently able to directly manipulate the blocks within the Post Content:

query.mp4

Naturally this change would be pushed upstream to the post itself. I wonder if this interaction is too powerful? Perhaps it should only be possible to select the Post Content block, move it around and change other attributes, but not drill down to the underlying blocks?

[jameskoster]

I'm going to close this since editing is now disabled. We can open subsequent issues to explore how to access edit capabilities.