-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilize ToolsPanel
component
#67954
Comments
@WordPress/gutenberg-components @youknowriad not sure who the main maintainers of this have been this far but curious about your take on this :) |
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 |
+1 The steady adoption of the component suggests we should look to stabilize the 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.
Others more knowledgable than I about the components package might also question whether a stabilized |
Yes, and probably yes. I'm afraid
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. |
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: |
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. |
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? |
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. |
Thank you all for discussing this matter. Given the effort in #67813 to use I'm going to add that we at @WordPress/gutenberg-components were not expecting this sudden focus on cc @WordPress/gutenberg-design as it seems like there are some design / UX concerns to be addressed. |
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.The text was updated successfully, but these errors were encountered: