-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refine the Save modal design in site view #49832
Comments
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". |
It would be great to explore modal and drill down, so that we can look at advantages and disadvantages of both methods. |
I want to add in this older issue. |
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? |
@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. |
Got a quick question. |
I tweaked the modal footer dimensions to be consistent with other modals and updated the OP. |
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: ![]() |
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. |
Chming-in here from #67313 thanks to @jameskoster for pointing me at this issue. Basically, the content of this modal dialog is the
While the content structure of the
As such, this is also an accessibility issue and I'd like to see some improvements here. Related: #67354 |
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 (#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.
The text was updated successfully, but these errors were encountered: