Stabilize `ToolsPanel` component

[fabiankaegy]

The ToolsPanel component has been introduced to Gutenberg as the __experimentalToolsPanel all the way back in 2021 #32392.

It is getting used by Core widely for all of the Styles controls and in #67813 we are consolidating the Settings of all blocks to use this control also.

Given that we should also seek to stabilize this component and it's child ToolsPanelItem so they become our recommended approach for handling groups of settings in any block development.

[fabiankaegy]

@WordPress/gutenberg-components @youknowriad not sure who the main maintainers of this have been this far but curious about your take on this :)

[ciampo]

not sure who the main maintainers of this have been this far

That would be mainly us @WordPress/gutenberg-components . The component was initially created and iterated on by @aaronrobertshaw .

We can definitely look into stabilizing the component. Maybe this is also a good time to audit it and see if there are any gaps/improvements we want to make

[aaronrobertshaw]

Maybe this is also a good time to audit it and see if there are any gaps/improvements we want to make

+1

The steady adoption of the component suggests we should look to stabilize the ToolsPanel.

As part of that process and auditing for gaps/improvements, there are some UX issues around the use of the panel that should be factored into the equation as well. The following issues will likely require some tweaks to the component before stabilization.

• ToolsPanel: It's difficult to close the ToolsPanel menu #41546
• ToolsPanel: The ToolsPanel menu gets in the way of seeing what selected options look like #41545
• ToolsPanel: Selected ToolsPanel menu options are not persistent #41544
• Audit and improve ToolsPanel's a11y #38059
• Components: audit accessibility #50166

Others more knowledgable than I about the components package might also question whether a stabilized ToolsPanel belongs in that package. It might be too late to "remove" it though.

[ciampo]

Others more knowledgable than I about the components package might also question whether a stabilized ToolsPanel belongs in that package. It might be too late to "remove" it though.

Yes, and probably yes. I'm afraid ToolsPanel has been part of the @wordpress/components package (and Core releases) for too long for us to be able to remove it.

As part of that process and auditing for gaps/improvements, there are some UX issues around the use of the panel that should be factored into the equation as well. The following issues will likely require some tweaks to the component before stabilization.

Thank you for listing those! Let's coordinate to understand which issues are still relevant and need addressing, and how to split those tasks. I started by leaving a few comments on the issues listed above.

[afercia]

I have concerns about the actual usage of this component and from a design / UX persepctive in the first place at the point I'm not sure it is ready to be 'the recommended approach for handling groups of settings in any block development'.

For example, I'm not sure I understand why it is used when there's only one setting. See the Background setting example in the screenshot below:

That feels just unpolished and confusing to me. It's a design issue and at the very least the usage guidelines should make very clear when an dhow it is best to use this component. Ideally, the component should be reconsidered to better handles these cases

There are specific a11y issues that I can report on #38059 but I think the UX isn;t good enough yet to make this component stable and recommended usage for settings.

For example, as an user I find extremely confusing that some settings can be 'reset' and stay always visible while other settings can't be reset but their visibility can be toggled. To me, this mixed mechanism is confusing and unclear for users and I think the design of this component is maybe one of the most confusing in the editor. As such, I think it should be reconsidered before making it stable.

Screenshot of reset / toggling visibility mecahnisms:

[Mayank-Tripathi32]

Building on [this comment], it seems unnecessary to allow resetting toggles and button-based views. For example, PR #67975 enables resetting the "Show Text" toggle, which feels redundant.

Additionally, as discussed in the tracking issue, the hasValue and resetAll options should be made optional for items where they are not applicable. This would simplify the logic and reduce unnecessary complexity.

[fabiankaegy]

I'm not sure it is ready to be 'the recommended approach for handling groups of settings in any block development'.

If this is not the case the we should prioritize a lot of these enhancements. Because every single core block has been shipping this UI for all of the styles options for almost 3 years now.

I'm not disagreeing with you @afercia here. All I'm saying is that if using the component in every single block we ship in core isn't setting the precedent already that this is how one should build stuff then what is?

[afercia]

I'm not disagreeing with you @afercia here. All I'm saying is that if using the component in every single block we ship in core isn't setting the precedent already that this is how one should build stuff then what is?

Well, the fact that this component is now widely used for many blocks doesn't automatically implies it provides a good user experience. Rather, I would argue the real question is: should the editor recommend to use a component that is argued upon for its confusing and less than ideal UI?

I would agree we should prioritize a lot of these enhancements before 'recommending' this component.