Add text field as an option in the block toolbar

[MichaelArestad]

There are already two situations where it makes sense for a user to edit the name of a block: reusable blocks and template parts.

In recent mockups for #21218, I tried using a similar design pattern to that of a reusable block. It worked okay. What I don't like is the friction added where a user needs to click "Edit" to edit the block and the block's name followed by clicking "Save" to save the block and the block's name. I also don't love how there is a persistent toolbar between the block toolbar and the content.

Here is the current reusable block edit and save flow:

Proposal

I think it would be useful to be able to edit a text field within the block toolbar. The changes would save when the user saves the document. It would reduce friction when creating or modifying the reusable blocks or template parts. @shaunandrews is also exploring what that might look like in the context of changing a link in the navigation block.

What do you think?

CC @jasmussen

Source figma file

[jasmussen]

I like it. Really nice ticket.

In absence of a save button, we'll want to test that undo works as expected.

One of the differences between saving reusable blocks, and saving template parts, is that the latter happens during publish, with the big save button with an unread dot.

This is harder for reusable blocks which more issue than not exist in a context that features a publish, or published button, which isn't as intuitively clicked. So simply for that reason, an unless we have better ideas, we might need to keep a save button for reusable blocks.

Or a check mark. We have some mockups for image tools featuring a check mark to apply a cropping operation.

[Addison-Stavlo]

I agree the current state is a bit clunky and funky feeling.

In the proposal we have the input field on the toolbar when the top level block (section/template-part etc) is selected.

Once a user selects an interior block (like a paragraph inside that template part) would that input field then go away?

If that is the case, it may feel a bit disorienting for users to try to get back to targeting the selection where they can see/edit the name at times (as opposed to always having it there like the current state, they can always find it!).

If thats not the case and we leave the input in the toolbar when interior blocks are selected that raises concerns for:

• The name/input would have to correspond to the nearest parent section/template-part which could potentially get confusing for users when there are nested sections/template-parts. We would need to find a way to reduce ambiguity, to help prevent the situation where they think they are renaming one and actually renaming the other.
• The toolbar width. With rich text, alignment, color, etc. settings on the toolbar along with the input it could get pretty wide. I guess for mobile width the toolbar can always 'wrap'. Two levels seems fine but if its getting to the point where the toolbar has a 3rd level to fit the input that could start to be undesirable?

[MichaelArestad]

Once a user selects an interior block (like a paragraph inside that template part) would that input field then go away?

@Addison-Stavlo Yes. It would behave like a normal block toolbar.

If that is the case, it may feel a bit disorienting for users to try to get back to targeting the selection where they can see/edit the name at times (as opposed to always having it there like the current state, they can always find it!)

That's true. I don't think that issue is unique to selecting the parent block in general and we're trying out a few things that will help with that. In other words, it would be consistent with how other blocks like Group and Columns function.

[Addison-Stavlo]

Yes. It would behave like a normal block toolbar.

Cool! This is neat and I do like it. The input works much better as part of a toolbar than as part of the page. Having it as part of the page while you edit makes that section of the page look visually different than it will end up on the front end, which is not very FSE-like 😆 . The toolbar definitely makes the editor - front-end feel a bit more 1-1.

[jasmussen]

Once a user selects an interior block (like a paragraph inside that template part) would that input field then go away?

I've been pondering whether there's a heuristic that lets the parent toolbar stay open. This is not just helpful for this specific design (and the 1-1 frontend editor feel is definitely key to achieve 👌) — but it might be helpful for things like the List block when that moves to using nested blocks. We already have the "parent absorbs child block toolbar" prop that the Navigation block uses, perhaps it could show the parent and child toolbars next to each other.

It's a thought that needs refinement. Multiple toolbars don't scale well, and when the toolbar is far away from the actual block, so is the drag handle. But it's something to think about — if you get any ideas, do share.

[youknowriad]

For both the template part and the reusable block, editing the title happens now in the block inspector. I think it's probably a good alternative to this issue. So I'm thinking that maybe we should just close this issue for now.

[jasmussen]

I would love to revisit "double click to edit" on any fields, both those in the toolbar and in the list view and other places. But I also tend to think this can be a separate more component-first/generic exploration.