Repository navigation
Selection mode in DataViews #82029
Description
What problem does this address?
As noted in #64553, selecting multiple entries can be hard when the action relies solely on the checkbox control. @mirka shared concerns with this interaction before (in a ticket I can't find 😅).
What is your proposed solution?
Integrate a selecting mode in DataViews that facilitates the multi-selection. The "mode" is just an interaction-related term to introduce the idea and the difference in the UX, but it doesn't itend to be implemented as such.
Before describing the details, here are two protoypes for table and grid layouts.
Table layout
i1.interaction.table.mp4
Grid layout
i1.interaction.grid.mp4
The proposal above is heavily based on @verofasulo research and design for the bulk selection experience. The prototype pulls in that work to stress the UX. The details are:
- Selection mode is triggered when one or all entries are selected. The latter via checkbox in the layout’s header
- In selection mode
- Checkbox control of all items are visible to communicate the mode.
- The whole item becomes selectable.
- The interaction expands the shift-click selection (DataViews: shift-click range selection #79622) by showing a pseudo-state of the items to be selected.
- Item actions (visible in hover and those under the ellipsis menu) disappear. Leaving the selection mode brings them back
- The layout’s header changes as the latest design work in DataViews: improve bulk actions discoverability #80408
- In grid layout
- A grid's header is added to be consistent with DataViews: improve bulk actions discoverability #80408 work.
- PENDING: Design the interaction to set one of the visible fields as the sort criterion.
- The design of the item selected is according to DataViews: Make grid selected item styles more noticeable like table view #80095
- Selection mode is the default interaction in DataViewsPicker
- PENDING: Revisit the keyboard navigation and focus to treat the layout item as a single selectable entry/exit point.
What do you think? @verofasulo @richtabor @andrewserong @ramonjd, @WordPress/gutenberg-design, and @WordPress/gutenberg-components
Activity
ramonjd commentedon Aug 25, 2026
Just a fly by comment. Firstly thanks for prepping the demos, they're clear and explain to me why we need this. Full-card selection to me is the way, and will make selecting inordinately easier.
The "Movie title" + checkbox header is a helpful addition and makes the mode obvious.
What does removing the action ellipsis prevent/bring? Just thinking if I realize mid-selection that I want to act on just one item I'd have to exit the mode first? I guess it's not a big deal.
The controls above the dataview are doing a long of different things, e.g., deselect, plus count dropdown plus
closeand trash. I don't have a suggestion to simplify, and I see it's the same currently but just in the footer anyway, so sounds like a decent intermediary to make it more discoverable as #80408 says.I'm thinking @andrewserong will have a more nuanced opinion, especially where it overlaps with the media picker modal. Thanks!
talldan commentedon Aug 26, 2026
DataViewsPicker is largely a seperate codebase, so I don't think it would be affected by a selection mode.
If regular DataViews does get a selection mode, then the two have a lot of crossover, especially based on the videos, which really looks very similar to the picker (no single item actions, bulk actions outside the list, clicking the entire item selects it). It then might be worth considering a deprecation/removal of
DataViewsPickerin favor of<DataViews selectionMode />.andrewserong commentedon Aug 26, 2026
That's a good point. I suppose the exported component could wind up calling
<DataViews selectionMode />internally if we wind up going that route.Overall, though, I'm liking the demo videos in this issue! I think making the checkboxes in grid view only visible on hover will help with the overall appearance of the grid, too (for the DataViewsPicker case). On this point that Ramon replied to:
I don't feel strongly about it, but we have a precedent with the block editor's list view where we allow multiple items to be selected but the ellipsis to still be available. Would that be possible (or desirable) here, too? I.e. clicking the overall item could still select it, but if the user hovers over they might still be able to use the ellipsis menu?
Just adding @ntsekouras and @oandregal as an FYI here, too, since they were involved in a lot of the decision making re: the shape of DataViewsPicker.
fcoveram commentedon Aug 26, 2026
Thanks for sharing your thoughts.
The core value I see in this proposal is the clear separation of actions (what) and interactions (how) per mode. The current mix both and leans to what #64553 reports. I understand this is a big change, so that's why I'd love to hear from @WordPress/gutenberg-components folks and @jameskoster as he's coming back soon.
ciampo commentedon Aug 31, 2026
Thanks for preparing these prototypes! I like the overall direction, especially bringing the bulk actions closer to where selection starts. I have a couple of thoughts about the interaction details.
This could mean two different things:
Previous messages hinted at both, we'll have to pick the compromise that fits our needs. Regardless, whatever option we choose, entering or leaving selection mode and swapping the header must preserve focus.
I'm unsure about reusing a background-color change for the pending Shift-click range. We already use that cue for hover, focus, and selection, so "would be selected" may look like "is selected". Do we need a preview in the first version? If we keep it, it should use a distinct cue and not rely on color alone.
Dan's suggestion to converge
DataViewsPickerandDataViewsis worth exploring separately. AselectionModeboolean risks mixing click-versus-open behavior, single versus multiple selection, and choosing versus managing items. I would share the behavior internally first, then decide the public API.fcoveram commentedon Sep 1, 2026
My approach is for option 2: make the item the selection control. And hiding the interactive elements comes from the report in #64553. The shift-pressed interaction for bulk selection in table layout already uses the row as the selection area, so that same approach in grid is consistent.
I'm not very strong on this idea, so perhaps we can start with something simpler and not show the color change in the background.
Good point
oandregal commentedon Sep 4, 2026
@talldan would you be able to provide a comparison about DataViews vs. Picker as it stands? This is a different conversation, so happy to track it in a separate issue.
ntsekouras commentedon Sep 7, 2026
TBH I think DataViews are closer to mail clients like Gmail, Outlook, etc.. There, the selection mode is really similar with DataViews and actions are still showing when someone selects something.
In your videos there are few things that could be tackled separately if are helpful:
gridlayout in order to select allverofasulo commentedon Sep 7, 2026
@fcoveram , wonderful exploration! ✨
I think this works well in both grid and table views.
Re: “Item actions (visible on hover and under the ellipsis menu) disappear. Leaving selection mode brings them back,” I just wanted to add that this also removes a friction point we saw during bulk editing tests.
Having quick actions remain available on hover was misleading for most users during the bulk editing flow. They tended to click Quick edit assuming it would apply to all selected items, then got confused when that wasn’t reflected in the bulk editing drawer.
In grid view, this also helps mitigate the interaction issue we noted in this issue: the checkbox is small and hover-only, and users expected the whole thumbnail to be selectable. As one participant put it: “I expected the entire picture to be a selection option, not just the small square.”
talldan commentedon Sep 8, 2026
I haven't kept track of everything that's happened in DataViews. I think it might be better to ask an LLM this question.
fcoveram commentedon Sep 8, 2026
Thanks @verofasulo for that input. Interesting how the quick edit was associated with a select all action. That moves away a little bit of the Gmail and Outlook product approach.
It would be great if we can work on this in parallel with #80408
jameskoster commentedon Sep 14, 2026
This would definitely make bulk selection more comfortable. The Gmail iOS app does something similar, and I use that pattern every day.
I’m a little uneasy about hiding actions once an item is selected, though. I’m not sure it’s obvious that selection also triggers a mode switch with a different set of behaviours.
What’s the main motivation for hiding the actions? If it’s to avoid nested interactive elements for accessibility reasons, I wonder whether this needs to be an explicit mode at all. Could it instead be a mouse-specific enhancement? For example, once one item is selected, clicking additional rows could toggle their selection, while row actions remain available as normal. If so I think the existing cmd+click logic could potentially be used to power this feature.
That would also mean we wouldn’t need to introduce special keyboard behaviour for a mode that (so far as I can tell) is mostly beneficial to mouse/touch users.
fcoveram commentedon Sep 15, 2026
I'm relying on the visibility of the checkboxes to indicate the mode change, from not showing checkboxes to showing them all. I'm not strongly committed to this, as hiding the checkboxes by default affects the white-space balance. In context, the empty column to the left of the title field might look odd.
This sounds good. I'm also not fully convinced about hiding actions.
When reviewing the web version of Gmail, selecting several emails, then clicking on one to see the content, and then going back, keeps the selection active. In this case, the selection mode serves a simpler purpose. But it might be good to start small and not hide the action.