ToolsPanel: Refining the component's behaviour

[aaronrobertshaw]

What problem does this address?

Now that the new ToolsPanel has been merged there’s been a few questions or concerns raised about its UX.

The plan has always been to iterate on its behaviour and polish the panel ahead of 5.9. This issue aims to collect comments or feedback from across several PRs, issues or channels and help focus the discussion around what improvements we wish to make.

Issues raised to date

1. The panel isn’t collapsible. All controls can be hidden but this means the value is also reset.
2. The majority of people using the panel for the first time expect the menu to only toggle visibility of controls, not reset them
3. Combining the concept of default controls along with the “reset all” menu item causes odd or unexpected behaviour. Toggling that control’s menu item results in it being hidden whereas the “reset all” doesn’t.
4. There is no persistence for panel display between block selections e.g. If you hide padding, deselect the block, then reselect it, the padding control will be back again.

Links to feedback / comments

• Dimensions Panel: Add new ToolsPanel component and update spacing supports #32392 (review)
• Dimensions Panel: Add new ToolsPanel component and update spacing supports #32392 (review)
• Dimensions Panel: Add new ToolsPanel component and update spacing supports #32392 (comment)
• Dimensions Panel: Add new ToolsPanel component and update spacing supports #32392 (review)
• Dimensions Support: Add SlotFill to Dimensions Panel #34063 (comment)
• https://wptavern.com/gutenberg-11-3-introduces-dimensions-panel-adds-button-padding-support-and-speeds-up-the-inserter
• Dimensions Panel: Add new ToolsPanel component and update spacing supports #32392 (comment)
• Dimensions Panel: Add new ToolsPanel component and update spacing supports #32392 (comment)

Related PRs

• ToolsPanel: switch to plus icon when no controls present in panel body #34107

Current panel demo

ToolsPanelDemo.mp4

Questions

• Does further adoption of the ToolsPanel for block support panels depend on refinements to be discussed in this issue?
• Do any current explorations around improving the Post tab of the sidebar or global styles introduce any new requirements?

---

cc/ @jasmussen @shaunandrews @mtias @paaljoachim @ciampo

I hope you don't mind the pings on this but thought it better to cast the net wide for early thoughts and feedback.

[jasmussen]

Good ticket, thank you. Thanks for trying the current behavior.

The checkbox behavior in the ellipsis menu seems to be the primary source of confusion. Let's walk through how it could work instead:

• If a paragraph block says font-size is visible by default then the user should not be able to make it disappear ever. I.e. a default panel should never disappear on reset so the behaviour of reappearing on reselect is unnecessary.
• Resetting controls should have no effect on other blocks of the same type.
• Any control the user enables (like line height) is removed when reset.
• When an attribute is set on a block (either by user or pattern) it makes the corresponding tool appear for that block only.
• The only case a user would be able to affect default controls across a block type is through the global styles UI, not the block inspector.
• “Reset all” always just restores default appearance (so only default tools render)

For global styles and in the future, a user could be able to control default panels via theme.json just like themes can. In one such case, you might want to remove all controls by default on a paragraph. If you did that, the ellipsis would be replaced with a [+] icon to add controls when you need them.

One small thing as well: the ellipsis is vertical in recent global styles mockups, so we should update it here as well.

[ciampo]

Premise: I have only been involved in the review of the ToolsPanel PR (and not in prior conversations).

To me, the main source of confusion is that the same interaction/piece of UI causes 2 separate outcomes: "visually show/hide a control", and "reset the control's value".

A better solution may be to have two clearly separate pieces of UI: one for toggling visibility, and one for resetting values. We should then only worry about making it clear to the user when a hidden control has a non-default (ie. that has not been reset) value.

[ramonjd]

One small thing as well: the ellipsis is vertical in recent global styles mockups, so we should update it here as well.

PR for that here: #34369

[ramonjd]

Thanks for all the work on this issue @aaronrobertshaw, and also for the communication and support along the way.

two clearly separate pieces of UI: one for toggling visibility, and one for resetting values.

If a paragraph block says font-size is visible by default then the user should not be able to make it disappear ever. I.e. a default panel should never disappear on reset so the behaviour of reappearing on reselect is unnecessary.

I've been thinking about how to visually express the latter, given that users would be able to toggle non-default controls, while also satisfying the former.

I know there's been a lot of thought and discussion invested already, and I don't want to derail the vision, so I'm happy for my comments to be left in the "comment" category :)

I also support decoupling the UI display reset from the control value reset. My concern has been that the dual purpose is not explicitly communicated.

Of course, I don't expect it to take folks long to work out the intention behind the controls.

Still, I empathize with anyone who has spent half an hour tweaking spacing and other properties for a design only to see those values vanish due a click in the wrong direction. And if this occurs as a result of hitting "Reset all", I wouldn't give the user any blame for not understanding why.

Changing the "Reset all" label to "Reset controls and values" would be more upfront, even if verbose.

If one of the objectives is to maximize sidebar real estate and make things easier for the user, maybe we could ask if we're tipping the boat too far in the direction of space optimization.

Along those lines, I asked myself:

• How would we communicate in the display options panel which controls may be hidden and which cannot?
• What would it look like to add a reset button in the controls?
• Is there an opportunity to be more specific in our labels?

This is just a doodle.

If the tools panel only included defaults, then the display options list and the ellipses icon would not show.

I submit that we wouldn't require a "Reset all values" functionality now, or maybe at all. It's a few extra clicks to clear multiple values for grouped controls, but I believe providing targeted and deliberate reset actions is more transparent. Furthermore it is more convenient if the user wishes to clear just one control.

the ellipsis would be replaced with a [+] icon to add controls when you need them.

I still think this is a neat idea to indicate the presence of options where non-default controls have all been hidden. (See #34107)

Regardless, it might help to get some controls working side by side (e.g., dimensions, typography and border) so folks can have a comprehensive overview of how multiple supports controls will look and operate for a single block in the editor. 🤷

Thanks for reading!

[mtias]

To reiterate a bit the considerations for these panels:

• First and foremost, reduce the weight of block tools by showing only the most important tools by default (i.e. a paragraph block might have only font-size exposed by default).
• Respect blocks needs to accommodate different default tools and use it to better communicate what a block is about.
• Allow users to dive into and tweak further attributes on demand.
• Always reflect modified attributes (i.e. if I insert a pattern, all modifications to blocks should be apparent).
• Allow default tools to be made visible or hidden globally.

We are not building a visibility toggle per se, so separating the actions would put too much emphasis on toggling visibility. Also toggling visibility off but not resetting a value would be decidedly worse — now you have modified attributes but it's not clear in the UI because they are hidden.

Currently, the scenario that is a bit confusing is using the ellipsis menu to reset a modified value from a default tool. We'd want it to reset the value but not hide the tool. That's an important affordance and would eliminate, for the most part, the need to handle an empty tools panel in the local block instance.

That means we will have items in the ellipsis menu that perform slightly different function upon resetting: one would also hide a tool, the other would not. This is a fair point to raise and one way to handle it is to group default tools together as a special unit in the ellipsis menu.

The other important consideration is the use of the tools panel in the global styles context, where a user could control what default tools a block comes with in addition to what default attributes a block uses. In this context, resetting and visibility are more distinct tools and might need a slightly different representation.

In the local block context, though, toggling visibility is just a side effect of 1) wanting to modify an attribute that is not a default 2) resetting an attribute that is not a default.

Also worth noting that resetting individual values, while a cool affordance, is not the main goal of this panel. That's why there is a more explicit "reset all". That would make the primary goals these two:

• Access non-default tools.
• Reset all attributes.

[jasmussen]

Thanks for the outline above, Matías. Differentiating between default tools where unchecking doesn't do the same double-duty as it does for non-default tools is the difficult part, but as you note, it's important here to weigh pros and cons and to optimize for the most common use case, which is less about resetting, and primarily about accessing additional design tools.

In that vein, I took a stab at a revised tools panel ellipsis menu, with input and iconography by @pablohoneyhoney. Consider the Typography panel, which has multiple controls available, but only font-size will be shown by default in the Paragraph block:

Imagine then that we select a paragraph block, then add and customize the line height and letter spacing controls (shown below on the left), and further goes on to customize the font size (shown on the right):

• Default tools are shown at the top of the menu, separated from the rest, and with a grayed out checkmark.
• When a default tool is customized, the checkmark turns into a minus, indicating its value can be unset back to its default value, but not hidden.