Refine the Save modal design in site view

[jameskoster]

• Makes use of regular modal patterns (title, close button, bottom-actions).
• Actions are sticky at the bottom of the modal. This may require a component-level update.
• Current context highlighted above all other changes.

Original issue

In the lead up to the 6.2 release a global save button was added to the site editor. Clicking it invokes the following modal: This is a essentially a clone of the multi-entity save panel, presented in a modal. It needs to retain the same functionality of course, but the design needs some refinement. If we stick with the modal approach then it seems reasonable to at least use conventional anatomy (title, close button, actions at the bottom, etc), and be more accessible (https://github.com/WordPress/gutenberg/issues/47885). There might be different formats to explore for the contents as well. I don't know how committed we are to the modal, it could also be worth exploring other options like drilldowns.

[jasmussen]

I don't know how committed we are to the modal, it could also be worth exploring other options like drilldowns.

The modal dialog has the benefit that it can be opened both from the save hub in the site view, and from the publish button in the edit view, and be the same interface.

One added gotcha to consider, if not design for, is revisions. We won't need them for 6.3, but at some point you should be able to make a long sequence of changes (change site title, logo, tagline, style, templates) and then schedule them to go live on a particular date, ideally even with a title for the incoming change, such as "Black Friday design".

[paaljoachim]

It would be great to explore modal and drill down, so that we can look at advantages and disadvantages of both methods. By doing so one would also gain a deeper knowledge for both methods.

[paaljoachim]

I want to add in this older issue. Improving multi-entity saving UI method. https://github.com/WordPress/gutenberg/issues/31456

[SaxonF]

Quick change here is to just use current modal patterns with actions on bottom.

One other suggestion, which ties into the save hub work, is promoting the current context to be the first thing listed in the modal. e.g. if on pages/my-page than any changes to that page will be highlighted.

[jasmussen]

Outside of some of the detail panel aspects in the background under the scrim, which are still works in progress, that modal design feels pretty good to me. Seems like we can update the main issue with this, what do you say?

[SaxonF]

@jasmussen yep fine with me. I don't think we currently have the ability to list out last modified time for each entity so can leave that off. We may also need to adapt modal to handle sticky footer unless it already handles that scenario. I'll update GH description tomorrow.

[paaljoachim]

Got a quick question. In general for modals is it possible to adjust the screen locations of where these show up to keep these closer to where they were activated? As it would be helpful to associate the initial click with the result.

[jameskoster]

I tweaked the modal footer dimensions to be consistent with other modals and updated the OP.

[jasmussen]

Based on #57470 I did a little quick work to refine this a bit. One of the pieces to consider is multi entity saving as an interface you see also when switching themes, saving drafts, scheduling, etc. To that end, it may be worth not only having the single modal across site and edit views as already proposed, but expand the range of content that can be checked/unchecked. For example, you might want to switch to a new theme, but keep your colors and fonts, etc.

To that end, here are checkboxes and a list-view-esque expand/collapse for each section of content you can save:

The style changes based on the above are fairly minimal, a darker subheading style, and no separator. We can keep the "Current page" separation if that's a strong aspect of this.

Extrapolated from that is also here a nearer term version, that might be a stepping stone in implementation:

[SaxonF]

There is an opportunity for this work to think through how post/page publishing may tie into the save modal. If a user modifies a post, and only the post, we can put far greater emphasis on publishing as the core action of the modal so you still get that sense of accomplishment.

[jasmussen]

Noticed today that for the existing Save modal, if you click in the padding of the modal, it closes it. The area highlighted in green below.

I assume this will be solved by moving this save modal to a proper modal component, but tracking here as something to capture.