-
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
List View: Add keyboard shortcut to collapse list view items other than the focused item #59978
List View: Add keyboard shortcut to collapse list view items other than the focused item #59978
Conversation
…an the focused item
Size Change: +1.99 kB (0%) Total Size: 1.72 MB
ℹ️ View Unchanged
|
…ist view in that context
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @jarekmorawski. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
This is pretty awesome! I know I'll appreciate this improvement as a user. I wonder if we should also add a mouse shortcut? For instance, we'd collapse all other items when I click on the chevron while holding |
While I haven't gotten to look closely at the code yet, I have given this a quick test and there does appear to be a small issue as Joen noted.
Initially, I thought it wasn't working at all for me as well, however, I did notice that if I specifically focus one of the items in the list view and then use the shortcut it behaves as expected. @jasmussen can you confirm the same behaviour using your keyboard? Screen.Recording.2024-03-20.at.6.24.41.PM.mp4 |
Oh right, yes, that fixes it. It works when a list item is focused. I would ideally like to see it working also if a list item is just selected. |
Thanks for the feedback, folks! It sounds like I'll need to add handling for when focus is in the editor canvas, but the list view is open. I think I should be able to get that to work, I'll do a little more digging 👍
That's a great idea to have a way for it to also be done via the mouse. Let's leave that aside for this particular PR so that we can focus on the keyboard shortcut on its own, but I'll make a note for us to pursue that idea in a follow-up.
"Collapse all other items" sounds good to me, I'll update. |
Just tested, also working well for me. I had more success using keyboard navigation, since the elements were focussed. 2024-03-21.11.39.08.mp4As with others, I had to focus the list element when testing with a mouse. Clicking twice to be able to use the shortcut is the same amount of clicks I'd need to use the chevron.
Is there a standard when it comes to collapsing/expanding? I had a look around at other apps and am seeing a combo of ⌥ or ⌘ + Arrow keys, or ⌥ or ⌘ + plus/minus keys. I ask because wondering if it would be useful to be able to expand as well via keyboard shortcut. If so, it might be nice to select a key combo whose shortcuts are the inverse of one another, e.g., arrow keys Or, if we allow mouse clicking on the chevron while holding ⌥ or ⌘ to expand and collapse, then ⌥ or ⌘ + Enter so that they're analogous. I dunno 🤷🏻 |
Thanks for testing!
I couldn't find a standard for expanding or collapsing the whole tree. Out of curiosity, which apps were you looking at? And was this expanding or collapsing just the highlighted item, or the entire list?
Yes, that would be useful. In the case of expanding, were you imagining a keyboard shortcut to expand all collapsed blocks? At the moment, we can expand or collapse the current block by keyboard by pressing the right and left arrow keys, but that's not quite the same 🤔. I think I'd lean toward looking at a keyboard shortcut for "expand all" to a separate PR potentially, as it might be challenging to determine whether a subsequent press of |
Update: I believe I have the keyboard short working from the editor canvas. In order to allow the keyboard shortcut there I needed to add some extra state to the Which keyboard shortcut shall we go with?The main issue now is that if you're in a rich text field and you press So, I think @ramonjd might be onto something in terms of thinking about a different keyboard shortcut to use. @jasmussen do you have any ideas for what might work? If we're allowing the shortcut from within the editor canvas, then I believe it needs to be a shortcut that doesn't conflict with characters that a user might be trying to intentionally output in that area. I've pretty much filled up my timebox for this PR for this week, but I'll continue hacking on it next week. If the Thanks again for the testing and enthusiasm, everyone! It's feeling like we'll be able to make this PR viable once we settle on a good keyboard shortcut and smooth over some of the rough edges 🤞 |
Flaky tests detected in 3cd869b. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/8370028268
|
Just another thought before I wrap up for the week: I didn't have much luck finding a standard for this kind of shortcut. All the examples I could find were for UIs where focus is already within the list view equivalent, rather than within an editor canvas (so CMD+Left/Right arrow is natural there, where it would interfere with navigating across text when used in a text field in the editor canvas). We also can't use CMD+ or CMD- as browsers use them for zoom. So, a couple of ideas:
I'll continue chipping away at this PR next week, and add in some more tests. Let me know if anyone has ideas for potential keyboard shortcut combinations to try! |
Just to be sure, is there a conflict in making ⌥L a global shortcut to collapse all other groups than the selected one, regardless of where focus is? We can certainly choose another shortcut if need be, but as this is especially useful in the site editor, I imagine going with Figma as the precedence here is a good place to start. |
⌘ + l also jumps to the address bar in Chrome
I'm pretty neutral about Alt+l - it's fine as a custom shortcut. Conversely, it's seems randomly allocated. Nothing wrong with doing what Figma does if there's a good reason to do so and it's not just Figma bias 😄 Here are some other programs that use Alt+l as a keyboard shortcut and how: https://defkey.com/what-means/alt-l The only alternative — and I'm not suggesting it's any better, only different — is to piggy back off the keyboard shortcuts we already have. So we have something close to the following: ⇧ / ⇩: Navigate between items in the list. It could be extended too: ⌘ + ⇦ / ⌘ + ⇨: This is equivalent of Home/End. Navigation to top and bottom of list. ⌘ + Shift + ⇦ / ⌘ + Shift + ⇨: Collapse or expand items or lists except focussed. ⌘ + Shift + ⇧ / ⌘ + Shift + ⇩: Expand/collapse all? |
Thanks for the continued discussion, much appreciated, and it's tricky coming up with a good shortcut!
The conflict is that
Unfortunately, these too conflict with navigating around text content within a RichText field, as those keyboard shortcuts move to the beginning and end of a line while selecting text content, or to the top or bottom of an area while selecting text content. Also, since we allow multiple block selection in the list view, ⌘ + Shift + ⇧ might be expected to select multiple blocks instead of performing a collapse/expand 🤔 So, currently the main conflict we're encountering is what happens when you're within a Paragraph or Heading block (or similar) within the editor canvas and expect the keyboard shortcut to perform an action solely within the list view. A few potential ideas:
I might have a go at "We go with |
Sounds good, thanks for digging into this! |
Update: that seems to have been pretty straightforward. In 0dc613b, I'm skipping the keyboard shortcut if we're in a text field / I believe this should be ready for review. Overall, I think |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The conflict is that ⌥L outputs a character when focus is within a RichText field
I'm skipping the keyboard shortcut if we're in a text field / contenteditable in the editor canvas.
This is working remarkably well. Thank you! 👍 👍 from this angle.
Good stuff.
|
Thanks folks! @richtabor are either of those issues blockers to landing for you? Happy to hold off on merging, if so.
I was thinking of looking into the re-opening behaviour in a follow-up as it's a little more complex to figure out when to reliably re-open, so I thought it might be easier in a separate PR.
Unfortunately I think the only way around that one would be for us to come up with a different keyboard shortcut altogether to avoid the collision. Our options here, I believe, are to go with I'm leaning a bit toward landing this in its current form and then iterating, but I don't feel strongly about it 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a passing ✅
Nested lists are collapsing as described for me. Alt + L is as good as any I guess, pending decision on Rich's feedback.
Also, obligatory video:
2024-03-26.09.49.28.mp4
Sounds good.
This particular issue will certainly come up. I noticed that Figma's command only triggers when a group is selected (rather than any child groups/items). Is that something we want to consider here? That would resolve this issue as well. |
I'm not sure how it would resolve the issue, as we're already skipping the shortcut when we're in a text field (i.e. any block with a rich text field). The |
Just double checked how it appears that things are handled in Figma, and it seems to use a similar approach to this one of skipping the shortcut if you're in a text field. I.e. if I'm editing a text area within a frame, or the text area within the layers panel, then the shortcut is skipped and 2024-03-27.15.28.37.mp4I think the main reason it's more visible in Gutenberg is that Figma being more design-based, you have to go to more effort in order to be actively editing within a text field. Since the behaviour right now is a parallel to Figma's, and there are a couple of approving reviews, I'll merge this PR in. Ideas for next steps:
Thanks again for the ideas and discussion, everyone! And of course, if the behaviour of this keyboard shortcut feels off in |
…an the focused item (WordPress#59978) * List View: Add keyboard shortcut to collapse list view items other than the focused item * Remove keyboard shortcut info from customize-widgets as there is no list view in that context * Add e2e test coverage * Try adding some state to get it working from the editor canvas * Skip keyboard shortcut in the editor canvas if the event is fired from a text field * Add a few tests Unlinked contributors: jarekmorawski. Co-authored-by: andrewserong <andrewserong@git.wordpress.org> Co-authored-by: jasmussen <joen@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org> Co-authored-by: richtabor <richtabor@git.wordpress.org>
It's just much more visible in the editor. This unexpected behavior will likely deter folks from utilizing the shortcut liberally, as it creates more work if that character is applied—especially if I failed to notice it. Just noting this. |
Totally agree! Let me know if you can think of any alternate keyboard shortcuts or other avenues to explore. Happy to continue hacking on subsequent PRs 🙂 |
…an the focused item (WordPress#59978) * List View: Add keyboard shortcut to collapse list view items other than the focused item * Remove keyboard shortcut info from customize-widgets as there is no list view in that context * Add e2e test coverage * Try adding some state to get it working from the editor canvas * Skip keyboard shortcut in the editor canvas if the event is fired from a text field * Add a few tests Unlinked contributors: jarekmorawski. Co-authored-by: andrewserong <andrewserong@git.wordpress.org> Co-authored-by: jasmussen <joen@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org> Co-authored-by: richtabor <richtabor@git.wordpress.org>
What?
Fixes #59936
Add a keyboard shortcut where
⌥L
collapses all other nested groups except the one you have selected.Why?
When navigating deeply nested list views, it could be handy to be able to quickly collapse everything other than the currently focused list view item. The approach in this PR is inspired by the behaviour in Figma.
How?
Testing Instructions
⌥L
(Option-L on Mac, or Alt-L on Windows) collapses all of the list view except for the currently focused part of the tree, when focus is within the list view.Screenshots or screencast
The new behaviour:
2024-03-19.16.05.27.mp4
The item in the list of keyboard shortcuts: