Error validation check on past date for a schedule post

[chriscct7]

Is your feature request related to a problem? Please describe.
If a user picks a date in the schedule post datepicker, and accidentally clicks on a previous date, the only notification of this change is a subtle change from "scheduled" to "publish" on the status.

Describe the solution you'd like
On the review panel when Gutenberg asks for a date confirmation, if a custom date has been selected, and is in the past, perhaps it would be a good idea to put an error notice with a "Are you sure you meant to pick a date/time that has already passed? Publishing now will put this post/page live immediately" or something like that.

TNW broke a GitHub news embargo today on accident because something like this doesn't exist: https://twitter.com/matthewhughes/status/1082325484678057984

[Clorith]

I don't think an alert is the answer here, it would rather be a point of frustration to many users. Because of WordPress' native way of sorting posts being by publish date, I know many sites back-date posts, some times only by minutes, to ensure the right ordering of articles at times.

What I think we could do here is to make the publish time always visible in the Pre Publish panel. As of right now we only display it if you've picked a future date, this feels like something we can safely always display and still maintain the existing flow. We could perhaps add in a quick little "X days from now" or "Y days ago" in some manner to make it clearer if it's in the future or past, when you may glance over a number and easily misread it.

[paulschreiber]

@Clorith Perhaps you could display the alert if the date is > n hours in the past (n=1, n=24, etc.). The value could be filterable.

[75th]

My suggestion:

• When editing the post date, add an OK button like the old UI had, and disable the Publish button until the user clicks it (or collapses the panel) and can see the below changes take effect
• When backdating a post, instead of "Publish: January 1, 2017 12:00pm", have it say "Publish: Immediately (dated January 1, 2017 12:00 pm)"
• When clicking OK on the date (or collapsing the panel), if the date is in the past, change the "Publish" button to say "Publish immediately" and perhaps turn it red

[Clorith]

A conditional based on N time isn't good here, I think consistency is key "I know that I can double check the date here" should always be part of the flow in my opinion, instead of conditionally displaying it.

I'm not a fan of making "negative" buttons, it takes away from the importance of similar tasks when a red publish button suddenly becomes the same as a red delete button (you get the gist, I know we often use link-style buttons) and so forth. A plugin to implement that is better if anyone wants that behavior.

I do like point 2 there, and is much along the lines I was thinking of as well.

[75th]

A conditional based on N time isn't good here, I think consistency is key "I know that I can double check the date here" should always be part of the flow in my opinion, instead of conditionally displaying it.

If the button always had "Publish immediately" instead of "Publish" that would be okay. But I think a change in the button text might be actively good, if the user does something that looks like they might have made a mistake. If you change the date and you expect the button to change to "Schedule", you're more likely to notice it if it instead changes to "Publish immediately" instead of remaining the default, similar-length "Publish".

I'm not a fan of making "negative" buttons, it takes away from the importance of similar tasks when a red publish button suddenly becomes the same as a red delete button

Yeah, that's fine, I knew that was iffy when I said it.

[karmatosed]

We discussed this in the triage weekly meeting in #design Slack. It was agreed this is a problem and to look at moving this to need a design.

[sarahmonster]

There have been a number of solutions presented for this problem as part of overall improvements to the publishing flow, most notably #16127 and #16308.

It would be lovely to get feedback on those specific issues.

[enriquesanchez]

This issue was discussed today during the Design team's Gutenberg triage meeting.

We agreed this needs design exploration. It could be something as simple as a line of text below the publication date that informs the user of what will happen, I think that @sarahmonster 's idea on #16127 (comment) could work really well:

"Your post will be published right now and back-dated".

[kjellr]

It seems like a notice might be a decent way of doing this — just a simple nudge to make sure the user knows they did something (potentially) weird. As noted above, we don't want to block their action, we just want to make sure they notice that their post is backdated.

A few options for how we might place a notice like that:

1. In the document panel, underneath the date picker

2. In the date picker itself

3. In the pre-publish panel

---

If we feel that a "warning" notice is too strong here, we could alternatively use a default (blue) notice:

[melchoyce]

I like including the notice on the post-publish panel, but it can't be the only place we show this notice because people can disable this screen. I think it would make sense to include both options 1 and 3. Option 2 is great for seeing an immediate reaction to the action of picking a publish date, but the notice would end up being hidden on mobile.

I think the warning notice is a more clear "head's up" than the default notice, so I'd stick with your original mocks.

[kjellr]

@ellatrix and @jameskoster pointed out that "scheduled in the past" text is confusing — You don't really "schedule" things to have happened already. 😄

The "Your post will be published right now and back-dated." language seems a lot more clear and to the point.

[paaljoachim]

I believe we can remove the "Needs Design Feedback" label here and add the "Needs Dev" label.
Is that correct?
@kjellr

[kjellr]

I'm not sure that it needs a dev — it has a PR already.

[paaljoachim]

Ah yes. I see the link to #25569

I will remove the "Needs design feedback" label.