Data views: quick-editing

[jameskoster]

Table and Grid layout

In these layouts, we can use the same UI as the full-screen editor to toggle the visibility of the Inspector panel:

table-quick-edit.mp4

List layout

In List layout it feels important that the preview remains visible. Instead of exposing a dedicated panel, the Inspector contents are loaded into the content frame via drilldown pattern:

list-quick-edit.mp4

---

This feature would be equivalent to the quick edit experience in wp-admin:

Original issue

Inline editing has considerable overlap with quick-actions (https://github.com//issues/55096). For example most quick-actions for pages (https://github.com//issues/55628) could also be accessed by clicking on values in the table directly. So for the initial implementation we might reuse where possible. Hopefully this mockup captures that:

Incidentally the "Author" menu in the above concept should be virtually the same as the one that has already been implemented for filtering, so hopefully some legwork is already done 🤞 :

One exception we might make straight away is boolean values, e.g. whether comments are enabled or not. In this case the cell can probably contain a Toggle.

[jameskoster]

Noting that the work in #59689 can unlock using the Inspector as a bulk/quick edit interface:

[seifeldinio]

I've explored this solution for quick-editing within the inspector panel, here's the prototype for it:

demo.mp4

Mockups:

Single Page Selection

Focus on Edit Modal: When a user clicks on an option to edit, the table view lessens in opacity to focus on the edit modal. This guides the user's attention with a dark overlay, allowing them to focus on the content at hand.

Editing options:

Multiple Page Selection

Editing options for multiple page selection:

Quick Editing for Media Files

A similar quick-editing approach can be applied to media files

Would love to hear your feedback on this!

[jasmussen]

This is looking pretty solid. A couple of details to figure out across the inspector itself, but high level that seems to capture the instincts I've had for this interaction. Would be good to hear from others in @WordPress/gutenberg-design as well!

[jasmussen]

Took a quick stab at revisiting this. Here's screenshots of what's experimentally shipping:

Noting there, by the way, that there's a horizontal scrollbar, which there probably shouldn't be.

The pieces are increasingly present, but some polish is missing. Here's a quick mockup:

Mockup shows the quick edit panel very much resembling the page inspector, as well as a version with multiple items selected. Main changes to what's shipping in trunk:

• Changed the QuickEdit width to be the same as that of the page/template inspector. The value in having this be that much wider is unclear, and matching the width also helps the understanding: this is conceptually (and partially in practice), the same panel.
• Showed the regular Featured Image control. Since you'd only see this when you have a single item selected, it's unclear that this needs to be different.
• Changing a few metrics, notably the inner padding, and the ensuring the main title aligns vertically with the data view title to the left of it.

What do you think?

CC: @youknowriad @jorgefilipecosta @WordPress/gutenberg-design

Figma.

[jasmussen]

Note, the above mockups are intentionally based on the same work and instincts as these.

[youknowriad]

Looks good, I think some things still need to be thought about properly in terms of how to represent them

• the "featured image" field for instance: Current in trunk, it looks like that because it's a regular "media" field. Imagine you being able to add multiple kind of image fields to a given post (or entity). Would you want to render the image directly like that? Maybe it's ok :) we need to try it but we need to also think more generically.

• It's unclear why "Last edited" is shown there, this is not really an "editable" field is it? so for a DataForm component, it's unclear why we show this information there, Maybe we need to support "readonly" fields that can be rendered within forms. (Again thinking what this represents in a more generic way)

[jasmussen]

the "featured image" field for instance: Current in trunk, it looks like that because it's a regular "media" field. Imagine you being able to add multiple kind of image fields to a given post (or entity). Would you want to render the image directly like that? Maybe it's ok :) we need to try it but we need to also think more generically.

This was specifically a reflection of this field showing up only when you select a single item. That field currently disappears when you select multiple. Thanks for the clarification, though. How's this?

That also addresses your other feedback about last edited. Thank you!

[youknowriad]

This was specifically a reflection of this field showing up only when you select a single item. That field currently disappears when you select multiple. Thanks for the clarification, though. How's this?

It looks good, a couple of thoughts

• Why the label is on top of the field for "media" but on the side for the "rest"? We can also remove the field if needed. For clarity, all of these options are currently supported (top, side, no visible label).
• We don't have support for "mixed" values yet for bulk editing. I believe @louwie17 is exploring this but your design brings something new: the possibility to have a different "mixed" value representation depending on the field type. We might have to start without it (showing "Mixed" instead of the three images, but it's something to think about)

[jasmussen]

Why the label is on top of the field for "media" but on the side for the "rest"? We can also remove the field if needed. For clarity, all of these options are currently supported (top, side, no visible label).

Practically, it's about scannability: the Media field is a general design tool like it is for Cover, Group, Site Logo and others. The other toggles are more like key/value pairs.

[youknowriad]

In the latest mockup it feels a bit weird design wise, in the sense that "Media" can also feel on the same level as "Projects" like a title for the whole thing.

[jasmussen]

Good point, can work without that label. It's a single panel, after all.

[jameskoster]

I'm also a little unsure about this media treatment, how would you know the association between file and field if they're grouped, and how would you edit the individual fields?

My thinking was that each would be a separate field, with type = media.

The associated control could be an instance of FormFileUpload, likely integrated with the media library. That part needs some design work, but there are some rough mockups in #65333.

[jasmussen]

Mighit work, though: "Downloadable file" wrapping doesn't work for me, and if we do move it to the right, I'd remove the border around it just like there's no border around "Status", which also has an icon.

[jameskoster]

though: "Downloadable file" wrapping doesn't work for me

I don't like it either, but ultimately we don't control field names, they can be anything. This is a real example from WooCommerce. Translations are a consideration too. Perhaps we could truncate to one line, and show the full name via tooltip?

An alternative approach could be to commit to a more standard form layout / appearance, which would simplify the DataForms work quite a bit I imagine.

I'd remove the border around it just like there's no border around "Status", which also has an icon

The difference between these controls and the status button is that they're drop zones. I think it's beneficial to visually indicate that functionality somehow.

[jasmussen]

I don't like it either, but ultimately we don't control field names, they can be anything. This is a real example from WooCommerce. Translations are a consideration too. Perhaps we could truncate to one line, and show the full name via tooltip?

Oh right, thank you for clarifying. We should not elide, and there's likely an action item for folks working on the woo product to optimize labels here so they capture that particular flavor of feature (e.g. "File download" or "Download" or "File" could be a suggestion for them, if they're reading!).

The difference between these controls and the status button is that they're drop zones. I think it's beneficial to visually indicate that functionality somehow.

🤔 Indeed. ItemGroup supports this, and a preview thumbnail on the left. It becomes a bit of a mix in this otherwise "key-value pair" layout, though. Should that particular type of control be surfaced in that same grid?

Essentially this is a metadata panel, just like how Apple Photos or Adobe Lightroom have metadata panels, even while also having other very different layouts. I'll do a little digging and look at best practices across these; even each key/value pair is metadata, they are definitely different type of metadata, each of which might need its own affordances.

[jameskoster]

We should not elide, and there's likely an action item for folks working on the woo product to optimize labels here so they capture that particular flavor of feature (e.g. "File download" or "Download" or "File" could be a suggestion for them, if they're reading!).

I agree we should encourage plugin authors to use shorter field names where possible, but forcing them work around one specific UI feels like an overreach to me. Especially as that UI might change in the future. There will undoubtedly be situations where long field names cannot be avoided, or translations cause them indirectly. I think it would be better to find a design that adapts elegantly, if we can.

It becomes a bit of a mix in this otherwise "key-value pair" layout, though. Should that particular type of control be surfaced in that same grid?

I see what you mean. I don't think the established convention is a great fit here though; the button would show the file name, and on click it would open a popover containing the UI to replace, remove, etc. That feels unnecessarily convoluted to me.

Worth noting we already have a mixture of behaviors in this 'panel' layout. In this example you can see that booleans appear as a toggle. Maybe it's okay for media fields to skip the popover?

To be honest I don't mind what is shipping, it just needs a label:

featured.mp4

[jasmussen]

There will undoubtedly be situations where long field names cannot be avoided, or translations cause them indirectly. I think it would be better to find a design that adapts elegantly, if we can.

I'm not sure what you're proposing here, is the eliding adapting elegantly, or do you mean a different UI altogether? In the case of this metadata I don't think it's unreasonable to list it like this, though as noted, I think there's wiggleroom in how different types of metadata gets listed, where some can be key/value pair style, potentially there's room for other tools. In fact I could argue: that is what's shipping, it's a different control for what isn't a key/value pair. I'm here for that. But also to clarify, I don't think the wrapping is fundamentally problematic, if it wraps, it wraps, and this is handled. It was more a matter of: if that particular string came from core, we have an opportunity to do better. Small detail.

[jameskoster]

I don't think the wrapping is fundamentally problematic, if it wraps, it wraps, and this is handled

Agreed :)

[youknowriad]

Can you do a quick TLDR of the discussion and add a quick todo list item to the issue description to clarify what's missing?

[jameskoster]

We were discussing how to treat media fields. Long term I feel they should probably render a comprehensive upload/dropzone component, but given we don't have that yet I think we can run with what we have. We just need to add a label. Whether that appears above or to the left of the control doesn't make too much difference imo.

Though if we go with the row orientation I'd adjust the label to "Choose image" to fix the eliding.

---

Then there was your question about whether to display "Last edited" given it isn't a field, which we didn't discuss :) A couple of ideas;

1. Could DataForms support a Summary property which would be output above the form?
2. Change the revisions field, so that instead of showing 'Revisions: $count' it shows 'Last edited: $date', and clicking $date takes you to the revisions screen.

[youknowriad]

Could DataForms support a Summary property which would be output above the form?

It could but if it's above the form, why should it be inside the component, it can just be outside but in this case, it's not above the form, it's within a form in a special position. IT looks more like a "readonly field" than a summary to me.

Change the revisions field, so that instead of showing 'Revisions: $count' it shows 'Last edited: $date', and clicking $date takes you to the revisions screen.

What does "editing a revision" mean. For me even that one is more of "readonly field" regardless of how it's rendered.

---

My question stands though, It would be cool to write down a todo list of the "mandatory things" before we can move this out of experimental.

[jameskoster]

It could but if it's above the form, why should it be inside the component

The main reason to make it part of the component is to ensure consistency, and easy updates in the future (maybe we want to change the spacing or whatever). But I agree it's fine to say it's outside the component for now.

For me even that one is more of "readonly field" regardless of how it's rendered.

You're saying both Revisions and Last modified should live outside of the form? That makes sense to me, but suppose it will require a small update to the existing document inspector since the revisions link currently lives in the 'form' section:

My question stands though, It would be cool to write down a todo list of the "mandatory things" before we can move this out of experimental.

Sorry I didn't realise you were asking generally :) In terms of functionality the main missing piece I see is bulk editing, but I know there are several PR's in the works to address that.

There are some design details we need to work out, but I don't know that they're blockers. The biggest one is better connecting the dialog to the form. Something about this pattern doesn't work as well outside the editor as it does inside:

Some spacing adjustments (panel width/padding) might help, but I'm curious about trying the more traditional form layout.

[jasmussen]

Some spacing adjustments (panel width/padding) might help, but I'm curious about trying the more traditional form layout.

It's a thing we can try, though so long as the appearance of the QuickEdit panel is the same (fundamentally) as that of the page inspector in the full editor, improvements we make affect both of them. At least in a systems sense, so it might make sense to take those two, together, as far as we can before starting to diverge. That's mainly an argument for width/padding changes first. Also perhaps scrimming the main canvas when opening a flyout. I think @auareyou also made a suggestion for the whole row itself to be a clickable button for the flyout, and having some sort of highlighted state when it opens being a benefit for both cases too.

Finally, there are some subtle pieces that seem missing between these two:

• It should just say "Status", not "Status & Visibility" (and even if it did say the latter, it should be "Status & visibility" as we use sentence case)
• The order is a bit off, with Author higher in this list than in the page inspector.
• Date works better when top-aligned, and the date itself wraps more nicely when the width of the overall panel is 280px.

The main argument I've heard for being more close to a form, is that it saves a few clicks. But in most of these cases, it really doesn't, as these are dropdowns or popovers. It's really only "Slug" that would save a click, if it was an input right here.

[jameskoster]

It's really only "Slug" that would save a click, if it was an input right here

Also Author, Date, Template, and Discussion. It's also easier for a form layout to adapt to different sizes which will be important if this panel ever becomes resizable in the future. The current format works less well at different widths, feeling too spaced out when wider, or running into wrapping issues when narrower.

Still, I agree we should explore how the existing design can be refined for this context. Making the whole row a single button has been suggested in the past as an a11y improvement so that sounds good to me. Here's a mockup, including the scrim idea and updated width/padding to match the Inspector:

row.mp4

If we're not confident about the dialog, modals could be another option:

modal.mp4

Or even drilldowns, though I suspect this would be trickier to implement as part of the component:

drilldown.mp4