Scheduling: Improve flow of new Status dropdown

[jasmussen]

Work is underway to unify the publishing flows between post and site editors. As part of that, there's a "Status" dropdown, which lets you choose between draft, pending, private, scheduled, and published:

If you change the publish date to a time in the future, the "Scheduled" status will automatically be picked for you.

But if you change the status to "Schedule" first, before picking a time in the future, the publish time will automatically be set for you, to a point in the future, as shown in this GIF:

For the near term, let's consider the following solution: we remove "Scheduled" from the Status chip, and rename "Publish" to "Public". So to schedule a post, you'd have to set these properties:

• Status: Public.
• Publish: [future date]

For a draft, you'd have:

• Status: Draft.
• Publish: Immediately.

For an already published post, you'd have:

• Status: Public.
• Publish: [past date]

This flow is similar to what exists in 6.5, but comes with the structural benefits of unifying in a status panel.

Longer term updates could work like the following.

Editing a draft

Editing a published record

• In both cases the Status chip reveals a menu containing actions equating to status changes.
• The pre-publish UI moves to a modal which enables content to be published from data views.
• Publish date is specified when you elect to schedule the post.
• The status change is saved immediately, eliminating ambiguous interaction between status + publish date fields.

[annezazu]

I was testing this today with GB 18.2 and was so baffled by this experience, partially because I couldn't always get it to consistently schedule out in advance:

scheduel.post.mov

When it did schedule out a week later, I hardly noticed it as it's not a hugely visible change and it's disconnected from the options you're in the process of selecting.

Should picking "Scheduled" not be possible, should this be a status that could only be set by choosing a time in the future? I.e. an implied status?
Should picking "Scheduled" open the date picker?

I expected the modal I had open to transform into the date picker view. I don't think we should be auto future scheduling any content and could see this being a massive headache, especially for enterprise folks with workflows around embargoed content for example.

[jasmussen]

@jameskoster what do you think of this idea?

Should picking "Scheduled" not be possible, should this be a status that could only be set by choosing a time in the future? I.e. an implied status?

Not sure how technically feasible this is, to have an option in the dropdown that only appears after you've set a date in the future, or what the side-effects might be.

[jasmussen]

A quick addon thought in case it inspires other ideas:

• Remove the "Scheduled" status from the status dropdown entirely.
• Rename "Published" to "Public" (as it was before).
• Scheduling can only happen by setting a date in the future.
• "Public" instead of "Publish" implies you still have to press the blue button to do the action.

This would be not so far from what exists in 6.5:

It would still keep some of the benefits of absorbing sticky and pending statuses. The nice "Scheduled" status would be missing again, but that would be no different from what exists today.

[jameskoster]

The status chip must entertain the scheduled status, so I'm not sure whether conditionally hiding it might feel strange in some flows? For instance if you're editing a scheduled post and manually change the status to private, what happens to the publish date? There are many nuanced flows like this due to the large number of combinations between status + date. It would be nice to avoid adding lots of conditional logic if possible.

For me, it feels most natural to set the publish date at the same moment the status is changed from unpublished (draft, pending) to published (publish, private, scheduled). Until then publish date is basically irrelevant. I suppose that could be an alternative approach; hide publish date unless status = scheduled?

It needs a little design work to get right, accounting for the pre-publish checks panel, potential bulk-scheduling/publishing, and other nuanced flows like unscheduling. One idea I keep coming back to is that status changes should be saved instantly rather than staged as they are now. This would simplify the flows, and remove a lot of ambiguity.

[jasmussen]

Must it? Here's a scheduled post in 6.5:

I do appreciate that the publish date says "Immediately" today, honestly.

[jameskoster]

The 6.5 inspector doesn't show the status. It shows visibility and publish date which are different data points.

If we're showing the status, and status = scheduled, then I think the chip will need to communicate that.

It could be an option to not show the status, but this would result in the re-introduction of the slightly awkward "Switch to draft" button which I would prefer to avoid.

[jasmussen]

I'm mainly suggesting removing the "Scheduled" from the Status chip. So scheduled would be:

• Status: Public.
• Publish: [future date]

For a draft, you'd have:

• Status: Draft.
• Publish: Immediately.

For an already published post, you'd have:

• Status: Public.
• Publish: [past date]

I could be missing a beat, but I could see it working, keeping the benfits of the status selector, while keeping it close to existing flows.

[jameskoster]

For a draft, you'd have:

Status: Draft.
Publish: Immediately.

I assume status would become 'Public' when you change the publish date? "Scheduled" feels more intuitive in that case to me.

I think I prefer hiding the publish date until you select a status that involves publishing. Initially it could be as simple as revealing the date picker in the popover when you change the status to scheduled. Needs a mockup.

[jasmussen]

I assume status would become 'Public' when you change the publish date?

Yes.

"Scheduled" feels more intuitive in that case to me.

Yes, that's the only loss with this approach. But it feels like a solid plan B unless we find better — it's very close to what's shipping in 6.5, but comes with improvements to the pending and sticky as well.

[jameskoster]

Longer term this is what makes sense to me:

Editing a draft

Editing a published record

• In both cases the Status chip reveals a menu containing actions equating to status changes.
• The pre-publish UI moves to a modal which enables content to be published from data views.
• Publish date is specified when you elect to schedule the post.
• The status change is saved immediately, eliminating ambiguous interaction between status + publish date fields.

---

I acknowledge we probably wont get to this state for 6.6, so rowing back a bit from this longer term vision we might do something like this:

Most of the UI remains as it is on trunk except:

• When the 'Scheduled' radio option is selected the date picker appears inline.
• Date only appears in the Inspector when the record is published/scheduled/private.

This iteratively moves us in the general direction outlined above.

[jasmussen]

Nice work, thanks for this. I'd tend to agree with the longer term view.

As far as the nearer term view, we're pretty close to the beta period, so I wonder if the plan B might not be a simpler thing to do?

CC: @annezazu @richtabor for a take as well.

[annezazu]

For me, it feels most natural to set the publish date at the same moment the status is changed from unpublished (draft, pending) to published (publish, private, scheduled). Until then publish date is basically irrelevant. I suppose that could be an alternative approach; hide publish date unless status = scheduled?

Just noting that the publish date matters when working across timezones on a post, for example. I wouldn't hide this and see this as incredibly important information, especially in the context of larger scale newsrooms. Not sure if I'm missing something there but wanted to make sure to say something. In my convos around phase 3, it's a critical piece of info to get right.

I very much dig this plan b!

[jasmussen]

Since we're barrelling towards beta, I've tentatively set the Plan B as the way forward, updated the issue, and added the "Needs dev" label. But I'll leave the comments uncollapsed so a dev can dive in and see if the longer term solution makes sense after all.

CC: @ntsekouras and @youknowriad in case you have thoughts.

[jameskoster]

Just noting that the publish date matters when working across timezones on a post, for example. I wouldn't hide this and see this as incredibly important information

The suggestion was only to hide it when it's irrelevant, IE if the post is unpublished. When the status is anything else it would be visible/editable.

We could still show publish date when the status is draft too, but in most cases it will simply say "Immediately" which isn't super helpful. It can also be confusing because it allows you to set a publish date in the past or future despite the draft status.

It's very possible I'm missing something, but when would you want to set a past or future publish date for a draft post?

I'm not convinced that 'plan b' is the way to go;

1. It means re-introducing the 'Convert to draft' button which has technical challenges in the site editor – does the action occur immediately or does it change status behind the scenes and only apply on save?
2. We'll have to undo work that has existed in the site editor for a long time, notably the status dropdown, which was implemented with multi-entity saving in mind and combines status + visibility in an intuitive way.
3. It's not really aligned with the longer term vision.

That's not to say it can't work. If the concept I shared above isn't feasible, then it's an avenue to explore, but we'll need to answer the technical question above.

[youknowriad]

Since we're barrelling towards beta, I've tentatively set the Plan B as the way forward, updated the issue, and added the "Needs dev" label. But I'll leave the comments uncollapsed so a dev can dive in and see if the longer term solution makes sense after all.

What's wrong with we already have in trunk for beta? I think it's just the same as 6.5 with very small tweaks to align with site editor. But I feel like we're in a decent state personally.

[jasmussen]

It's mainly the scheduling piece, where picking "Scheduled" arbitrarily picks a date a week into the future.

I don't feel very strongly about this, and the "plan B" could potentially be something to apply based on feedback in testing this.

[jameskoster]

@youknowriad would it be feasible to reveal the datepicker in the status dialog, when the status is set to scheduled (ideally with rules that prohibit the selection of dates in the past)?

This still feels the simplest and least disruptive path forward to me, in terms of UX.

[ntsekouras]

would it be feasible to reveal the datepicker in the status dialog, when the status is set to scheduled (ideally with rules that prohibit the selection of dates in the past)?

Right now this is not possible with the existing RadioControl component. I'm not sure if with the planned new component using Ariakit would solve this for us, but even if it was, there might be not enough time for 6.6. What we could do for sure, is show the date control below all the available post status options. Could that work design wise?

[jameskoster]

What we could do for sure, is show the date control below all the available post status options

Do you mean in the dialog, something like this?

For me, that could work well. It's certainly a big improvement on the date field updating randomly in the background as it does now.

As a cherry on the top, would it be possible to prohibit the selection of dates in the past when status = scheduled?

[jasmussen]

If the above is feasible for 6.6, we can try that. Though I would suggest we keep in mind the Plan B as something to fall back to, if things don't come together. Does this issue need a blessing? @youknowriad

[annezazu]

Adding to the 6.6 board. In my mind, this is a blessed task as part of the unification effort and as a bug fix. It's definitely buggy right now to assume 1 week out.

@ntsekouras can you take this on?

[colorful-tones]

Does the work here seem practical for WP 6.6 release? Given tomorrow is Beta 1 and I'm not clear on whether a developer is working on this. It may be advisable to move this to Punted to WP 6.6.1? 🤔

[jameskoster]

I think the main issue here was around scheduling, which got improved for 6.6 in #62070

@jasmussen do you think we should close this, and open a new issue for the longer-term updates? Or just prune this one a bit?

[jasmussen]

Happy to close it, we can always reopen or repurpose if pieces become relevant again.