ToolsPanel: It's difficult to close the ToolsPanel menu

[apeatling]

Prior: #41376

Description

With the changes in #40716 the ToolsPanel menu now stays open when selecting a specific option. A byproduct of this is that the menu now has no clear way to be closed as previously it would close upon selection.

By clicking outside of the menu you may inadvertently select something else on the canvas, causing the sidebar state to be lost.

[apeatling]

When I use this, I naturally expect to be able to click anywhere in the browser window to close the menu. @bdurette made the same observation in the previous thread.

This seems like a no brainer to me as a first iteration. Although we don't have any other examples of this in Gutenberg outside of modals -- I would bet most users would also naturally expect to be able to do this. Trying to do this is the reason this issue has come up.

Going further we could also explore a dedicated close button within the menu in addition to being able to click away. Figma is an example of this:

[fotisps]

Close icon with close text would be a good solution in order to close each popup that could accidentally lose the state by misclicking. It also makes it clear to the user how the primary closing works rather than giving the false impression that closing only comes from clicking outside.

[jameskoster]

I naturally expect to be able to click anywhere in the browser window to close the menu. [...] This seems like a no brainer to me as a first iteration.

I agree, this feels like a good first step.

A dedicated close button already exists – re-clicking the ellipsis will close the menu. Perhaps there's something we can do to make that more obvious?

[mtias]

I'm also not sure I agree with the menu not self-closing when you select an item. Seems to be optimizing for the less common cases. Can we look at reverting that part?

[apeatling]

@talldan I think you changed the menu from self closing for accessibility reasons. Am I remember this correctly? Are there any other options here that would keep the menu self closing when selecting?

[talldan]

@talldan I think you changed the menu from self closing for accessibility reasons. Am I remember this correctly?

That's correct. The reason being that when dropdown menus close like that it results in a loss of focus.

There was also feedback on the PR that keeping the menu open is better. Previously, if a user wanted to select multiple items the only way was to keep reopening the menu.

Are there any other options here that would keep the menu self closing when selecting?

The accessibility feedback has always been that menus should stay open like this unless the act of clicking on an item deliberately transfers focus (e.g. to a newly inserted block). Perhaps focus could transfer to the newly added tool? I don't know for sure if that would be acceptable, it'd be worth getting further accessibility feedback.

A dedicated close button already exists – re-clicking the ellipsis will close the menu. Perhaps there's something we can do to make that more obvious?

The opener icon could change to an 'X'?

[jameskoster]

I think auto-closing is worth trying, assuming that shifting focus to the added tool is acceptable from an a11y perspective.

[richtabor]

There was also feedback on the PR that keeping the menu open is better. Previously, if a user wanted to select multiple items the only way was to keep reopening the menu.

Agreed. I don't think we should auto-close. It's not uncommon to enable multiple tools at a time, re the typography controls.

[richtabor]

Is this still relevant, or can we close?

[jameskoster]

Looking at it with fresh eyes, it seems the problem isn't that the toolspanel menu is difficult to close, it's that clicking on the canvas to close it will likely select a different block resulting in a context shift in the Inspector.

What if: when a popover menu is open, clicking outside only has one behavior (close the popover) regardless of what you click on? This seems to be a fairly standard practise, as seen right here on github:

(Note how clicking on the Comment button doesn't actually click it, while the popover is open).

[simonwammerfors]

I find this part of the editor UI to be quite cumbersome. Even though I'm an experienced user of the editor by now, I often accidentally select a different block trying to close those menus in the sidebar. And then I have to navigate back to where I was. Limiting the behaviour of a click outside the menu (like @jameskoster suggests above) would help a lot.

I also often experience that the selections I make in those menus don't persist if I then accidentally navigate away from the selected block. If I select a paragraph block, navigate to the styles tab and then turn on the line-height panel, but accidentally selects another block (or just de-selects the current block) trying to close the menu, then I have to repeat the process when I select the paragraph block again. A guess that's a different issue though.

[richtabor]

I also often experience that the selections I make in those menus don't persist if I then accidentally navigate away from the selected block.

Agreed. I’d expect them to persist.

[hanneslsm]

How can we move this forward? Looks like we all agree the issue exists, so here are the options:

1. Adding a close icon
2. Clicking anywhere should close the menu, instead of clicking the underlying element.
3. I'd like to add that changing the position would also help, as in Figma. See screenshot above: ToolsPanel: It's difficult to close the ToolsPanel menu #41546 (comment)

How about doing all three?

[jameskoster]

What if: when a popover menu is open, clicking outside only has one behavior (close the popover) regardless of what you click on?

This seems worth a try imo. What do you think @apeatling ?

[hanneslsm]

What if: when a popover menu is open, clicking outside only has one behavior (close the popover) regardless of what you click on?

This seems worth a try imo. What do you think @apeatling ?

In this case I'd like to add that it might be worth exploring to make the shadow a little bit bigger. This adds to the mental model we're acting on a different "layer" and the behaviour is slightly different than for the other options, like those:

This is the shadow Github uses.

[jameskoster]

I tend to agree that more 'obvious' shadows would do a better job of communicating the different 'layers' in the UI.

That said it needs to be considered holistically accounting for elements like modals, snackbars, the 'frame' in the site editor, command palette, and so on. This is most likely a separate endeavor.

[joedolson]

I have consistently found it frustrating that the ToolPanel opens directly on top of the tools it's activating. What's most natural for me is to open the tool, turn something on, and then immediately interact with the new tool. E.g., enable Line Height, then set the Line Height. Moving your focus into the Line Height tool would automatically close the ToolPanel. However, I can't do that, because the panel covers the settings.

If the ToolPanel auto closed on selection, having it cover the related tools isn't a problem; but now that it stays open, that creates a more difficult flow.

I think that adjusting the position of the tool panel to not cover the relevant tools would make this flow more natural.

It would probably also be beneficial to change the ellipse into a close icon to make it more clear that you can use it to close.

All of the problems with clicking somewhere and losing access to the tools (e.g., clicking on the canvas, focusing a block, etc.) stem from the fact that there's no way to visually distinguish between different regions of the page.

[richtabor]

If the ToolPanel auto closed on selection, having it cover the related tools isn't a problem; but now that it stays open, that creates a more difficult flow.

Downside is that you'd have to open, then select, for as many controls you want to add.

I think that adjusting the position of the tool panel to not cover the relevant tools would make this flow more natural.

That could work, though it may be too much of a disconnect putting it to the left of the sidebar (like color palette selection is currently). Worth a shot though.

[richtabor]

A couple ideas I've explored:

• Making the popover fly out to the side, like we see in Colors and Shadow UI. This makes it much more clear what's added/removed from the UI, as you're not blocking any of it.
• Removing separation of default and available tools. I don't think it's worth the extra cognitive load trying to figure out whats default, what's not. Instead the view asks "what controls do you want to see?" and "do you want to reset this control?" without having menu items shift around in the list.
• Clicking the "X" would close the panel, as well as clicking outside of the flyout (no change there).

Video — View the prototype ↗

flyout-tools.mp4

[apeatling]

I think the side menu is a completely appropriate fix for this flow issue. It's a fairly well established pattern and shouldn't be confusing for users.

[richtabor]

For reference, here's what we have today:

CleanShot.2023-10-20.at.12.28.12.mp4

CleanShot.2023-10-20.at.12.27.10.mp4

[joedolson]

I like both of those changes; removing that arbitrary separation would definitely help in cognitive load, and not covering the information you're supposed to be working with would be very helpful.

[annezazu]

I really dig this approach and it's part of what I like about how duotone works:

duotone.approach.mov

The only light concern I have is the difference between making a new option visible (what's demoed above) and acting upon a block directly (duotone approach). I'm not sure we need to reconcile the two but wanted to note.

[talldan]

I like it too 👍

It'd be good to make sure it works well on mobile. The duotone/color panels are ok on mobile, but could probably do with a little bit of polish.

[richtabor]

It'd be good to make sure it works well on mobile. The duotone/color panels are ok on mobile, but could probably do with a little bit of polish.

@talldan I have a draft PR #55785 which moves the panel over. Ideas on how I'd position it for mobile?

[afercia]

I like both of those changes; removing that arbitrary separation would definitely help in cognitive load, and not covering the information you're supposed to be working with would be very helpful.

I'd agree both changes greatly improve the general usability and accessibility of these panels.

[hanneslsm]

@richtabor With your PR #55785 this issue can be closed, right?
Also, with #64108 the discussed elevation can be tackled in future.