Multi-entity Saving: Allow the ability to Save Draft and Schedule changes

[annezazu]

What problem does this address?

Currently, there isn't a way to save drafts or schedule changes to the site editor experience. Right now, this is an option with the customizer and can be super useful when overhauling a part of the site but wanting to wait for a quieter traffic time to launch changes. Here's what it looks like in the customizer:

This came up as part of the FSE Outreach Program's second call for testing. Of note, this touches a bit on what's raised in this issue as well with saving template drafts but it felt important to separate out this concept into its own issue: #27905

What is your proposed solution?

Allow for an option to schedule changes during the saving flow in the site editor.

[jameskoster]

I believe scheduling would need to be per entity, and the UI would have to clarify that somehow. This begs a question: should it be possible to have different schedules for different entities?

[courtneyr-dev]

@coreymckrill is working on a revisions plugin/tool for Learn and likely Docs that may be useful here. https://github.com/coreymckrill/revisions-extended. It’s available for testing in Make Testing.

[coreymckrill]

My understanding is that FSE templates are actually posts of the wp_template post type, so using revisions to save drafts, schedule for later, etc. could probably work the same way the above plugin does.

[javierarce]

I've been exploring some interfaces to schedule changes and save drafts. Following @jameskoster idea, here's a version that would allow saving changes per entity.

From the sidebar, users can mark several entities to be published on a future date (or as a draft), and receive a link to preview all those changes together. The publication settings for each entity could also be managed independently.

schedule_and_draft.mov

This prototype borrows some interface ideas from this issue

Figma prototype

[jameskoster]

Nice work on a 🤯 problem @javierarce !

The "Save draft" flow gave me a moment of confusion. It may just be a labelling issue, but saving something that is already published as a draft sounds... contradictory somehow? Could there be two separate drafting actions based on whether the entity is already published?

1. If the entity is already published, there is an option to un-publish / switch to a draft status
2. If the entity is not yet published, there is an option to not publish it on save

"Discard changes" and "Reset to initial state", are these different? In this context they feel like they're describing the same action. If the reset action here is a revert (IE solving this issue) then I would question whether this is the right place to include such an action.

On a similar note, seeing the un-published changes seems like a nice addition, but I wonder about the placement. I wonder if you tried placing them in the "Template part" tab of the isolated view? That way we could present a consistent UI for this feature in template editing, isolated template part editing, and perhaps even isolated reusable block editing as well.

[jasmussen]

Great prototype, great followup comments by Jay!

I'd add that it does seem like there's potential in attaching the scheduling state as a property of each sub-item on the list that gets highlighted for saving/updating. I'd probably not use the ellipsis on hover, though — seems like the goal there is to find something more discoverable but still visually reduced.

And yes, finding a superb label for the save button seems like a separate challenge on its own, to Jay's point. Can we have multiple labels depending on the state of the document and what gets picked up for saving?

[javierarce]

My answers for @jameskoster comments:

It may just be a labelling issue, but saving something that is already published as a draft sounds... contradictory somehow

In my head the action is saying: "save the last changes I've made as a draft", but I understand what you mean. Maybe a more appropriate name could be "Mark as draft"? Or the main "Save" button could say "Publish" instead?

Could there be two separate drafting actions based on whether the entity is already published?

1. If the entity is already published, there is an option to un-publish / switch to a draft status
2. If the entity is not yet published, there is an option to not publish it on save

I think that the second action is already achievable using the checkbox, right? And, in my opinion, the first one is more complex because in order to be consistent, the option would have to be available for entities that haven't gone through the drafting phase too… and that would make it a bit confusing.

I wonder if you tried placing them in the "Template part" tab of the isolated view? That way we could present a consistent UI for this feature in template editing, isolated template part editing, and perhaps even isolated reusable block editing as well.

I didn't think about that, but I guess it would make sense to have the information about the draft/schedule status in both places.

"Discard changes" and "Reset to initial state", are these different? In this context they feel like they're describing the same action.

For me, they behave differently. After clicking in any of those options, the template in question will be removed from the list and its changes will be reverted to the previous state (Discard changes) or to the default state (Reset initial state).

I understand that the placement could be not ideal (because of the destructive nature of those options) but I think it could work. At the end of this video for an older and different prototype, I explain how this could work (the design of the popover is a bit different from the one in this ticket):

ktO67rl6xl.mov

[javierarce]

Answering @jasmussen comments here:

I'd add that it does seem like there's potential in attaching the scheduling state as a property of each sub-item on the list that gets highlighted for saving/updating.

That's a good idea, I think that could work too and it would reduce the redundancy of the column after scheduling a change or creating a draft.

I'd probably not use the ellipsis on hover, though — seems like the goal there is to find something more discoverable but still visually reduced.

I understand your concern, but on the other hand, I think that drafting and scheduling are more advanced actions that could be accessed through the ellipsis. In order to make them a little bit more discoverable, maybe we could hint at that possibility through the description on top?

[jasmussen]

I understand your concern, but on the other hand, I think that drafting and scheduling are more advanced actions that could be accessed through the ellipsis. In order to make them a little bit more discoverable, maybe we could hint at that possibility through the description on top?

Absolutely! For something that will likely be used so very rarely, it's crucial that it doesn't weigh down the interface and add mental overhead. The challenge here is that as black text each item looks entirely inert. It seems like if we are going to add some interactivity there, there should be some indication other than the description.

Could it be tiny versions of the icons we have, shown as extension of the text? I don't love these, but they sort of convey my point:

[draganescu]

This is so cool!

I'd love to have one big "schedule all changes" place/button/flow instead of having to set the same date for three to n items.

[critterverse]

I think this issue is really close to being able to be picked up by a developer based on the flow @javierarce shared in #29575 (comment).

I'd probably not use the ellipsis on hover, though — seems like the goal there is to find something more discoverable but still visually reduced.

I like @jasmussen's suggestion above and there were some nice alternatives for this shared in #29575 (comment).

Another option could be to show the ellipses in it's current placement but in a lighter gray until the row is hovered over:

saving-panel-ellipses.mov

One side note: these options all seem to work a lot better without the expanding/collapsing arrows that the individual panels have currently — they add a lot more visual noise when paired with this new persistent element and I'm not sure how useful that functionality is in this context.

[westonruter]

I believe it would make more sense (and more common) to allow the user to schedule all the changes together, rather than to have a way to schedule each separate entity separately. The Customizer's approach is to have scheduling for all of the changes being made, not separate schedules for each change. Being able to schedule each change separately feels like a power user feature that would not be used by most.

[critterverse]

I believe it would make more sense (and more common) to allow the user to schedule all the changes together, rather than to have a way to schedule each separate entity separately

Good to know, seems like there have been requests for both ways. Curious if anyone sees value in the ability to schedule by panel grouping — Site, Template, etc? Just thinking out loud because it would resolve some of the trickier aspects of this UI if we could use a single ellipses "more" menu at the top of each panel.

[westonruter]

For reference, here's a video showing the Customizer UI for scheduling all changes made in the current session:

customizer.changeset.scheduling.mov

More screenshots can be seen in the Changeset Scheduling section of New Features and Enhancements with Customizer Changesets in 4.9.

When working on the Customizer changeset scheduling feature, I don't recall there being any discussion of the need to schedule individual setting changes separately. That being said, there was actually a way to do so but still at the session level and not the setting level. There is the concept of a “Changeset Branching Mode” which allows you to have multiple pending changesets in parallel (which required a PHP filter to opt-in). So you could have one changeset that modifies the site title and schedule that for publishing and then another changeset that modifies the site tagline and schedule that separately. A reason why we didn't default to have the ability multiple changesets pending at a time is (1) there wasn't a clear user need, (2) it would complicate the UI by needing to introduce a way to manage changesets, and (3) there would be the possibility for two separate pending changesets to have conflicts in the changes that they are intending to make (which would necessitate some UI to warn users of such conflicts as well).

[javierarce]

I want to share a prototype of a global scheduler system that I created last year (it was my first attempt to solve this problem, but I ended up working on a more granular version). It's obviously a bit outdated and will also require some polishing, but maybe it can work as an alternative.

save-draft-schedule.mp4

Link to the prototype

[jasmussen]

Nice, thanks for sharing Javi!

I wonder if a split-button treatment with a dropdown chevron might work instead of the cog 🤔 — there's something about the cog being used for the inspector that trips me up a little. Something like this perhaps?

[javierarce]

Yes, that would totally work and looks much better than the cog (I guess I used it to replicate the way the Customizer does it)

[coreymckrill]

Here's a screencast of the plugin we built for WordPress.org that allows for scheduling updates to published posts, which incidentally uses the same dropdown style button:

https://d.pr/v/f2623L

[jasmussen]

Nice, thanks for sharing Corey. Definitely looks similar.

[courtneyr-dev]

I'd love to see (and may have earlier suggested) making use of this plugin when pursuing feature parity with scheduling in Customizer. It's been stable and useful for Training & Docs.

[javierarce]

I've updated my previous proposal with a split button, as @jasmussen suggested.

Screen.Recording.2022-05-12.at.17.17.17.mov

Something else I've added from the previous iteration is a warning notice in the case the user schedules a post for publication but then decides to save a draft instead.

You can find the prototype here. And here's the design.

[jameskoster]

I find saving drafts in the site editor to be a little confusing. What happens if I edit post content then save a draft, does that update the post status to draft (and unpublish it) or just store those changes somewhere? If the changes are stored, what happens when I go to edit that post, can I pull the changes in?

[mtias]

This is looking good! In the context of templates and the site editor we should avoid saying things like "this post is scheduled" because users can get confused. Expressing it as "these template updates" or "these design changes" would be better.

[javierarce]

In the context of templates and the site editor we should avoid saying things like "this post is scheduled" because users can get confused.

Oh, yes, you're totally right, I don't know what I was thinking when I wrote that 🤦‍♂️ I'll fix it.

[javierarce]

Based on the feedback I got from @shaunandrews I've made several changes to the design:

• The button now says “Update” instead of “Save”.
• The split bottom tooltip shows all the available actions with a tick next to the selected one.
• Uses the upcoming Date popover instead of dropdowns.
• The schedule and draft information sections appear on top of the list of template areas
• The checkboxes appear on the right side of the sidebar, to be consistent with some changes we are implementing

Here's a video of the new prototype:

Screen.Recording.2022-05-23.at.13.27.10.mov

And some notes about how this design presents the different saving options:

[draganescu]

This is so cool ❤️

I wonder:

• will the schedule updates feature only be available for editing templates, not when editing individual template parts?
• just checking, we assume only one set of scheduled changes for template is available at a time, right?
• I can't grasp from the mockup what happens if edit a scheduled template and it's parts, will I have to "reschedule" and just select the same date/time?

Using the post revision system there is a situation I can't figure out:

1. Edit the header in home template -> schedule
2. Edit the header in single template -> schedule

This means we need to keep two versions of the scheduled changes for the header template part, right? Or will scheduling changes for template parts in a template affect another template (unlikely)?

[javierarce]

Ah, those are great questions I should have included in my design.

will the schedule updates feature only be available for editing templates, not when editing individual template parts?

I think only at the template level, otherwise it could get very confusing and complicated to manage.

I can't grasp from the mockup what happens if edit a scheduled template and it's parts, will I have to "reschedule" and just select the same date/time?

If you edit a scheduled template the default option will be to add the changes to the current scheduling, but you'll be able to: a) adjust the scheduling b) save as a draft c) save immediately.

This means we need to keep two versions of the scheduled changes for the header template part, right? Or will scheduling changes for template parts in a template affect another template (unlikely)?

Here's a mental excercise of what I think could happen (this is quite complex, so maybe I'm totally wrong and/or maybe there's a simpler way 😅):

• Template A contains Template Part 1 and 2.
• Template B contains Template Part 1, 2, and 3.

1. You first go to Template A and make several changes (on the template itself and also on the template parts). You schedule the changes to be published tomorrow.

2. You then go to edit Template B. You'll see Template B and the updated (but not just published) versions of Template Parts 1 and 2 [a question here is if we could indicate that they have scheduled changes]

3. You make some changes to Template B and also to Template Parts 1, 2, and 3. Then schedule the changes to be released in two weeks.

Here's what I think will happen:

• After 1 day, Template A is updated with the changes made for that template but also with the modifications for Template Part 1, and 2 that were introduced when updating Template B.

• After 2 weeks, Template B gets updated with its changes. Since Template Part 1 and 2 were already updated, users will only notice the change in Template B and Template Part 3.

[javierarce]

And then there's also @jameskoster question:

What happens if I edit post content then save a draft, does that update the post status to draft (and unpublish it) or just store those changes somewhere? If the changes are stored, what happens when I go to edit that post, can I pull the changes in?

Should we exclude the content changes from that flow? And… is that something we can technically do?

[pablohoneyhoney]

Perhaps the new button with a drop down could use some more padding and finesse. @javierarce
How could we improve that whole top header with the button and the close icon, like position when the it slides in.
Do you think the large close icon works well in scale and also in context of a smaller version in the settings inspector?

[pablohoneyhoney]

This is a separate issue or consideration, but this effort made me think how disconnected the action button (top right) and the snackbar validation (bottom left) are.

[talldan]

Are there concerns over how easy it'll be to break a site by switching a template part to draft? I did try to read through the whole thread and couldn't see this addressed, but I may have missed it.

If I'm editing template A and switch my header template part to draft, then that may accidentally unpublish the same template part in templates B, C, D etc. It seems like that would be incredibly easy to do, and have quite a bad result.

Scheduling is less risky, but similarly a user may be unaware that scheduling a change in a template part will affect multiple templates.

I also think it's worth thinking through the use cases for scheduling something. I think seasonal or promotional content is a big reason, but there are many others.

In this situation, rather than editing a template part in place, I wonder if a way to fork or create variations of a template part might be more interesting. A user could perhaps be able to schedule a seasonal variation to go live, but also be able to schedule an end date when the original version of the template part is reverted back to.

[jameskoster]

I don't even know that scheduling is less risky. For example it would be easy to schedule changes to a template in the site editor, then go and save changes to that template in the post editor... what happens when the scheduled changes go live... what if there are conflicts? Drafting / scheduling that involves content or templates still feels like a can of worms to me.

[mtias]

Scheduling is essentially a fork through revisions. Generally, editors load the scheduled version so you are always editing the latest. It gets complex when the thing that is scheduled is an update because you also want to be able to see what is published. They are workable problems, though.