Refine save flow when editing template and publishing content

[jameskoster]

As it is now possible to edit a template while drafting a new post / page, and even create a new template altogether, the resulting effects of the "Save draft" and "Publish" buttons could use some clarification in the UI.

I'd love some design explorations that include the following constraints:

• Only posts/pages can have drafts
• How/where to show the "pre publish" checks
• What happens if the user disables the "pre publish" checks
• What does "save draft" do in the different situations
• What does "revert to draft" do in the different situations
• What does "publish/update/save" do

Figma.

[jameskoster]

Matias suggested an elegant solution to this, which may only be temporary but I think makes sense for the foreseeable future:

Unless a post/page is published, it is not possible to access the template editor.

If we were to implement this change, I think the following flow is the only one that will need design attention:

• Edit published post -> Edit template -> Return to post -> Convert post to draft. What happens to the template changes in this scenario?

cc @youknowriad for thoughts.

[youknowriad]

It's not a great limitation though, I can imagine folks wanting to creating a new page and only published once they crafted its template.

I don't mind it as a start though.

[jameskoster]

I think something like this might be simplest:

save.flow.mp4

In the video above I:

1. Edit a post
2. Switch to the template editor
3. Make a change
4. Return to the post editor without saving
5. Switch the post to a draft

A dialog appears stating that unsaved template changes will be lost.

This provides users with an escape hatch so that they can save their template changes before un-publishing the post.

[youknowriad]

Worth nothing it's not just template changes, it's also reusable blocks changes, site changes...

[jameskoster]

True. I think the design can still cater to those changes as well though? The dialog would just need to be more verbose.

[youknowriad]

True. I think the design can still cater to those changes as well though? The dialog would just need to be more verbose.

It's not the design that I'm concerned about, it's more the behavior. I mean it's possible that someone wants to update a reusable block even if they want to keep the post as draft.

[jameskoster]

Wouldn't they be able to do that via the multi-entity save flow?

So in the flow above, when the browser dialog appears you would click cancel. Then click save to see which entities have been edited. Save the ones you want to, then click switch to draft.

[youknowriad]

So in the flow above, when the browser dialog appears you would click cancel. Then click save to see which entities have been edited. Save the ones you want to, then click switch to draft.

Yeah, well I guess the fact that I didn't about this make it a bit complex, isn't it?

We can start that way and see how it goes.

[youknowriad]

Actually, I feel the current behavior is a bit better, we don't discard those changes, we just don't save them.

[jameskoster]

Fair point. Neither are ideal, but I agree that current behaviour is ok.

So I suppose the only thing to do ito this issue is hide template-related links (edit/new) when the page is a draft. Again this is not ideal, but it's a starting point.

[paaljoachim]

Reading through this thread..... Makes me think we need local saves that are not tied in with the draft or published page/post. Right now the save mechanism is in general difficult to handle, as things stop up when a user unchecks one of the items that are to be saved.

Thinking out loud.
There are talks about adding a Save button to the toolbar for Reusable blocks here:
#29871 (comment)

James mentioned a way to discard needed to save here (Which can also be used for Reusable blocks.):
#31043 (comment)

For Reusable blocks had a huge change in WP 5.7. Which also made it not possible to discard a save.

In relation to page templates. Should a save button be added locally inside the page template area?

Right now it should be easy to discard any area the user does not want to save. We need to figure out a better way to handle these things.

[jameskoster]

My (perhaps incorrect) assumption is that actively discarding changes for a specific entity will be a fairly uncommon activity for most users. So for now, in order to be consistent across entities I feel like it would be ok to add this affordance to the multi-entity-save flow, if we do indeed need it.

I shared a design for that here.

[hedgefield]

I think discards would be used more than we think. I was playing around with the site editor earlier today and tried some different things for the global styles. I ended up not liking any of the changes and wanted to reset. Now luckily the global styles panel has a reset button, but I think other elements would benefit from such a thing too, centralized in the changes panel. The idea to discard changes to templates when you exit the editor without saving works, but I fear assumed interactions like that might not be clear enough. Someone working fast might forget to hit Save and have to go back in and make changes again. I'd assume any changes made are meant to be published unless the user tells us otherwise. If we centralize the controls to do so, that would help.

Now, if they have pre-publish checks disabled, that's a real problem 😅 Since the site editor is much more complex, maybe we should consider always showing the pre-publish check there.

I was also wondering whether a discard option meant the checkboxes could even be removed (or vice versa), but I don't think they could. Thinking of how Github does this - I see these scenarios:

• You have a bunch of changes and you want to publish all of them - easy, just save.
• You have a bunch of changes and you want to publish some but continue to work on others - uncheck specific changes. They are not discarded nor published, and will remain 'stashed' until you either do save them or exit the editor.
• You have a bunch of changes but want to remove some before publishing the rest - you discard some changes. They disappear from the list and their state is reset in the document. Then you save the rest.
• You want to discard everything - hit discard on everything, now there's nothing left to save, close the panel.

[jameskoster]

Good thoughts @hedgefield. I tend to agree that a "discard all changes" affordance could be useful. The challenge is where to put it?

Individual discard actions in the save flow makes some sense (although I'm still a bit troubled by the overlap with the checkbox):

But a "Discard all changes" action... not so much. Mostly because it would be gated behind a "Save" button which feels very awkward. To continue the github analogy it would be like having to click the commit button in order to discard all your changes.

[paaljoachim]

What purpose does the checkboxes have?

Brainstorming...
What if we removed the checkboxes and added Save next to the Discard text buttons?
So one can choose to select each individual element to Save or Discard. Or just click the Save button in the top.

I just happen to read the text in the top again: "Select the changes you want to save".....

[jameskoster]

The conversation here is veering off a little into broader multi-entity save territory. These are important discussions, but I'd like to circle this issue back to the op, and discuss the other topics in dedicated issues.

To re-iterate, the todo here is hiding the "new" and "edit" template links when the post / page is a draft.

[paaljoachim]

To not derail this issue. A general multi entity saving issue has been created here: #31456
The general approach could use some feedback.

[youknowriad]

I'm removing this from the 5.8 board due to the feature freeze, that said if we do add important iterations, we can still consider these case per case as part of the general polish that happens during alpha/beta.

[jameskoster]

I'm going to close this as the save flows seem to have changed a bit. Working with templates in draft posts doesn't feel as bad as it did previously, but there's probably room for optimisation. We can explore that in separate issues.