Standardize Block Inspector Settings to use ToolsPanel - Tracking Issue

[fabiankaegy]

Today, we have two different UI components for grouping controls in the InspectorControls area (Block Sidebar).
The older PanelBody and the newer ToolsPanel.

The ToolsPanel comes with many benefits such as:

1. Control over which settings are displayed at any given time
2. Much easier mechanism for injecting additional settings into an existing group
3. Visual parity with the Styles that already is using the ToolsPanel extensively

There have been one off PR's to handle this conversation from existing PanelBody components to the newer ToolsPanel before:

• Cover Block: Refactor setting panel #65432

This issue is meant to be a tracking issue for converting any remaining usages of the PanelBody

[fabiankaegy]

This issue originates out of a discussion I've had with @youknowriad and @Mamaduka so we have some support for it on the engineering side.

I'd love to get some input from @WordPress/gutenberg-design though as this will be a bit of a visual change (some blocks have already made the move)

[youknowriad]

What's not clear to me yet is whether we should go directly towards InspectorControl group="something" or if we do it in steps, first move to ToolsPanel

[fabiankaegy]

@youknowriad I think the two are unrelated. This ticket is only concerned with moving to the ToolsPanel UI. #67814 is for coming up with how to allow the extension of those via groups.

That being said, looking at the list above 90% of the instances here simply are a PanelGroup called "Settings" so we should already keep track of what groups there are and potentially consolidate where possible

[hanneslsm]

The UX in #65432 (review) is different than the current UX, e.g. in the typography settings. Currently it's about displaying the settings, the new one is about the values.

I think it is crucial to update the display settings simultaneously to ensure consistency and prevent major UX issues.

CleanShot.2024-12-11.at.13.31.58.mp4

[fabiankaegy]

@hanneslsm can you elaborate a but? I'm not sure I understand what you mean? What you show for the typography settings here is exactly what was applied in #65432

[hanneslsm]

@fabiankaegy Sorry for not being clear enough. I can only speak about the design and was referring to:

I'd love to get some input from @WordPress/gutenberg-design though as this will be a bit of a visual change (some blocks have already made the move)

I was trying to say that the panel (no matter how it's implemented) uses two different UX principles. One (e.g. typography settings) is about resetting what is displayed and the other (e.g. #65432 (review)) is about resetting the values. So, it's not only a visual change but a UX change.

I wanted to point out that we could run into frustrating UX because two panels, which look similar, are controlling two different things. Maybe this is a more a design issue than going from PanelBody to ToolsPanel - I now realize that this issue is probably be not the right place.

[fabiankaegy]

@fabiankaegy Sorry for not being clear enough. I can only speak about the design and was referring to:

I'd love to get some input from @WordPress/gutenberg-design though as this will be a bit of a visual change (some blocks have already made the move)

I was trying to say that the panel (no matter how it's implemented) uses two different UX principles. One (e.g. typography settings) is about resetting what is displayed and the other (e.g. #65432 (review)) is about resetting the values. So, it's not only a visual change but a UX change.

I wanted to point out that we could run into frustrating UX because two panels, which look similar, are controlling two different things. Maybe this is a more a design issue than going from PanelBody to ToolsPanel - I now realize that this issue is probably be not the right place.

Ahh okay yeah I see how the two implementations of the ToolsPanel look different here. I wonder why that is though... But yeah ideally it should all be the same

[jameskoster]

I'm all for consistency :)

@hanneslsm I don't think the UX is different, it's just that in the Cover block all the setting controls are visible regardless, whereas in the Typography panel only 'Size' is forced, and everything else is optional.

It's not entirely clear why this decision was made, but it begs the question... do we apply this approach to all Settings panels, or are there some where only certain settings would be added by default and others optional?

If it's the former, then this UI doesn't feel particularly intuitive:

The checkmarks are kind of irrelevant since you cannot toggle any settings off.

[fabiankaegy]

@jameskoster My idea right now would be to start having all elements that currently are always visible (so all items =D) also be visible after the refactor. That way there are no "regressions" just from us moving component.

Then as a next step we can actually do an audit and choose which controls we want to demote and no longer show by default.

Which is then paired with the filterable defaultControls work we are doing in #67729

[jameskoster]

Yes that makes sense, though will lead to a multitude of confusing menu instances as outlined in my previous comment. Maybe it's time to refresh the design a little (separately of course). Something more like the property visibility toggle UX in data views might work—there's a lot of conceptual overlap.

[fabiankaegy]

@jameskoster Do you think we should hold on the refactor till we have improved the tools panel? 🤔

[jameskoster]

No I don't think so.