Make it possible to save changes in browse/manage view in the Site Editor

[jameskoster]

As we add more features to the browse/manage view in the site editor (#36667), a need arises therein for saving changes. For example it will soon be possible to update a navigation menu (#46436), or restyle a button, or change the site title.

At the moment saving such changes requires invoking the edit view first which is unnecessarily verbose.

There are several options we can explore:

1. A global save button which opens the multi-entity save UI
2. Per-panel save buttons that only save changes within that panel
3. No save button – all changes in the management view are auto-saved
4. Others?

It seems relevant to note (though I'm unsure whether it should affect the solution here) that some existing actions in this view are auto-saved, IE creating a new template or template part.

cc @youknowriad @WordPress/gutenberg-design.

[jameskoster]

Here are some initial thoughts for this one:

Auto-save (publish) pretty much goes against a decade of WP UX conventions, so a dedicated Save button is probably needed.

In Browse view I'm not sure the Save button can be positioned in the top right (where it lives in Edit view) because its connection to panels like Nav / Styles becomes too tenuous. It would also mean re-arranging the site hub in a way that feels like a downgrade, and unless we wanted to jumble things around more in Edit view it would also result in some lost real estate there. In short, this doesn't feel like a good direction but I'm sharing it in case it inspires other ideas:

Here's an alternative approach which keeps the site hub dimensions / behavior roughly the same as they are now:

• Edit button becomes an icon button
• Save button appears only when there are unsaved changes
• Save button produces the multi-entity save UI in a modal on click
• In Edit view the site hub is condensed, but expands again on hover

The trickiest part of this approach is figuring out what to do on mobile. If we want the site hub to be full-featured it's hard to escape a two-row situation:

These are all early thoughts, so feedback would be very welcome. I'll continue to work on this in the mean time.

[youknowriad]

What about this:

• Edit button becomes an icon but keeps its position
• A save button is added inside the hub at the right of the edit icon
• When moving to "edit" mode, the save button morphs into the current "save" button of the edit mode (in other words, no changes at all to edit mode compared to trunk aside the animation from view mode)

[jameskoster]

I don't think the morphing part will work in terms of animation. Have a button break out of the site hub boundary and fly across the entire viewport would be very strange.

But yes, perhaps it would be simplest to leave Edit view alone for now, and add a Save button to Browse view. Instead of morphing, it could just fade out between modes:

We can figure out how these two buttons become one later.

[SaxonF]

I feel like this could get quite messy mostly because we are starting to mix the idea of saving a single space/entity like a page, template or global styles, with the saving of all of them together. Combine this @jameskoster point about two save actions that do the same thing but are positioned differently and it starts to get really confusing. If this action were "publish" it would make more sense but of course that's not an option right now. It's like we are half way between Squarespace and Webflow/Framer.

What if we just didn't allow someone to leave a space without saving? e.g. If they try leave the editor, we prompt to save. In future if they try to modify site settings, same thing. Same could be done for global styles if that's ever moved into the left. Does a user ever need to save a template and a page at the same time?

Perhaps what's confusing me is that I currently view the editor/frame/browser as its own thing, which is why I also find it weird that the edit button and toolbar are detached from the frame (e.g. toolbar slides up out of screen as opposed to off the frame). 🤔

I hope that all made sense 😆

[jasmussen]

Saxon makes a good point. I would also expand a bit: when you are in this design section, the site hub is contextual to the viewport on the right. While that technically would include any changers made inside the fullscreen editor, when you are in the browse mode, all context for those changes have been lost.

So why do we need a save button in this overview mode? Because you might change navigation, or global styles. But those do not make use of the site hub. So if anything, the Save button should be outside the site hub in that case.

I don't love the following. But it illustrates the point that perhaps if we require saving before existing fullscreen, then we can make save buttons for styles and navigation contextual to each section:

[jasmussen]

Another option per discussion with @youknowriad in #47142 (comment) is to keep the button in the site hub, but make it contextual:

I don't think that necessarily works either. But it seems like we're reaching a point where either the site hub needs to contain multiple buttons and affordances, or we need to be highly contextual. Which is what I tried to do here. Working in this Figma.

[jameskoster]

keep the button in the site hub, but make it contextual

A concern with this one is that you'd be forced to leave panels like Styles or Navigation to begin editing whatever's visible in the frame. That could be annoying if you've dived deeply into Styles.

It also seems superfluous to include the panel name in the site hub, given there's the main panel heading directly below:

On balance I prefer to let the site hub do one thing – provide context (and additional actions like search in the future) for the frame.

All that to say I prefer the first idea:

• If there are unsaved changes when you attempt to exit Edit view then there's a prompt to save/discard first.
• Dedicated save buttons in Navigation and Styles panels.
  • Like in Edit view, if you attempt to leave one of these panels without saving, a prompt appears.

[jasmussen]

Yep. we'd have to disable the back button then. I agree at the moment having save buttons contextual to each subsection, and therefore in visual proximity to such section navigation, seems like the best bet. Also as far as any future settings pages go.

[youknowriad]

Personally I'm not sure I agree with different buttons. I think it introduces too much work and complexity for a design that we're uncertain about, while the alternative is simple both in terms of implementation and design.

Having separate save buttons mean any change in the sidebar (navigating back) or to the frame (switching the frame content) should trigger the "unsaved changes warning". Technically, there's no clear way to implement this. There's a lot of APIs and actions that can trigger these changes and some maybe harder to cover since it's not necessary UI actions.

Without mentioning that editing is centralized in Gutenberg, so we'd have to figure out a way to "cherry pick" what we want to save depending on which button is clicked and leave any other edits untouched (remember any plugin can trigger any edit outside of our own UI).

In other words, personally I think it's a lot of work for a design that is potentially temporary. Not saying we can't do it but I don't think it's the right tactical move.

[jasmussen]

Understood. I'll see if I (or the design group!) can't explore some more mockups for this before we decide. I think we should be careful with every single bit we add to the hub: it's easy to add, hard to remove.

[jameskoster]

Thanks for the technical details, that's good information and I can see why this wouldn't be a change to jump into until we're certain.

I think we should be careful with every single bit we add to the hub

It feels like we need to nail down the purpose of the hub before we can proceed here. My understanding is that a direct relationship exists between the hub and the frame, IE the hub indicates what is being viewed, and provides edit access. Despite the geography (which Saxon notes is a little awkward) there's no relationship between the hub and the contents of the dark side panel. This makes it an unsuitable home for a global save button imo.

Returning to the per-panel save button idea, what if we tried that design, but didn't do any complex cherry-picking or unsaved changes interrupts? IE all save buttons open the multi-entity save UI (in a modal), but the save button(s) only appear in the left-hand panel when unsaved changes are detected.

[jameskoster]

My understanding is that a direct relationship exists between the hub and the frame, IE the hub indicates what is being viewed, and provides edit access.

A follow-up thought: if this is the purpose of the hub, it makes view like this one a bit awkward:

Since the frame contents are replaced, it's unclear what the hub should display. The current implementation shows the active management area, but as you can see in the screenshot above that is superfluous because the section title is already displayed beneath the hub (and above the frame as well).

None of that is to say the hub purpose as described above is flawed, but it's important to it highlight how the rest of the design will be impacted by its behavior. We'd likely need to rethink views like template management a bit, and of course the positioning of the save button comes into play too. Worth noting this might be an opportunity to double-down on the idea that management views and the frame are entirely separate environments.

[SaxonF]

None of that is to say the hub purpose as described above is flawed, but it's important to it highlight how the rest of the design will be impacted by its behaviour

Are we 100% settled on the hub idea? I'm not confident its the right choice because of the reasons you mentioned. It will get even trickier if we ever introduce functionality like site settings that is saved separately, or even make the space hook-able by plugins.

Coming back to the point around global vs local saving though. I do think that without auto-save like Webflow, Framer or Wix, combining changes to all aspects of your site under a single save action introduces a lot of mental friction. This is compounded by the fact that "save" is also "publish" unlike the other platforms, and that there isn't a lot of consistency when moving from browse mode to edit mode (e.g. the save button moves). I just don't think The Frame paradigm works well for globally saving changes. A lot of this depends on the vision of this admin like space and how wp-admin will play into it.

This is important to get right so I want to offer a wild card which was partly explored in a previous thread somewhere. If we really wanted to continue with globally saving changes, which I'm not sure we should, then I think we need to change the UX and keep the toolbar as a persistent element across all states. This is similar to @jameskoster original concept with the black toolbar except its merged with editor toolbar.

browse-mode-sidebar.mp4

I'm still in favour of compartmentalising each save though using the existing frame paradigm we've introduced.