Bulk edit: UX improvements notes #84391

Activity

1. verofasulo commented on Oct 12, 2026

   

   verofasulo

   on Oct 12, 2026

   More actions

   So many good points here!

   Meaning, when the user clicks Quick Edit, we show them a non editable view. They then have to click or hover on each individual item to actually do any "quick" editing: (This is not quick!)

   I agree, and we've had several discussions about this. From my understanding (but @jameskoster @jasmussen please correct me if I'm wrong), the main reason for choosing a summary view over inline editing was to maintain consistency with the editor. I agree that this doesn't work well in the context of the admin, where the jobs and workflows are quite different and call for a different UX.

   I explored inline editing for Products and other surfaces. Depending on the use case, we could either group fields into sections or keep them flat. For Products, given the number of editable fields, I went with the former.

   

    

   wp-admin also includes an additional feature of being able to quickly add/remove the items you are editing. You have to back out of the edit view in order to adjust what pages or items you are editing.

   I explored this a while ago, too, looking at ways to show the selected items directly in the editing panel. The most straightforward approach was to use pills/badges, with one chip for each selected item:

   

   That said, I'm not entirely convinced we need this. I think the problem is partly a consequence of the current layout: when we open the modal, the table and its selection are hidden. With a side panel instead, the table would remain visible while editing, making it much easier to understand what you've selected and answer the question, "What exactly am I about to change?". It could also allow users to adjust their selection without having to close the editing interface.
   I'm personally not a big fan of the modal approach. I can't remember why we moved away from the side panel (was it for accessibility reasons?), but I think the previous UX worked better. I also think a wider side panel could work well here. The current 320px is quite narrow, but we used 450px in some of our PoCs and explorations, and that gave us more room to work with.

   

   ❤️React with ❤️1Reacted by Filipe Varela
2. jameskoster commented on Oct 12, 2026

   

   jameskoster

   on Oct 12, 2026

   Contributor

   More actions

   I've been saying for a very long time that we should use the regular DataForm layout (rather than the current panel layout) for the majority of quick edit fields. Let's try that!

   ---

   A dialog pattern is employed because quick edit is a modal flow; you click edit, focus moves to the UI, then you apply or discard your changes. It also simplifies the small-screen implementation.

   But nothing is written in stone! A side panel can work in theory, it just poses a lot of UX questions that are a bit tricky to answer. Questions that the modal approach inherently handles for us. For instance;

   • What happens to unsaved changes when you update the selection, are they kept or discarded? I worry it's unclear either way.
   • Similarly, if you update a field for the current selection, then add an item to the selection; does it inherit the changes you already applied, or not? Again there's no clear expectation here...
   • If you already made a selection and opened the panel, what happens if you click 'Quick edit' on another row outside (or inside) the selection—does it get added/removed to/from the current selection, or replace it entirely? Once again it's unclear what the expectation would be here.
   • What happens to unsaved changes? Is saving handled entirely by the global save button, or locally within the panel? If saving is local then what happens if you close the panel without saving?
   • How does all of this work on mobile, is it the same? If so how do we fit both the list and the panel on the screen at once? If it's different then are we adding too much complexity?
   • How would it work outside of the site editor environment (imagine for a second that something like Extensible Site Editor: explore direct Appearance entry points with the wp-admin sidebar #83364 comes to pass)?

   I think we need to find good design solutions to all these questions (and likely more) before revisiting the a panel approach.
3. oandregal

   added

   [Feature] DataViewsWork surrounding upgrading and evolving views in the site editor and beyondWork surrounding upgrading and evolving views in the site editor and beyond

   on Oct 13, 2026
4. keoshi commented on Oct 16, 2026

   

   keoshi

   on Oct 16, 2026

   Contributor

   More actions

   This is a really thoughtful conversation, and I'm happy to see so many good points come up.

   For what it's worth, my own explorations in this area also use the regular DataForm layout, so I'm glad to see it suggested as the more natural (and immediate) editing option.

   My first instinct was to agree with you, @verofasulo, that a side panel makes for a much better editing surface. But keeping the list visible and editable doesn't guarantee you can see every selected item either. Once the selection runs past the fold, or gets split across pages, you're back to guessing what you're about to change. Maybe the real gap is that the panel should do a much better job of summarizing which items are being edited, whatever container it ends up in. To be fair, the current wp-admin interface isn't great at this either.

   @jameskoster raises a lot of great points, especially around unsaved changes and being careful with data users have already entered. Those questions get much harder once the selection can change while the form is open. On top of that, there's the question of splitting the screen between the list and the panel. It's a smaller concern in comparison, but can't be ignored.

   Either way, I love seeing a full DataForm layout in the explorations above, and I'm excited about where this could go.