List View: Consider hiding some of the ellipsis menus when mass selecting

[annezazu]

What problem does this address?

When selecting multiple blocks, List View continues to show the ellipsis menu for each individual block, cluttering the interface unnecessarily. This was found during the 6.0 walkthrough.

What is your proposed solution?

Would be keen to hear from design (added the label) but it seems like it would make sense to include the ellipsis only on one of the blocks. Perhaps, to match what happens in the editor itself, the top block?

cc @andrewserong who I've seen digging into List View items!

[andrewserong]

Thanks for the ping! I think it was raised at some point during the review phase for the multi-select behaviour, but to contain scope, we just made sure that clicking on any of the ellipsis items allows making changes to the whole set (e.g. removing or grouping), rather than making any more significant updates to it.

I'd love to see what designers think — there are a couple of potential challenges:

• If the list of blocks is very long, and we only showed the ellipsis on the top-most block, then you'd need to scroll up to that block to get to the menu (not sure if that's an issue?)
• If navigating via keyboard, and it was only available on the top-most block, you'd need to navigate all the way up by keyboard to access it (which would be difficult for folks using screen readers)

I wondered if there's an opportunity for a different kind of options / control than the ellipsis menu for when multiple blocks are selected in the sidebar?

[jasmussen]

If the list of blocks is very long, and we only showed the ellipsis on the top-most block, then you'd need to scroll up to that block to get to the menu (not sure if that's an issue?)
If navigating via keyboard, and it was only available on the top-most block, you'd need to navigate all the way up by keyboard to access it (which would be difficult for folks using screen readers)

Great observations. Some quick thoughts. Here's what we have today:

A quick win could be this:

• Rounded radius only in the top and bottom corners of the selection, not on each item in between
• Ellipsis shown only on the first one.

I suspect the need to use the ellipsis menu when multi-selecting is not going to be so common that it's problematic to scroll up a bit to access it, so I think we can start without any smarts there. Speaking to the keyboard interaction problem, could we show only the first one, but still have the others, just hidden until focused/hovered?

As a longer term thing, we could make the ellipsis sticky, so it's pinned at the top when you scroll down, just like a viewport:

Note that this might require a bit of a refactor of how the ellipsis is implemented as a table-cell. The splitting of a single table-cell within a single table-row to accommodate the ellipsis caused some challenges with the radius recently. I'm not sure the best structure here, it would likely require some creative thinking. But to the point of tabbing through items: once you have a multiselection of items, you really don't need to tab through every item — to an extent, it could/should count as one item, one selection, even if it means we need to make the items inside inert when multiselected. This is a half-baked thought that needs sanity checking.

[andrewserong]

Thanks for diving in Joen!

Speaking to the keyboard interaction problem, could we show only the first one, but still have the others, just hidden until focused/hovered?

Oh, I like that idea — I think that makes the path forward to improve this iteratively much clearer 🙂
I'm not sure how hard it'll be to implement (I've made the mistake before of thinking changes to the List View will be simple), but it feels like hiding the ellipsis menu for selected items, except if it's hovered / focused, or if it's the first item in the selection shouldn't be too hard to do 🤞😄

For the border-radius problem, I wonder if we can have similar logic for if the current item is the first or last in the selection then add a classname to set the top left / top right (or bottom left / bottom right) radii, and otherwise have no radius set for selected items.

If I get a chance before I go AFK later next week, I'll have a play, but otherwise, hopefully the info might help anyone else wanting to pick this one up!

to an extent, it could/should count as one item, one selection, even if it means we need to make the items inside inert when multiselected.

When multiselected, for keyboard at least, we still need to be able to navigate within the selection and expand / collapse, or hit Enter on an individual block within the selection to select that one block to cancel out the group selection. So, I think I'd lean toward handling border radii visually via classnames rather than treating the selection as a single unit. But again, it could be fun to play with the options there!

[jasmussen]

💯 — I wonder if it would be easier — both for hover/focus surfacing of the ellipsis and the radius — if the item and ellipsis sat in a single table-cell rather than two table-cells? It can be a space-betweened flexbox. It might even make some of the eliding we have to do easier (such as when a HTML anchor is shown, or if a block title is long).

[andrewserong]

Just assigning myself to this one — I should have a draft PR up by the end of the day 🤞

[andrewserong]

I've opened up a PR in #40174 — I labelled it as a bug, since it's flagged as an issue to be resolved in 6.0 and we're nearly at the feature freeze. Hope we can squeeze through on a technicality there! 😄