Repository navigation
DataViews: improve bulk actions discoverability #80408
Description
What problem does this address?
One recurring pain point in usability testing was the discoverability of bulk actions after selecting one or more items.
We traced this to a few main causes:
- The actions read as plain text rather than interactive controls.
- On large screens (e.g. 1920px), the actions sit at the far edge of a very wide bar, away from where the eye lands.
- The common scenario isn't cherry-picking. People narrow to a group using search and filters, then click the header checkbox to select everything that matches — they interact at the top and expect the resulting actions to appear at the top too. Today's bottom placement feels disconnected from the selection.
- Users already expect actions at the top, both from the legacy screens and from other products.
Another thing to keep in mind: users manage items in the table view, not the grid — the only exception is media. If uncertain between two approaches, I'd recommend picking the one that suits table management the best.
Design explorations
Actions at the bottom
The most conservative option. Change the buttons from tertiary neutral to secondary neutral so they read as actionable, add a Select all button (to select items across pages), and slightly increase the bottom-bar height to fit the secondary buttons. This doesn't solve the placement problem, but the actions at least look like buttons.
Bulk.actions.-.Bottom.mp4
Actions at the top
Two variations:
Header-row swap
Swap the header row for actions when items are selected. This keeps the table compact while maintaining strong proximity between the selection checkbox and the actions. It does mean keeping a header in the grid layout too, limited to the title column for selection.
Bulk.actions.-.Header.swap.mp4
Filters exposed, bar replaces the toolbar.
A variation where the filters are exposed and the action bar replaces the toolbar/filter row, while the column header and content stay intact (the way Google Drive behaves).
Bulk.actions.-.Filter.swap.mp4
Other considerations (independent of placement)
- Tone / destructive action. A toolbar is a utility, so I'm leaning toward neutral buttons with a red Trash/Delete — that seems to give the best hierarchy.
- Button weight. Secondary over tertiary; outlined buttons read unambiguously as tappable targets.
- Select all — dropdown vs. plain text. I think a dropdown is a clean, beneficial addition: it gives us a dynamic menu that adapts to the current selection, and leaves room for clearer labels to disambiguate what's being selected (e.g. all on this page vs. all across pages).
Mobile
The current experience shows all actions as icons. On their own the icons aren't very descriptive, and the UI starts to feel busy. I explored collapsing the actions into a single button that reveals them on tap; a drop-up with labels feels the most scalable and easiest to understand.
Recommendation
Move bulk actions to the top on larger screens — otherwise they're physically distant from the point of interaction, hard to discover, and don't match the user's mental model. On mobile, given the smaller screen, collapse the actions into a single button.
Curious to know how others feel about the proposed designs.
Activity
keoshi commentedon Jul 22, 2026
This is absolutely great, @verofasulo! The DataViews system would greatly benefit from having more discoverable bulk actions.
This seems to be the most balanced one, but also the smartest implementation thanks to progressive disclosure. I've seen this model being used in other systems and really feels like the best solution.
The table header provides good orientation at first, but when a selection is made it makes total sense to switch that for contextual options. Using buttons instead of links styling also makes these feel like actions rather than copy. I even like the close icon at the very end to undo the selection and revert the UI.
Could we not force UI into specific layout options? In other words, what if the solution isn't to replace the header but instead adapt the bulk selection to whatever elements are scaffolded by the specific DataView layouts? For example, Grid view would still display bulk selection in the table footer.
This seems to give a bit more purpose to each layout option and invite developers to pick the best one for a JTBD. In a way, creating a specialization of some layouts instead of aiming for the common denominator for all. Bulk actions seem more conducive in Table view anyway, so it could be a way to prioritize view options. Potentially even offering no choice of layout if one is optimal for a certain task. I know it sounds counter-intuitive at first, but is a great reminder of "Decisions, not options".
The element in the videos seems to be a hybrid between a SelectControl and a Menu. It has a chevron indicating more options within, but it's not styled as a regular Select. I wonder if this because the options inside vary according to the selected items, and we can't provide a proper SelectControl that keeps track of the selected option.
Great stuff!
sarthaknagoshe2002 commentedon Jul 28, 2026
Thanks for the amazing design explorations here!
I spent some time today testing these concepts locally. I am inclined towards the assessment regarding the Header-Row Swap combined with layout specific behaviors.
While the "Filter/Toolbar swap" (Google Drive style) is interesting, it hides the current filter context.
The Header-Row Swap provides the best proximity for the Table view. I also implemented the suggestion to keep the Grid view using the footer bar. Since grids don't have headers, forcing a header just for bulk actions feels unnatural.
I have this implementation working nicely on my local environment. If we have consensus that this exact approach (Header-Row swap for Table + Footer for Grid + Secondary buttons) is the winning direction, I'd be happy to polish it up and open a PR for you all to test. Let me know what you think!
verofasulo commentedon Jul 29, 2026
@keoshi @sarthaknagoshe2002 Thank you both for the great feedback!
I agree. It’s the most common pattern and the one users would likely expect to see here as well. 🙂
Hmm, I’m not sure about this, to be honest. I’d prefer to keep the interaction consistent across layouts and make the experience more predictable for users: if bulk actions appear at the top, they should remain at the top. Even in the current WP Admin, if you go to the Media Library in grid view, the bulk selection controls are still positioned at the top. I also like how Dropbox approaches this by keeping the checkbox at the top in grid view, which is essentially how I shaped the grid layout in the header-swap proposal — screenshots attached (it's in Italian, hope it makes sense anyway 😆).
As you also mentioned later, I also don’t expect grid view to be used for bulk editing very often, apart from perhaps media. Table view is generally the layout users reach for when they need to perform bulk actions.
Good question. 🙂 I’m using the minimal variant, which is why it looks different from the regular one.
fcoveram commentedon Jul 29, 2026
Thanks for the ticket. Great work Veronica ✨
Although I also like the header-row swap version, I would encourage us to begin with a small changes like updating the style of buttons in footer.
Bulk selection in grid layout is certainly different that table, but given that the component needs to support different use cases, I would try to keep affordances in the same area for consistency.
That said, it would be nice to explore how the surface system from theme provider works here to outline a depth hierarchy. If I understand correctly the token approach, the DataViews + filter row surface will use
wpds-color-background-surface-neutraland the actions row will usewpds-color-background-surface-neutral-strongRegarding the popover menu to select entries not visible on the screen, menu component fits better this purpose. I’d like to hear from other folks possible a11y concerns given the label is dynamic.
The mobile version looks clean, and I like it. I’m optimistic we can reach a similar UI if we keep actions in footer.
ntsekouras commentedon Jul 29, 2026
Thanks for the great explorations!
We generally need to have in mind that such components can't be 'tied' explicitly to others based on existing core (default) usage.
For example in
Filters exposed, bar replaces the toolbar.we shouldn't expect that all consumers are the same. I guess one could even not have a toolbar and just expose the data view.So, the framing should be more about position (top, on top, below, etc..).
keoshi commentedon Aug 3, 2026
Agreed, @verofasulo! I was trying to stretch the boundaries of what would it look like if view options are not something you toggle at will, but rather purpose-built configurations for distinct goals. It could be something, but this is not the moment or the scope to discuss that, and I completely agree that consistency and expectable behaviors should still be the determining factors across all of these.
verofasulo commentedon Aug 4, 2026
Usability test results: bulk action placement
I ran an unmoderated usability study comparing two placements of the bulk-action bar — actions at the top (replacing the column header row on selection) vs. actions at the bottom (as clearer secondary buttons). 12 advanced WordPress/WooCommerce users, each tried both versions, with order counterbalanced across two groups of 6 so that seeing one first couldn't bias the second.
Actions at the top (header-swap):
Actions at the bottom (sticky bottom bar):
Key findings
Placement — top wins clearly. 10 of 12 preferred the top version, regardless of which they saw first. It matched people's mental model from the WP admin they already use ("expected at the top as usual"), rated easiest, and helps discoverability — the original problem was that bottom actions sat far from the checkboxes and were easy to miss. This also lines up with keyboard/accessibility best practices: no need to tab to the bottom of the page to reach the actions.
Select all — no clear consensus. Button vs. dropdown split participants, and several were fine with either. The dropdown was familiar to many; a few found it less discoverable. My inclination is to start with the simplest option tech-wise. @ntsekouras' exploration would help decide button vs. dropdown. To clarify the two interactions:
Grid view — selection is hard to find, lower priority. The checkbox is small and hover-only; some expected the whole thumbnail to be selectable. Worth revisiting, but most bulk actions happen in table view, and making the thumbnail selectable would change the click-to-open behavior — so I'd treat it as an open question rather than a recommendation for now.
fcoveram commentedon Aug 25, 2026
Those are great insights @verofasulo ✨ Thanks for sharing. I will use your input to connect other ideas and gather them in one design proposal.
dinhtungdu commentedon Sep 10, 2026
Update
I opened a draft here and it's testing well, I will need to polish it a bit more before opening for review.
It's EOW for me, I will do final polish and make the PR ready next Monday.
annezazu commentedon Oct 21, 2026
Thank you for landing this 🚀
jasmussen commentedon Oct 22, 2026
Plus one. Thank you!