-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
ToolsPanel: It's difficult to close the ToolsPanel menu #41546
Comments
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: |
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. |
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? |
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? |
@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? |
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.
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.
The opener icon could change to an 'X'? |
I think auto-closing is worth trying, assuming that shifting focus to the added tool is acceptable from an a11y perspective. |
Agreed. I don't think we should auto-close. It's not uncommon to enable multiple tools at a time, re the typography controls. |
Is this still relevant, or can we close? |
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). |
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. |
Agreed. I’d expect them to persist. |
How can we move this forward? Looks like we all agree the issue exists, so here are the options:
How about doing all three? |
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: |
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. |
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. |
Downside is that you'd have to open, then select, for as many controls you want to add.
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. |
A couple ideas I've explored:
Video — View the prototype ↗flyout-tools.mp4 |
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. |
For reference, here's what we have today: CleanShot.2023-10-20.at.12.28.12.mp4CleanShot.2023-10-20.at.12.27.10.mp4 |
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 really dig this approach and it's part of what I like about how duotone works: duotone.approach.movThe 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. |
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. |
I'd agree both changes greatly improve the general usability and accessibility of these panels. |
@richtabor With your PR #55785 this issue can be closed, right? |
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.
The text was updated successfully, but these errors were encountered: