List View: Add right-click behaviour to open block settings dropdown, and add right click overrides editor setting #41041
Conversation
andrewserong
added
[Type] Enhancement
andrewserong
changed the title
|
Size Change: +363 B (0%) Total Size: 1.24 MB
ℹ️ View Unchanged
|
| */ | ||
| function ListView( | ||
| { id, blocks, showBlockMovers = false, isExpanded = false }, | ||
| { | ||
| allowRightClickOverrides, |
There was a problem hiding this comment.
I personally don't think the preference is needed to trial this. It's the kind of thing that could be added to the plugin with the goal of seeking feedback.
It'd also be good to avoid introducing new stable props as I think ListView should move towards become a stable API soon. (some discussion here - #40777)
An alternative if the preference is required could be making this an editor setting and pulling it in using useSelect.
There was a problem hiding this comment.
Thanks for taking a look @talldan! It'll be easy enough to strip out the setting.
The main reason I included it is that we don't yet have a precedent in Gutenberg (that I could find, at least 🙂) to override the browser default behaviour, and I imagined that there could be some folks that might feel strongly about whether or not it's okay to override right click. I'll be keen to hear if anyone feels strongly about it!
An alternative if the preference is required could be making this an editor setting and pulling it in using useSelect.
If we do keep the setting, that does sound like a better way to do it, it felt a bit awkward adding it as a stable prop (and all the prop drilling involved). I might not get a chance today to switch over to that approach, but can take a look on Monday.
Thanks again!
There was a problem hiding this comment.
I've moved it over to an editor setting in 8fd68db — that makes the change to ListView much neater, without the additional prop drilling 👍
Happy to remove the setting, too, if need be, but 🤞 this PR should be in a better place for gathering more feedback now. Cheers! 🙇
andrewserong
force-pushed
the
try/hijack-right-click-in-list-view-to-show-block-settings
branch
from
7ac27ce to
125c4f5
Compare
|
Please keep the setting. I believe feature specific context menus would be great but I still use browser menu to open element inspector for accessibility related stuff. Allowing users to choose is a must even if the default is to use the item specific menus for the editor, not the browser menu. Thanks. |
|
Tested well for me, but will hold off giving an approval to see if there is any more comment on the concept in general first. |
|
Thanks for confirming @alexstine! I had a feeling there would be a good reason to include the setting, and this very much confirms it. I'll keep the setting in this PR 🙂 |
andrewserong
force-pushed
the
try/hijack-right-click-in-list-view-to-show-block-settings
branch
from
125c4f5 to
051ecea
Compare
|
Hi! Thanks for working on and pushing this PR up. It's working as advertised! There's a UX problem here, but I can't help but doubt that swapping the native browser context menu with a Gutenberg one solves it universally. I don't have an alternative, but the following came to mind while testing:
I suppose I'm struggling with coming up with an alternative because I'm caught wondering what problem are we trying to solve. A UX-one fundamentally, that is, to reduce the effort required to open the context menu. Additionally, reading the issue, to accommodate the user's expectations and habitual use of the mouse. As for the effort component, the menu, at least for me, would have to appear at the place where I right-click otherwise it requires just as much effort. With regards to users' expectations, we might want to ask a few more people. I mean, it might be useful to a lot of folks to have such a feature, I don't know 😄 Also, I think I found a small anomaly. When I right click on multiple items, the context menus appear to persist for me. It doesn't happen all the time, normally after I've left-clicked on the ellipsis icon.
|
|
Thanks for testing @ramonjd! You raise excellent questions:
One of the reasons I thought adding in the setting to switch off the behaviour could be helpful, was to help those of us working on the list view to inspect it when needed! 😄
Good point — if folks think this feature is worthwhile, we could always explore seeing if we could change the position of the popover
Yes, I think so — it'd be good to gather more feedback to see if this change makes sense holistically as a part of how users interact with Gutenberg. If it's just in one place, it could be confusing (both in seeing that the browser behaviour is overridden, or that it's only overridden in one place)
Nice catch! It looks like there's something to fine-tune here — I can reproduce that reliably in the site editor, but not the post editor.
I think this is the central question to answer before spending too much more time fine-tuning this PR — is this, as a feature, a UX concern that we'd like to deal with in Gutenberg and cover, or not? Personally, I don't think I'd use it all that much myself (I mostly picked up the task as a quick hack-day like exploration last Friday to see how hard it might be to implement 😄), so I'm very happy to shelve it if folks think it isn't a worthwhile enhancement. I might ping a few more folks to see whether or not this is even something that we think Gutenberg should attempt to do (overriding browser behaviour in this way, and imposing a right-click UX in the editor). Thanks for the feedback! 🙇 |
|
I am really happy with a feature like this. It brings Gutenberg more aligned with Google Drive and that navigation style is amazing for screen readers. It is much better to context menu something than remembering tons of different interaction models per application. Might want to check this out for additional context. I think this will benefit the suggested improvements here. |
|
Thanks Alex! @mtias and / or @priethor — do either of you have any feedback on introducing a feature to override right-click behaviour (and in the list view) and how that fits into our UX strategy for Gutenberg? It doesn't look like we're overriding right-click anywhere else in Gutenberg as far as I can tell, so just thought I'd check before adding this PR to the editor chat agenda for wider feedback. I'm equally happy to continue refining this PR if there's consensus that it'll be a useful feature, or to shelve it if we don't think it's suitable to start overriding right-click at this time. Thanks, all! |
|
I think that the right click should not be hijacked from the browser. There can be all sorts of useful browser actions in the right click menu (Inspect, Page Source, Screenshot, other browser extension stuff). Not all devices have a mouse or multiple buttons on the mouse, so the interface would become inconsistent. That means more code, more documentation, and more support problems. Since you have that menu already, perhaps a shortcut key for the menu is all that is needed (although this doesn't help for touch interface). |
|
Thanks for exploring this! We held off on doing something like this before because it's a pretty significant paradigm shift that we need to be mindful of. However, being able to have contextual menus would open up so many doors for improving critical flows that are tricky to accommodate widely otherwise. It's great to hear this could potentially improve accessibility as well, @alexstine. I'm all for exploring this, but let's definitely have a way to disable it. It'd make sense to introduce a top level Accessibility group of settings (contain keyboard nav within blocks, show button labels, etc) because the changes go a bit beyond Appearance and would be easier to discover. |
mtias
added
the
[Focus] Accessibility (a11y)
|
Thanks for the feedback folks, and confirming that it's worth exploring further, Matías!
That makes a lot of sense to me, and I think would help with the visibility of the setting, particularly for folks who'd prefer not to have the browser override. I'll look into fine-tuning some of these things this week (and also Ramon's feedback on the positioning of the popover) so we can then get a better sense of how it feels to use 👍 |
…ngs dropdown instead of browser default
…t-click browser behaviour
…e prop on ListView
andrewserong
force-pushed
the
try/hijack-right-click-in-list-view-to-show-block-settings
branch
from
051ecea to
3b48415
Compare
|
Update: in 3b48415, I've had a go at Ramon's idea of anchoring the settings dropdown to the mouse cursor position when using right-click, and I think it improves how it feels to use quite considerably. Thanks for the suggestion! Here's a screengrab:
There's still some glitchy behaviour to deal with (like the menu not hiding again properly when you right click elsewhere), and I'd like to explore moving the settings to an Accessibility panel. I'll continue chipping away at this sometime next week, but just thought I'd share where I'm up to 🙂 For clarity sake: this is still very much an experimental idea, so the goal is to get the PR to a stable state where it can serve as a good proposal for how the feature might work — I'll still be happy to shelve it if folks feel like it isn't a change we'd like to land just yet. |
|
Update: I think this could still be a cool addition, however this PR is now pretty stale and trunk has since moved on from it a fair bit. I'll close out this PR now, but we can borrow things from this PR in a new PR if and when we'd like to revisit the feature. |
What?
Fixes #40287
Adds in right-click behaviour to the individual block buttons within the List View, that opens up the block settings dropdown menu instead of the browser default rick-click behaviour.
Because overriding browser default behaviour can be a contentious issue, this PR also adds in an editor setting (in the post and site editors)
allowRightClickOverridesthat defaults totrue. That way, for folks who'd like to retain the browser default behaviour, they can opt-out.Why?
As raised in #40287, in other web apps that people are used to, right-clicking an item opens up a contextual menu that is part of the app — and for those spending a lot of time in the List View this change should make it a little easier to quickly make changes, rather than having to hover over the ellipsis menu to get to the settings dropdown.
How?
allowRightClickOverridessetting in the post and site editors.onContextMenuhandler, and if the settings allow it, simulate a click on the settings dropdown when the button is right-clicked.Testing Instructions
Screenshots or screencast
Screengrab of right-click and toggling the setting: