Improving multi-entity saving UI method.

[paaljoachim]

Various feedback on multi-entity saving method have become spread into various issues that talk about different aspects of multi-entity saving.

The current multi-entity saving method.
Clicking the Save button leads to the Save panel.

1- Here one can uncheck various options. For instance if I uncheck the header. (H should be capitalized.)
2- Then click Save.
3- Make some changes in the canvas/layout area.
4- Click Save again. The header is still seen. Along with anything else that has been adjusted.

---

Improving the Saving flow.

One idea is to add a discard option like so:

Added by @jameskoster in this isse (comment): Refine save flow when editing template and publishing content https://github.com//issues/30800#issuecomment-829990021

--

Another option is where I removed the checkboxes, added Discard options and instead added an inline Save (so one can save each individual item or click the Save button in the top to save all).

One suggestion without the additional Save option.

Associated issues:
Refine save flow when editing template and publishing content
#30800

Show save button in the Reusable Block toolbar if there are changes
#29871

Page Template: Not able to cancel save of page template.
#31043

[paaljoachim]

Additional mockups.

If the title/name of an object is long then it can wrap.

Another option would be to use the 3 dot (ellipsis) drop down.
Also touched upon in this issue:
#29871
by @critterverse Channing.

It looks like the ellipsis menu will give us some additional space in this area.

[jameskoster]

The ellipsis makes sense to me as these will be secondary actions in most cases.

I do question the need for the save action though. Isn't the duplicative of the big blue "Save" button at the top?

[paaljoachim]

We can go ahead and remove the "Save changes" in the ellipsis drop down. Like so:

The ellipsis drop down also gives us an opportunity to later on iterate with additional options.

[jameskoster]

Yeah, the "Select" affordance can potentially go in there as well.

[paaljoachim]

Clicking "Select" selects the object in the Canvas. One should also be able to click the title and automatically have it selected in the canvas area.

I am also creating a mockup removing the checkboxes, so that the user can really decide to click the 3 dots and select discard. Removing the object from the Save panel.
Currently clicking a check box to uncheck still keeps the object in the Save panel. It also shows up the next time one clicks Save.

[paaljoachim]

Here is a prototype.
Adjustments:
I removed the checkboxes. (The question that comes up should or should not the checkboxes be removed? As we have the discard option inside the ellipsis drop down instead of of needing to uncheck the checkboxes.)
Added in the ellipsis drop down which gives the option to "Select" or "Discard"
Clicking Discard removes the object from the save panel.

FSE-discard-save.mp4

Link to the prototype figma file:
https://www.figma.com/proto/Kc4ptneSCZv8pwnI3mQB8c/Multi-Entity-Saving-process?node-id=1%3A7&scaling=min-zoom&page-id=1%3A5

[jameskoster]

One drawback to this flow:

Let's say I've edited my header and my footer. I want to save the changes to the header immediately. I also want to keep the changes to my footer and continue working on it. With the removal of the checkboxes that is no longer possible.

I suppose the "Save changes" menu item in the ellipsis can help, but does that feel a bit awkward? 🤔

An inline save (like the one from Reusable Blocks) might be better.

[paaljoachim]

Good point. I am bringing back the checkboxes. Taking this adjustment one step at a time.
The focus is on adding the ellipsis drop down menu that includes the "Discard" and "Select" options.

FSE-discard-save.mp4

[jameskoster]

Since discarding is a destructive action, did you think about how we might protect the user from removing their changes mistakenly?

Lots of existing tools to consider in that regard:

• Undo button could work for discards
• A confirmation modal could appear before discarding
• A snackbar confirmation with undo action

Discarding feels similar to the "Clear customizations" flow in the site editor, so we can probably align with that.

[paaljoachim]

Since discarding is a destructive action, did you think about how we might protect the user from removing their changes mistakenly?

As discarding requires the user to first click the ellipsis menu and then selecting Discard. There are two steps required to make before a discard can be done.

Undo button could work for discards

The undo button located in the top left of the screen could as you say also work for discards. As it seems like the easiest method.

A confirmation modal could appear before discarding

It can be done, but it requires an extra click for a user to discard an object.

A snackbar confirmation with undo action

I think we need to look at the general guidelines for how snackbar confirmations are used. I am hesitant going both ways on this one.

1. It could be helpful to have a snackbar confirmation with an undo action seen for a few seconds. Giving the user the option for the specific amount of seconds to change their mind, or to later on click the undo icon top left to get the discarded option back.
2. As it is not easy to accidentally discard an object. The snackbar confirmation can also become an additional distraction.

Two things we can add.
I think what would be the route to take is making the undo button (top left) also handle discards.
+Adding a snackbar notification with a message saying something like (text link) undo the action taken. Clicking undo would be the same as clicking the undo icon button.

Discarding feels similar to the "Clear customizations" flow in the site editor, so we can probably align with that.

I am not sure what you mean with this.

[jameskoster]

I am not sure what you mean with this.

In the site editor, customised templates can be reverted:

I just checked – performing this action results in a Snackbar with undo action. So I agree it could make sense to utilise that same pattern here :)

[hedgefield]

That makes sense to me 👍 Checkboxes and Discard together enable all possible usecases of saving or not saving, and I would show a snackbar with revert/undo action after a Discard. Having to first click through a warning modal of some kind would get annoying after a while I reckon.

[paaljoachim]

It could be something like this:

1. User clicks Save button. Then decides to discard adjustments done to the Footer Part.
2. Selects the ellipsis.Then selects Discard.
3. Notification is seen "Undo discard? Yes". User has a few seconds to decide here. If they later on want to undo/revert then they would need to click the top left undo icon.
4. Footer template Part is discarded.

Multi-entity-flow-with-snackbar-notification.mp4

[jameskoster]

I would change the language in the Snackbar a bit. It should be confirmatory rather than ask a question. So instead of:

Undo discard? [Yes]

Something like:

Footer changes discarded. [Undo]

This would be consistent with other Snackbards offering an undo affordance.

[paaljoachim]

Adjusted the Snackbar language.

Multi-entity-flow-with-snackbar.mp4

Link to prototype:
https://www.figma.com/proto/Kc4ptneSCZv8pwnI3mQB8c/Multi-Entity-Saving-process?node-id=1%3A7&scaling=min-zoom&page-id=1%3A5

[javierarce]

I'd like to offer a prototype I worked on in the context of another issue some weeks ago: FSE: Allow the ability to Save Draft and Schedule changes

My prototype touches many of the functionalities listed in this discussion and adds a couple of extra things:

• Two-way highlights (from the sidebar to the canvas and vice versa).
• And undo button.
• The ability to save/discard/revert changes independently

I do think offering the ability to save or discard changes at this stage could be useful and since the user is dealing with reverting or making changes permanent.

Here's a short version of the video from the other issue:

save.mov

Link to the prototype.

[jameskoster]

Very interesting! I like a lot of this.

One part I'm not sure about is the "Undo last change" button in the save panel. I would expect the regular undo button to still work in this context, and we have the undo affordance in the snackbar, so do we need the extra undo button here?

I think I mentioned this elsewhere, but I'm also on the fence about allowing "Reset to initial state" here. It may just be the ambiguity of the language though... I can see it being interpreted both as a "Discard changes" and a "Reset to factory settings" which are very different actions. Maybe it just needs a description like the "Clear customizations" action in the site editor:

[javierarce]

One part I'm not sure about is the "Undo last change" button in the save panel. I would expect the regular undo button to still work in this context, and we have the undo affordance in the snackbar, so do we need the extra undo button here?

I hadn't noticed that the undo & redo buttons affect the changes made to the sidebar items, so I think you are right, and we don't need that new button.

And I also agree with you about the need to make the labels for those destructive actions more clear & distinctive (either through a change of text or with a description)

[critterverse]

Loving these explorations so far and can see this working really nicely in tandem with the Save button in the toolbar that's being looking into for Reusable blocks: #29871 (comment)

There were some earlier explorations around adding the Discard functionality into the block inspector within that issue, but I think incorporating it into the multi-entity saving flow that's being worked on here makes a lot more sense 😁

[paaljoachim]

It feels like for version 0.1 PR we will add the "Select" and "Discard" option into the ellipsis drop down menu.
For version 0.2 PR we can include the "Save" button into the Reusable block toolbar etc.

Then for later iterations/versions one can look into extending the ellipsis drop down, as well as other things.
At the moment it would be best to focus on the first actionable item for 0.1 version.

[Mamaduka]

I find "Select" a little confusing.

Even currently, when it's just checkbox and "Select" button, it took me a few minutes to realize what button was selecting. Pairing it with the "Discard" button might make things a little confusing IMO.

I like @javierarce's mockup where labels are more descriptive.

[paaljoachim]

We could of course chance "Select" and "Discard" to add a little more description such as "Select template" (Reusable block/Etc) and "Discard changes". It gives a bit more clarity to what the options are.

[javierarce]

@javierarce I like the prototype. One thing to consider is when unchecking an item, maybe we should surface the "discard" option more? Or maybe we need to look at what happens after updating when an item is unchecked. Should we resurface it in the post-save area for visibility?

Here are a couple of ideas:

1. Surfacing the "discard" option more for the unchecked items.

My concern with this solution is that it overexposes a destructive action. I'm also not sure if "discard" is easy to understand.

---

2. Resurfacing discarded elements in the post-save area

This solution adds an extra step to the flow, but it makes the distinction between the two main actions (saving and discarding changes) more explicit.

[javierarce]

I'm not sure about this, @paaljoachim… I think it could be interpreted as "Discard" this panel, and I feel is a bit inconsistent with the title below (Select the changes you want to save).

I also fear that some people could miss text change when they are unchecking some lower checkboxes.

I would suggest we instead do this. As it would reflect the choices the user made.

[paaljoachim]

You have some nice suggestions, @javierarce !

It is a good idea to resurface discarded areas in the post-save area. As it creates a much clearer distinction between what is saved and what is to be discarded.

[kellychoffman]

Resurfacing discarded elements in the post-save area

@javierarce - Option 2 is much more clear and draws a nice separation between the two types of actions. One thought - The "Discard all changes" looks like the main and intended action button. What do you think about adding an additional button that essentially closes the panel and allows users to more clearly take a non destructive action?

[javierarce]

What do you think about adding an additional button that essentially closes the panel and allows users to more clearly take a non destructive action?

That's a great idea.

Here's a variation of that second screen. I've simplified the interface by removing the discard links. Adding a little bit of friction through the checkboxes will probably make more sense, because of the destructive nature of the action.

Discard.and.save.mov

I've updated the Figma file with that prototype.

[kellychoffman]

@javierarce - Great iterations. I feel like the overall flow is feeling good now. Something I keep coming back to is the overall IA of this panel - how the info is organized and presented to the user and what information we surface. A couple questions that come to mind:

• Organizing information: Does grouping things by Page, Site, Template make the most sense from a user's perspective?
• Location: This isn't always obvious. For example, when you edit the site name that appears in your footer, you only see "Site, Title" and no other context. Should we differentiate things that appear across your site 100 times vs. something that only appears once?

[priethor]

Should we differentiate things that appear across your site 100 times vs. something that only appears once?

Isn't that what the Site grouping is for? As far as I understand, editing the Site title block would appear under Site, no matter if the Site Title block is inside the post content or the template. In any case, that can still be very confusing for users, we need to better indicate that changes in blocks like Site Title are global and affect the whole site (related to #33223).

Related to this and @javierarce 's great exploration:

• We can see the Post term appearing twice: as a category level and under Templates. I think renaming the category to Post Content or similar would be more explicit.
• Is there any flow where Sitewould contain more than one checkbox?
• Would it make sense to list all site-level items that have been changed, even if we don't allow for individual items to be selected? Making changes at a site level can be scary and need to be extra clear (for example, if a user edits the Site Title in the header and they expect the changes to belong to the header only, it will not be clear what is being changed at a site level).

[kellychoffman]

Isn't that what the Site grouping is for?

In theory, perhaps. In practice, its not obvious and I think we could look at generally updating the IA here.

[priethor]

Good call, @kellychoffman . Anything that can clarify what changes will affect other instances/places is extra helpful here!

[javierarce]

@kellychoffman @priethor I think we could definitely improve the IA of the sidebar by moving the items whose changes have a bigger impact to the top. I don't know why I put the template parts at the bottom, but a better arrangement could be: site > templates > local changes.

If we also improve the labelling of both the items and each section, users will understand the impact of their changes.

Here's a new version of the sidebar with the changes I mentioned.

---

Organizing information: Does grouping things by Page, Site, Template make the most sense from a user's perspective?

I think so. I'm not sure if there are other groups we could use to organize the changes.

Location: This isn't always obvious. For example, when you edit the site name that appears in your footer, you only see "Site, Title" and no other context. Should we differentiate things that appear across your site 100 times vs. something that only appears once?

+1. I think placing the global changes at the top will make that distinction more clear.

Is there any flow where Site would contain more than one checkbox?

Yes, you can also have tagline or logo

We can see the Post term appearing twice: as a category level and under Templates. I think renaming the category to Post Content or similar would be more explicit.

That makes a lot of sense.

Would it make sense to list all site-level items that have been changed, even if we don't allow for individual items to be selected?

That's interesting @priethor… what kind of changes were you thinking of? I think it would be great if we could show more granular information about the changes to the user.

[priethor]

what kind of changes were you thinking of?

Just the ones you added in this iteration, including the individual blocks/items (logo, title, tagline) 😄 Because the previous iteration showed Theresa Webb, it wasn't clear to me whether that referred to the whole site Theresa Webb or the site title alone. I find this new iteration to be much more clear, listing the site blocks instead of their content, as well as the new top-bottom ordering 💯

[kellychoffman]

Going to lock this issue as a design in that is ready for dev. "Locking" is for dev clarity and is not meant to dissuade further design contribution - open new issues or unlock if needed!

• Comment containing final design with prototype to illustrate flow here
• Figma file
• Designer to add to PR for design reviews: @javierarce

[ockham]

👋 I'll give this a stab!

[ockham]

PR for the first part (add entity descriptions, re-order entities, change panel header copy): #35933

[noisysocks]

I think let's kick this out from WP 5.9 as #36185 is blocked and we are past the feature freeze date.

[ockham]

PR for the second part ("Discard changes" panel): #36185

[adamziel]

Related: Multi-entity permission management #37489

[paaljoachim]

Could anyone give somekind of status update on this feature?
Thank you!

[annezazu]

It hasn't shifted since originally introduced. There is an additional save option built into the new dark grey sidebar in the site editor when you've edited multiple items in 6.2 that reuses the same experience.

[paaljoachim]

We are now able to see this new feature built into the grey/black sidebar which you mentioned Anne.