DataViews Quick Edit: Support quick editing in the list view. #64437
Conversation
youknowriad
added
[Type] Experimental
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
youknowriad
changed the title
|
Size Change: +214 B (+0.01%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
|
Neat! A couple of high level thoughts, unsure if they can be addressed here: We need to figure out the pathing when clicking the back button. If you navigate to Drafts, then quick-edit, then click Back you end up on All pages which is unexpected. It should return you Drafts. The record header should be rendered using the page It may be worth trying the settings form layout in this context. Forcing extra clicks to edit fields is pretty awkward and tbh feels unnecessary. |
This is not as easy as it seems because that component showing the title and action is the same that is used in other "quick edit" panels (table and grid) and the editor.
It sounds a bit weird that quick edit in one layout is "form" and in other layouts is "panel" no? |
There was a problem hiding this comment.
Personally I think this is good to land (just the location params fix). The heading component should be handled separately.
Regarding the design question about using the 'regular' form, I'd personally lean on keeping the panels for consistency with the rest parts of the UI..
|
Flaky tests detected in fa223c7. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10385432944
|
Appreciate it's not easy, and probably not one we can tackle here. But ideally all pages/panels use the same header component, especially when there is so much overlap between them.
The difference for me is in the flows intent. In grid/table the details panel is a secondary toggle which you might use to quickly see a summary of the selected item(s); editing remains a secondary affordance. In list layout you actively navigate away from the list to "Quick edit" or "Edit details" (or whatever we label the action as). In this scenario the form becomes the primary UI, and all the extra clicks to open popovers feels like unnecessary friction considering the user has already signalled intent to edit. If we wanted to use the panel layout then I'd probably expect the behavior to be the same as the other layouts. IE a toggle button for showing/hiding the panel rather than drilling down. In that case composing the layout becomes rather tricky because there isn't really room for another column. We'd likely have to consider options like stacking preview + panel: 
|
youknowriad
force-pushed
the
add/support-quick-edit-list-view
branch
from
431ea87
to
fa223c7
Compare
|
@jameskoster I have something locally that updates the panel to use the Page Header component, the problem is that it's a big change with potential for breakage and I would like to do it separately. |
|
We talked separately about whether the grid view should be allowed, if an item doesn't have a featured image. The argument being that that particular view is not very useful unless the item in question at least supports an image. The list view feels similar. It serves a particular purpose, to quickly preview the item you select in the first column. The interface is even optimized for it: instead of navigating to the item, you simply select it. It's not a great interface for multi-selecting. To that end, I'm not sure we should rush this feature, and particularly I'm not sure we should be changing the appearance of the quick editing panel to specifically accommodate this one. One of the things to figure out around the quick edit panel, is this empty state:
The entirely empty panel on the right doesn't feel completely solid yet. I understand there might be a case for a future media library where having that panel permanently pinned open like that can be sensible. But for the near future, perhaps it would be a better experience to add a "Quick edit" button to this bar: The flow would be: see table view, select an item or a few, click "quick edit", and then the right-most panel appears. And inversely, once you deselect items again, so does the quick edit panel close. Separately, despite my recent note that we shouldn't be referring to this feature as "Quick Edit", Matías pointed out to me that this name exists to differentiate it from the regular "Quick edit" button, which takes you into the full editor. So apologies from my end, we should be calling it "Quick edit" after all. |
|
Quick-editing seems useful to me, regardless of layout. I agree that in List layout bulk quick editing isn't practical, but I don't really see a good reason to prohibit single-item quick-editing? |
|
For me it's all about the dedicated layout it would need as part of this view. I think of it as the panel on the right, and not something that moves around. And if we were to have that here, it would be all the way on the right, a 3rd column after the preview column, and move it perhaps too far away from the selected items. |
|
I see the form and the panel as separate things. The panel is just the vessel, the form is a malleable object that can render anywhere as required. So far as I understand it this is one of the big benefits of the data forms component. In terms of flows I don't fully understand why we'd prohibit access to this form based on layout selection – they seem totally unrelated to me? Managing prominence makes sense, but removing access entirely seems heavy-handed. In the List layout the form could live in a modal, accessed from the ellipsis. A crude mockup: 
|
|
Just was testing this out today -- I see above we're going to change "Edit details" back to "Quick edit" so I wanted to underscore that as it was the first piece of the experience I was going to note as confusing. When in the quick edit view, I noticed that the modals that pop up are just so slightly overlapping in a janky looking way with the overall frame: overlap.movSeparately, I noticed that we show "View" as an option when in quick edit but it leads nowhere. What is this supposed to do? Can we remove? Otherwise, I found basic tests with renaming, duplicating, etc to work. The only point of confusion is that you can duplicate but there's no way to then quickly go see where the duplicated page went, even when you click on the notice. That's likely outside of this PR though: Screen.Recording.2024-08-15.at.11.58.53.AM.mov |
For me it's not about removing access, it's about optimizing each view to what it's already designed to optimize for. This view is already not that conducive to multi selecting, which is one of the best aspects of the quick edit tool. Combined with the layout change, I mainly worry it's technical debt that we're not sure we actually need. So I'm saying: it's fine to start without this particular feature, and then revisit it. @richtabor I know you had thoughts too. |
|
I guess we're looking at this tool differently. I agree that bulk-editing is one of the most compelling elements, but I find quickly editing single entries to be enormously valuable as well. I use it's counterpart in wp-admin all the time for changing slugs, status, etc. I just don't see the logic around restricting quick editing based on layout selection. I'd hope the tech debt would be minimal given it's the same form. |
Related #55101
What?
This PR brings the quick edit panel to the list view as well. The thing that is different compare to #55101 is that the action to trigger it is not "inline" but within the actions dropdown menu. The reason for that is that the list view only support one primary action at the moment.
Screen.Recording.2024-08-12.at.12.26.52.PM.mov
Testing Instructions
1- Enable the quick edit experiment
2- Open the pages dataviews
3- You can use the "quick edit" action in the list view