ToolsPanel: Improve ellipsis menu with subheadings and separate reset button for default tools

[jasmussen]

The ToolsPanel component comes with an ellipsis menu. This ellipsis menu serves two purposes:

1. To make available design tools that are occasionally but not always useful
2. To clear various such properties back to their default state

This panel is in part created to allow more design tools in a legible state, without encumbering the panel with repeated "Reset" buttons. In most cases, after all, you can select "Default" from a drop-down, or select and clear a line-height value, accomplishing the same. here's what it looks like today:

For the cases where it still needs to be clearer how to reset a value back to its defaults, however, we can improve the clarity of the menu.

Shown left, a Typography panel with the default font size shown, but no value chosen. Shown right, the panel with the additional non-default Font and Appearance tools shown, including a value picked for font size. The main changes are:

• Sections have subheadings delineating default tools (always shown in the panel) and additional tools.
• The default tool is no longer a full button that gets disabled when it has no set value, instead it gets an explicit "Reset" button on the right.
• Additional tool can be cleared and removed by unchecking, just as today.

Note that these improvements do not preclude additional enhancements, but they could be a starting point. See also #43082.

[annezazu]

@aaronrobertshaw @apeatling might this be something ya'll can prioritize for 6.1 as an initial iteration/tweak, ahead of broader work on refinement in the future? I know there's a very similar discussion underway in #43082 and there was previous in the original consistency issue for design tools #43241 (comment). As mentioned by @jasmussen in the above issue, broader thought is still needed but it feels wise to take a step in that direction for now ahead of the great work being done to expand the supports available.

[talldan]

The default tool is no longer a full button that gets disabled when it has no set value, instead it gets an explicit "Reset" button on the right.

@jasmussen Using Font size as an example, does the 'reset' text need to be part of separate button, or can it be implemented as some additional text within the 'Font size' button?

The reason I ask is that the accessibility story for having two buttons on one row like that is a bit of an unknown. Keyboard navigation works using up and down arrow buttons, but this introduces more of a grid. It would definitely be easier to make it part of the same button.

However, if it is a separate button, what does clicking on 'Font size' do?

[jasmussen]

In the example shown, "Font size" was meant as a label to indicate the locked-in-place default control, so only one button in that row. Instead of that button being a minus, a "Reset" button could be clearer:

However the main motivation for this change is to avoid the reduced legibility of the button, and even the initial focus style:

A mitigation would be to improve the contrast ratio of the disabled menu item to be similar to that of the "Saved" indicator, and to ensure the focus style isn't lower in opacity:

The subheadings would also likely help. What do you think?

[talldan]

What do you think?

Those all sound like good suggestions 👍

Thanks for clarifying.

[aaronrobertshaw]

In the example shown, "Font size" was meant as a label to indicate the locked-in-place default control, so only one button in that row. Instead of that button being a minus, a "Reset" button could be clearer:

@jasmussen I'd like to get some further clarification if I may, as to what the expectations are for the default control items in the ToolsPanel menu.

At present, each menu item is a single button. That button spans the full width of the menu. So currently, the "minus" is just a right-aligned icon within a single button that includes the label text e.g. "Font size". Not an icon button with a separate label.

Is the goal to maintain the full-width button or should I be creating a new menu item component to render a label and button combo together?

After a quick play around with this today, we could get something close to what you've proposed while still using the MenuItem component and keeping all the existing keyboard navigation as is.

Screen.Recording.2022-09-16.at.5.06.50.pm.mp4

[jasmussen]

Nice! Your video above feels like a pretty solid step forward. I'd be happy to launch that one as an improvement to what's shipping. The most important aspects are legibility for the default items even in their disabled states, and the subheadings. I imagine this is also an interface that we will come back to again, so it seems like a good step forward 🙏

[aaronrobertshaw]

Ok, thanks for confirming the general direction. I'll put up a draft PR for this Monday where we can hammer out the implementation details and any component updates if required.