Add back "Block Name" text field in Advanced Inspector

[fabiankaegy]

In #60234 the "Block Name" Text field in the Advanced Inspector was removed.

Having used this in a few Gutenberg Releases now, I think it's a major mistake, and we should add it back before WordPress 6.6 is released.

Renaming is a very common action on sites with more complex page structures. However, the flow for performing this action has become much slower and more complex.

[talldan]

If it is added back, a good thing to test is how well it works for the Enable/Disable Pattern Overrides flows. I don't think there'd be an issue, but worth double-checking.

It's surprising to hear that using List View is slower though, I would've thought having to select a different block and expand the Advanced section to be much slower. Is it the modal that makes it slower?

[fabiankaegy]

@talldan I added #62084, which reverts #60453 and disables the text field when the block has pattern overrides enabled.

It's surprising to hear that using List View is slower though, I would've thought having to select a different block and expand the Advanced section to be much slower. Is it the modal that makes it slower?

Yeah, of course, it would be even better if the expansion of the Advanced Inspector were retained across block selection. But even still, the issue with the context menu option to rename is that the context menu itself covers the button to open the next context menu. The interaction to close the modal and the animations themselves slow it down. Additionally, it is too much of a context switch. The modal covers the content area, so you no longer actually see the section you are renaming, etc.

[richtabor]

However, the flow for performing this action has become much slower and more complex.

How is it more complex? You can rename any block from list view here, or on block selection. Otherwise, it's buried on block selection, with the inspector opened, with the advanced panel open. It's more hidden as an additional control, than the current implementation.

And I'm not confident we should have multiple controls for the same function (which we do far too often).

We could instead add a key combo to rename perhaps.

[fabiankaegy]

@richtabor I recorded 2 quick screencasts of me renaming a bunch of blocks:

CleanShot.2024-05-29.at.13.37.17.mp4

CleanShot.2024-05-29.at.13.38.57.mp4

It may very well have something to do with my dyslexia. But to me even finding the correct button in the block context menu always means I have to pause and look where the right action is. On top of that as you see in the video, in the advanced panel it is two clicks:

• Selecting the Block
• Expanding Advanced Section

For the Modal it is more than that:

• Selecting the block (is required to close the previous context menu that covers the new context menu)
• Clicking on the context menu
• Clicking on the "Rename" menu item
• Closing the modal

Those factors, paired with the fact that the modal covers the content and that the name field shipped in 6.5 and, therefore, removing it breaks established user flows, are the reasons why I deem this to be a clear regression that, in my opinion, needs to be reverted / fixed before WordPress 6.6 ships.

[richtabor]

But to me even finding the correct button in the block context menu always means I have to pause and look where the right action is.

To be fair, you have to do the same searching for the block name field, it's just in the "Advanced" drawer, where the number—and type of—controls vary from block to block, which make it more difficult to scan than the list of actions where "Rename" currently sits.

Those factors, paired with the fact that the modal covers the content and that the name field shipped in 6.5 and, therefore, removing it breaks established user flows, are the reasons why I deem this to be a clear regression that, in my opinion, needs to be reverted / fixed before WordPress 6.6 ships.

I'd like to hear others' opinions as well.

[richtabor]

For context, here's what we have without the additional name field, from a pattern:

And here's a group block:

[jameskoster]

I think it's okay to have renaming in the Inspector, but I'm not sure about the Advanced panel. I think I'd expect to find an Ellipsis button in the block card which would open the same menu as the ellipsis buttons elsewhere (albeit with certain actions omitted):

This would mimic a convention recently installed in data views / document inspector:

[jasmussen]

The sticking point here, and why I don't think we should revert to have the "Block name" panel as it exists, is that the modal rename experience that is invoked from the ellipsis menu in list view opens a modal with helpful context. That context doesn't exist in the block name, so it appears as two very different interfaces for renaming, even if the net result is the same.

I'd echo Jay's instincts above, that an ellipsis menu in the inspector could open that very same modal, thus solving the problem. I'd also lean in on what you noted about the current flow being slower and ask: what can we do to make it faster, that isn't necessarily the input field in advanced (because arguably that's cumbersome and complex too). Some ideas:

• Double-click list item to open rename modal.
• Click list item, then press ⌘R, or another shortcut, to rename.
• The ellipsis menu as Jay mocked up, and perhaps paired with double clicking the block title in the inspector also opening the rename modal.

[fabiankaegy]

I appreciate all the ideas for improving this flow. I really do. And I don't think that the advanced panel is the only/right way to solve this long term.

Having said that, for WordPress 6.6, I think that if we don't have a better alternative solution, the next best thing we have today is reverting the change and retaining the behavior we released to the world in WordPress 6.5.

We can always revisit/improve that in 6.7. But for now, we are 2 days away from the feature freeze of 6.6, and what we have today, in my eyes, is a regression. So, whilst we work on a better solution, the short-term fix is the revert.

[richtabor]

We can always revisit/improve that in 6.7. But for now, we are 2 days away from the feature freeze of 6.6, and what we have today, in my eyes, is a regression. So, whilst we work on a better solution, the short-term fix is the revert.

I don't think there's a consensus that this is a regression.

[fabiankaegy]

We can always revisit/improve that in 6.7. But for now, we are 2 days away from the feature freeze of 6.6, and what we have today, in my eyes, is a regression. So, whilst we work on a better solution, the short-term fix is the revert.

I don't think there's a consensus that this is a regression.

@richtabor even if you disagree that this is a regression. Don't you think that if we want to iterate more on this feature in the future it isn't a better experience for end users to not have the experience change 3 times in 3 releases? And instead retain the current behavior that is in 6.5 and then only ship one iteration when we are happy with it.

[richtabor]

If the block rename control in Advanced shouldn't be there long term, then removing it sooner than later would certainly be ideal. That would be a less dramatic change.

The additional affordances suggested are small enhancements and likely not much of a difference. I don't consider them a necessity.

[peterwilsoncc]

Fabian reached out to me and asked me to form a view on the ticket. Which I am yet to do ;)

I know WordPress.com makes use of telemetry a fair bit, but don't know how detailed that is.

Do any of the Automattic employees on the ticket have stats on how much the block renaming feature is used, and if so, specifics in to which UI is commonly used? (Please ensure you are allowed to share any data before sharing.)

The reason for my question is that I would like to understand whether renaming blocks is

• a commonly used feature or more of a feature used by a power user
• more commonly used on big content sites (news sites) or used on sites of all types

[jasmussen]

I'm not aware of any telemetry there. Though a casual ping to @annezazu in case she has info about this, I know she was excited about the renaming aspect. Very anecdotally with a data point of myself, I was recently in a conversation around creating a feature showcasing the fact that you could rename your sections to make the List View more glanceable, and creating said feature because not enough people knew about this fact.

I'm for keeping the trunk behavior, for the same arguments as Rich presents; it's two different UI's and the modal we have consensus to keep and embrace with future added affordances. However it's not the most strong opinion in the world, so I'm happy to defer to consensus otherwise if that happens.

[ndiego]

I currently use the option in the Advanced panel quite regularly, but then again, that panel has become a catch-all, and I am not opposed to simplifying it.

I do find it annoying to have to click on the ellipsis icon for the block and then find the "Rename" option. It's basically four clicks to rename a block instead of two. And I am usually already in the settings sidebar configuring other block options.

Gutenberg

1. Click on the block
2. Click ellipsis icon in the block toolbar
3. Click "Rename"
4. Rename the block
5. Click "Save"

WordPress 6.5

1. Click on the block
2. Click the Advanced panel to open it
3. Rename the block

We could instead add a key combo to rename perhaps.

This would be the ideal solution.

[bacoords]

I would just like to add another vote of support to reverting this change. A block's name is one of its many attributes, so it should be editable in the Inspector Controls for that block. A few reasons:

1. There's already a wealth of training (in public and with our clients) on this workflow, which means after the next release it'll just be a missing/broken feature, another Gutenberg "papercut" because the experience changed without warning.
2. Hiding block settings behind ellipsis icons and requiring additional modals does not simplify the editing experience, it actually makes it more complicated and adds more exhaustive mental effort.
3. Inspector controls should be the catchall for editing the attributes of any block. One of the most common pain points we hear about are block-level settings that aren't in the inspector controls (such as flexbox, alignment, etc). At this point a user expects to be able to open the sidebar and edit any block attributes.

(If there were to be an additional interaction for renaming a block, I'd recommend doing what almost every graphic design tool offers - double clicking the block's name in the list view converts it to a text input field. Photoshop, Figma, etc all use that same convention- double-click on a "layer" and edit the name of it.)

[ndiego]

(If there were to be an additional interaction for renaming a block, I'd recommend doing what almost every graphic design tool offers - double clicking the block's name in the list view converts it to a text input field. Photoshop, Figma, etc all use that same convention- double-click on a "layer" and edit the name of it.)

I believe this was originally explored but created accessibility issues.

[richtabor]

I'd recommend doing what almost every graphic design tool offers - double clicking the block's name in the list view converts it to a text input field.

Yes, we tried to get this in.

Inspector controls should be the catchall for editing the attributes of any block. One of the most common pain points we hear about are block-level settings that aren't in the inspector controls (such as flexbox, alignment, etc). At this point a user expects to be able to open the sidebar and edit any block attributes.

A catch-all is simply not a good user-experience. The Advanced panel will continue to become more burdensome the more "kitchen-sink" it becomes.

Hiding block settings behind ellipsis icons and requiring additional modals does not simplify the editing experience, it actually makes it more complicated and adds more exhaustive mental effort.

Right clicking for options (which you can do in List View) is just about as universal as it gets for accessing rename options (second to double-click).

[carolinan]

Moving options creates problems and annoyance for users who have to re-learn an already advanced UI.

It was mentioned that the options in the advanced panel varies depending on the block and that this is a reason to not show the option there.
But the options list view also varies, the number options are sometimes many times larger than in the advanced panel, and because the options are uniform, plain text, they are more difficult to find.

[richtabor]

because the options are uniform, plain text, they are more difficult to find.

The opposite actually happens; a list of like items is much easier to parse than an array of different shapes/sizes/text length (the Advanced panel).

[richtabor]

For additional context, this is the proposed state, with an override.

You shouldn't be able to carelessly rename an override (which is why the control is disabled in the proposal). But at the same time, if you see a disabled control that you expected to be able to use, you've introduced a point of frustration.

This was the original intent behind removing the additional Block Name control from the Inspector.

[richtabor]

Moving options creates problems and annoyance for users who have to re-learn an already advanced UI.

100%. That's another reason I don't think this should be reverted. The longer something is introduced in core, the effect of introducing changing it is more profound.

If there's a lack of confidence that this belongs in the Advanced panel, we shouldn't keep it. Any enhancements or additional affordances to access the rename flow are just that: enhancements and additional affordances.

[fabiankaegy]

You shouldn't be able to carelessly rename an override (which is why the control is disabled in the proposal). But at the same time, if you see a disabled control that you expected to be able to use, you've introduced a point of frustration.

We can easily add a link to the help text why it is disabled that opens the rename modal that then also provides the additional context for what side-effects the rename action has. I'm more than happy to update the PR with that if that is the point of contention.

Update: Never mind. Opening the modal is not exposed and local to the other control. Doing what I proposed would be a larger lift.

[fabiankaegy]

If there's a lack of confidence that this belongs in the Advanced panel, we shouldn't keep it. Any enhancements or additional affordances to access the rename flow are just that: enhancements and additional affordances.

Honestly, my take is the exact opposite. If there is a lack of consensus on this, we should retain the behavior that has actually shipped to users in WordPress core...

[annezazu]

Quick note that I'm attempting to get data from WordPress.com but that's it's likely this isn't tracked in the same way data is in place for methods for inserting blocks or patterns. If you don't hear from me, I haven't gotten data so please proceed as if that's not in place for now.

(If there were to be an additional interaction for renaming a block, I'd recommend doing what almost every graphic design tool offers - double clicking the block's name in the list view converts it to a text input field. Photoshop, Figma, etc all use that same convention- double-click on a "layer" and edit the name of it.)

To close the loop on this, here's the discussion and PR: #53852

To share my point of view here, I see this as a natural evolution to both accommodate overrides and to consolidate options. It's not being changed for no reason but to fit a new feature. I tried to track down when this was added to Advanced but couldn't come up with anything specific. From the onset, the intent was around renaming in List View directly. As a result, I'm in favor of keeping it removed and solving the issue with wanting to see the renaming while it's happening directly in List View. I think the prior PR has some good starting discussions that can lend itself to how to accomplish that (visible save, cancel options similar to what was shown here).

[talldan]

Related issue that was just created - Keyboard shortcut to rename a Block