List View: Tweaks to improve usability, visual feedback, and keyboard behaviour

[andrewserong]

The list view frequently comes up as a feature that folks both love, and also find frustrating or challenging to use. There are already a number of issues that address aspects of the list view's usability. The purpose of this issue is to track some of these issues, and provide a list of related issues that, grouped together, should hopefully help improve the overall usability of the list view.

For prioritised tasks for WordPress 6.6, see #60099

---

Exhaustive list

Outstanding bugs to address

• Gutenberg List View has limits on the length it can display #41613
• Column blocks (e.g. 30) are not displayed correctly in a group block #42031
• List View: Fix performance issue when selecting all blocks #54900
• List View: Stale translate3d styles stick to row items leaving stray borders after dragging blocks #56409
• List View: Dragging a large number of blocks at once throws the windowing logic #56361
• List View: Stale windowing logic when switching between content and template in site editor when no content block is present #56360
• Block Settings Menu: Unintended horizontal scrollbar in FF on Windows 11 #60355

Improving drag-and-drop and related visual issues

• Come up with a solution for the issue where the drop indicator blends in with the color of selected blocks List View: Ensure visibility of drop indicator over selected items #52917
• Explore allowing dragging on a collapsed block to expand it: List view drag and drop: expand collapsed parent blocks when dragging over them #33684
• List View: Make drag chip resemble list item, and displace blocks when dragging #56539
• List View: Unfold whole container on (Right-/Double-) Click or new >> Icon #60242

Improving interactions using the keyboard

• Allow blocks in list view to be deselected by keyboard: List view: Impossible to deselect all blocks using the keyboard #48462
• Allow keyboard shortcut to duplicate blocks to work in the list view
• Allow CMD / CTRL + A to select all blocks
• Allow CMD / CTRL + C to copy blocks
• List View: Explore adding a keyboard shortcut to collapse other list view items #59936
• Allow keyboard shortcuts for inserting a block before or after the currently focused block in the list view
• Allow Page Up / Page Down to select blocks in addition to the existing Home / End support
• When shift-selecting blocks nested within a selected parent block, it should be possible to update the selection (currently no change occurs as the parent block being selected causes all children to be treated as though they're part of the selection)

Visual issues and tasks

• List View: Display image thumbnails #46015
• List view: Add image thumbnails to additional image attribute blocks #53684
• Deeply nested lists are difficult to work with (e.g. List view: Add and handle a max-width for deep nesting cases #44603). One potential solution could be to explore making the list view's width adjustable as described in Make it possible to adjust the width of the List View and/or Block Settings Sidebar #53096. (WIP PR)
• List View: Improve visual feedback on windowing logic (make it smoother) #55114
• List view: empty settings menus for non-editable items instead of a lock icon  #62352

Misc tasks related to usability

• Add right-click handling for exposing the block settings menu: Hijack the browser's right-click contextual menu when right-clicking on any part of the items in the FSE / Gutenberg post's blocks hierarchy list view sidebar #40287 — earlier exploratory PR: List View: Add right-click behaviour to open block settings dropdown, and add right click overrides editor setting #41041 — current WIP PR: List View: Allow right-click to open block settings dropdown, add editor setting #50273

[jameskoster]

When beginning to drag a block, it is immediately hidden from the list view, causing the area to jump. Explore whether greying out the currently dragged blocks would help with interacting with the list view.

I wasn't able to get it working for expanded parents (otherwise I'd open a PR), but I think this would be a win. It makes List View feel much less fragile imo.

drag.mp4

[andrewserong]

but I think this would be a win. It makes List View feel much less fragile imo.

Agreed, thanks for showing the quick demo! I'm happy to have a go at it once a couple of my WIP PRs have advanced a little further 👍

[richtabor]

but I think this would be a win. It makes List View feel much less fragile imo.

I think so too. The only bit I'd consider adapting is the grayed-out not maintain the accent color.

[andrewserong]

Update: I'm just refreshing this issue now that WP 6.3 is out, and to highlight some of the issues that could be good to tackle for WP 6.4. With the issue description now updated, for posterity, below is a list of some of things that made it into 6.3:

A non-exhaustive list of things that made it in for 6.3

Improving drag-and-drop and related visual issues

• Before attempting to resolve how specific a user needs to be in dragging a block, it would be good to work out how to allow dragging to all levels of the block hierarchy, or at least one level up (e.g. drag to next parent): List view drag and drop - make it possible to drop at all levels of the hierarchy #33678 — WIP PR in List View: Allow dragging to all levels of the block hierarchy #49742
• Once that's resolved, we could then expand the area in which dropping in the list view is allowed, so that it's easier to quickly drag to the top or bottom position of the list view: Ability to drag blocks into the whitespace between the title and content, and content and bottom of screen #32438 — PR in List View: Allow dragging outside the immediate area by passing down a dropZoneElement #50726
• When dragging into a collapsed group block, currently blocks are inserted at the beginning of innerBlocks. Explore whether it is more intuitive for a user for blocks to be appended rather than prepended. Consider changing the order of nested items added by drag n drop in the list view, so that dragged items are added to the bottom of created components. #50716 (comment)
• When beginning to drag a block, it is immediately hidden from the list view, causing the area to jump. Explore whether greying out the currently dragged blocks would help with interacting with the list view. List View: Explore whether greying out the currently dragged blocks would help with interacting with the list view #50156
• When dragging blocks, currently selected blocks render their text color as black instead of white, which looks unexpected.

Improving interactions using the keyboard

• Once blocks can be deselected by keyboard, explore allowing blocks to be deleted by keyboard: Deleting multiple blocks from list view #49087
• Once the above are resolved, close out: List View: Multi-select follow ups (de-selecting blocks, accessibility wording) #39671

Resolved tasks

The above features were implemented across the below PRs:

• ListView: Try showing blocks that are dragged (no longer hide them) #51724
• ListView: Update drop indicator line positioning to support rtl languages #51284
• [ListView] Allow deleting blocks using keyboard #50422
• List View: Append when dragging into collapsed blocks #50936
• List View: Allow dragging outside the immediate area by passing down a dropZoneElement #50726
• List View: Allow dragging to all levels of the block hierarchy #49742
• List View / Block Draggable: Fix scroll to top issue when dragging the second last block in the list #50119
• List View: Update drop indicator width to be aware of scroll containers #49786
• List View: Update drop indicator line to be 4px high with a white border #49462
• List View: Allow dragging underneath collapsed non-empty container blocks #49390
• Group Block: Allow blocks to be dragged onto it in its placeholder state #49361

What's next?

I have updated the issue description with tasks that I think would be good to work on next. It's likely that not all of these will make it in for 6.4, but IMO they're all good tasks to look into. First off, image thumbnails have been added to the list view in #53381, and next up I'm planning to look into a couple of tricky bugs related to the windowing logic (#41613 and #42031)

Note: this issue is intentionally non-exhaustive, and there are plenty of other tasks with the List View label not covered here. If there are any major ones that folks think belong in this list, though, feel free to drop a link here!

[annezazu]

@andrewserong if possible, mind updating this issue with 6.5 in mind? It would help pull together PRs and organize efforts for the 6.5 board for the release squad ❤️

[andrewserong]

Thanks for the ping @annezazu! I've updated the issue description with a section for prioritised tasks for 6.5 and a list of tasks that have already been completed. Most tasks for 6.5 have been completed, in particular adding right-click support and making it clearer that blocks can be dragged.

The two outstanding tasks for 6.5 are ones that I have WIP PRs for. There's dragging over a collapsed block to expand it (WIP PR in #56579). That one's fairly straightforward to implement. The stretch goal is to improve the experience of dragging within the list view by displacing list items as we drag up and down the list. This one's more complex to implement as it changes quite a few things. I have a WIP PR for that over in #56625, and I'm hoping to get it viable for 6.5 if we don't run into any further blockers with it 🤞

IMO, the other issues here are not urgent for 6.5.

[colorful-tones]

Hi @andrewserong,

Lot's of great work here ❤️

Would you please drop an update on where you see progress for this in the WordPress 6.5 release cycle? The Editor Triage team and Editor Leads will likely need to assess whether this should continue to reside on the WordPress 6.5 Editor Tasks board, and a summary would help. Thanks!

[andrewserong]

Thanks for the ping @colorful-tones! The prioritised tasks that could make it in time for 6.5 have all been completed, so I've moved this tracking issue over to the Done column. There were quite a few PRs that made it in for this release (all linked at the top of this issue description). From my perspective the main highlights that folks might be interested in include:

• Added right-click behaviour so that users can right click on list view items to open a contextual menu for quick tasks. For folks that wish to switch it off, they can do so in editor preferences.
• List view items are now displaced when dragging up and down the list. This feature has been built in two stages: the first stage has landed in time for 6.5, but the second stage, which is to ensure the drag chip will resemble the list view item when dragged, has been punted to 6.6 as it was not in stable-enough shape in time for the 6.5 feature freeze.
• The list view displacement drag behaviour also now enables hovering over a collapsed block to expand it, making it easier to navigate dragging in lists with nested blocks.
• Keyboard shortcut improvements: it is now possible to select all blocks via the keyboard, and also to cut/copy/paste blocks via keyboard shortcuts.
• The List View now uses a drag cursor when hovering over items to make it clearer that items can be dragged.

That's pretty much it for 6.5 features, the remaining PRs were mostly small bug fixes and polish such as auto-expanding collapsed blocks in the list view when dragging in the editor canvas — those sorts of fixes can be a bit invisible since once they're in, you sort of expect that it was always that way 😄

---

I'll leave the tracking issue description as it is for now, so that it's clear which PRs made it in for 6.5. My intention is to continue working on this for 6.6, by which time we should be able to finalise a WYSIWYG drag chip and close out this tracking issue 🤞

[annezazu]

I'll leave the tracking issue description as it is for now, so that it's clear which PRs made it in for 6.5. My intention is to continue working on this for 6.6, by which time we should be able to finalise a WYSIWYG drag chip and close out this tracking issue

When you start work on this @andrewserong can we try the following? Creating an issue with the Epic tag that's specifically scoped for WordPress 6.6 and references this as the main tracking issue of overall tasks. This will help communicate more clearly what's being worked on for 6.6 and keep this tracking issue from getting too long/hard to keep track of.

[andrewserong]

That's a great idea @annezazu! If I don't get to it today, I'll open an Epic issue for the proposed 6.6 tasks next week, and tidy up the issue description for this one 👍

[andrewserong]

Update: I've edited this issue's description to remove items that landed in WP 6.5. For prioritised tasks for WP 6.6 (ones that I know either myself or someone else is planning to work on), I've opened up #60099 as an "epic" issue. Since that issue is the one for tracking tasks for WordPress 6.6, I've added that one to the 6.6 Editor Tasks project board, and removed this issue from it. If it helps folks to have this issue be on that board, too, do feel free to add it back on 🙂

To recap: this issue is still a great place to flag nice-to-haves or bigger picture issues for List View usability. I'll be using #60099 for tracking the granular tasks for WP 6.6 that I work on.

[diggeddy]

I am seeing this issue in Firefox when dropping multiple dragged items in a large list

Screen.Recording.2024-04-06.at.13.12.23.mov

It does not remove the is-displacement-down class on drop resulting in a empty row

[andrewserong]

@diggeddy thanks for reporting, unfortunately I haven't been able to replicate this. I've tested in FF and Chrome on a Mac, with both WP 6.5 without Gutenberg activated, and with Gutenberg trunk activated. My test post has 300 blocks. I do notice that after dropping blocks, the list view scroll position isn't always correct, which would be a good thing to resolve.

Can you please confirm which OS you're running, which WP version, whether Gutenberg is activated, and a little more about your testing environment? Feel free to open an issue and ping me on it if it's easier. I'd like to be able to try to replicate the issue so I can better understand where to investigate next 🙂

[andrewserong]

Update: thanks again @diggeddy, I was able to reproduce the issue in the end, and have a fix up over in #60845. Hopefully we can get it into the next WP point release.

[diggeddy]

@andrewserong awesome glad to hear that, and apologies i had not seen the previous ping.