No way to clear publish date from datepicker once set

[earnjam]

Once you set a publish date using the publish datepicker, there is no way to go back and remove that if you would like to have it publish immediately on press of the publish button. The best you can do is just manually set it in the past or close to the current time.

In the classic editor, there was a cancel button that would clear the scheduled date.

Similar: #9030

[sarahmonster]

Oddly, my testing is finding the inverse—the Classic Editor doesn't actually reset the date to the current date & time, it just cancels your current changes. So, if I've already saved a scheduled post date, there's no way of reverting it to the current date without manually setting it. "Cancel" here really just closes the "Edit" date modal:

Anyway, that may just be a regression. At either rate, it's worth being able to reset the date & time from the calendar. Let's explore a few initial options for this:

Reset

My first thought was to provide a way of "resetting" the schedule action. A text link felt like the simplest, least obtrusive choice here, especially where the UI of the datepicker is a bit cluttered:

But, since it's an action, we may want to use a button instead. Matching the reset from the image resize mechanism probably makes sense in terms of ensuring consistency, even if it feels a bit less elegant:

Pros:

• Super simple, minimal change.
• Fits with how other resets work (image sizing).

Cons:

• Doesn't really help address other potential usability issues with the datepicker (see below).
• The reset action doesn't follow the date. From an accessibility perspective and a user experience perspective, it might make more sense to read out the time, date, and THEN the reset link. (Batsignal @LukePettway if you've a moment to share your thoughts here.)

Publish now

This is essentially the same action under the hood as Reset, but framed to the user differently. Instead of "resetting" the saved date, the user would choose to "Publish now".

Pros:

• Nice big obvious button!

Cons:

• Having a "publish now" button that doesn't publish the post feels like it could be pretty confusing. The alternative would be to have the post publish immediately if someone uses this button, but that means that there are now two entry points to the publishing experience, which could be confusing as well.

Reset or save

This frames the choices as either "save" the date or "reset" the date—both of which close the datepicker popover.

This helps to avoid some confusion in terms of updating the date. Right now, you click the date you want in the popover, and then need to click outside of the popover in order to close it. Having an explicit button for this behaviour feels much more natural and confidence-inspiring (I know what's happened) than having to click somewhere at random. (This also seems to be how to Classic Editor works, so it's likely a pattern that long-term users are more familiar with.)

I wasn't sure if the labels were clear enough, so I tried a more explicit variation:

Cons:

• Labels feel like they might be unclear.
• Introducing a decision here could potentially add mental overhead unless it's super clear which is which.

Pros:

• Helps improve the overall usability of the datepicker.
• Improves hierarchy of actions at the bottom of the calendar by using buttons for the primary actions and a link for the help link.
• Probably the best solution from an accessibility perspective.

Some combination of the above

I'm not sure any of the above are the ideal solution. A combination might be best:

I'd love some additional thoughts on this!

[earnjam]

Oddly, my testing is finding the inverse—the Classic Editor doesn't actually reset the date to the current date & time, it just cancels your current changes. So, if I've already saved a scheduled post date, there's no way of reverting it to the current date without manually setting it.

Correct, once saved it could not be cleared. But if you hadn't saved a draft yet or clicked Schedule, then it resets to immediately when you press clear. This is not possible in the new editor.

[Luciaisacomputer]

@sarahmonster I'll need to pull this down and test it out. At least from what I believe you are asking about the date being read first, ideally yes that should happen. What are the steps you are performing when this occurs?

At the very least, I might consider the rest to have some additional text for non-visual users to know what the reset resets to. Does it reset to the Unix Epoch, the current date, the last date that it was set to?

[earnjam]

@LukePettway It would reset to a floating date. As far as the actual saved DB value, it is 0000-00-00 00:00:00. WP basically reads this to mean that no publish date has been set and it will first be set when the post transitions to a published type status. For more info, see: https://core.trac.wordpress.org/ticket/39953 and #7195 and #9967.

I think something like "clear" makes more sense than "reset" in this context. You're essentially clearing the date input so it no longer has a value.

[Luciaisacomputer]

@earnjam that makes sense to me

[ValentinGratz]

On calendar I can not find the reset link.

[sarahmonster]

The above explorations are just mockups right now—there's no PR here just yet. Right not I'm looking for feedback on the suggested approach, and then we can move to a PR. 😄

Correct, once saved it could not be cleared. But if you hadn't saved a draft yet or clicked Schedule, then it resets to immediately when you press clear. This is not possible in the new editor.

I've definitely been approaching this as a "revert" action that would apply regardless of whether or not the post has been saved. This doesn't seem in line with how the behaviour of the classic editor works, but it feels like it's more in line with possible user expectations here, in it would allow for resetting the date altogether if a user wants to switch their post from scheduled to "publish whenever I press the publish button." (This is an assumption on my part, so if anyone happens to have data around this I'd love to hear it!)

[afercia]

DIscussed during today's accessibility bug scrub, here's some recommendation:

• auto-save seems potentially confusing for users, we'd prefer to remove it
• Two buttons “Reset” and “Save date” sound good

The actual placement of the buttons should be explored a bit, taking into consideration:

• keyboard / assistive technology users need to reach these buttons in the easiest possible way
• longer translations may need some more space

[sarahmonster]

I've tried a few variants of this, trying to account for longer text strings that translations bring about and taking into consideration keyboard users.

From testing, it seems like keyboard users can skip the calendar pretty easily (three taps), although there is a missing focus indicator somewhere in the middle that we'll want to fix.

Here's where I ended up:

A: Reset link

⊕ Very distinct, easy to pick out from the other inputs here
⊖ Doesn't match with image reset (which uses a button)

B: Reset button

⊕ Matches the image reset button
⊖ Can get a bit lost in the sea of buttons and inputs

C, D: How might it work with longer strings?

I tried looking up different languages to see where these strings get really long. One option might be to simplify the text if the strings will be long: "Save Date" vs "Save", or "Calendar Help" vs "Help", for instance. Another is to just scoot things down to a new line entirely.

E, F: What if we moved things around a wee bit?

One of the things I realised was throwing me off a bit whilst working on the above is the sheer number of different types of input for, often, the exact same data.

There's also some weirdness around having the reset button right after the time input, and then having a calendar input beneath that. In an ideal world, you could set the date all from one area (date input + calendar), then the time (time picker), and then finally, save or reset. I tried to play around with what that might look like here:

This one really seemed to highlight the problems with stacking the "reset" link right next to the time input, because it implies that you'd only be resetting the time, when in fact you're going to wind up resetting everything. (This is also an issue with the explorations above.)

This can potentially be solved by having "Reset" sit beside "Save", which does feel like a logical place, and pushing "Help" down to the bottom, like so:

This does wind up being a larger redesign, but if this seems like a promising direction, we could try to follow it further as part of #10181.

[afercia]

@sarahmonster thanks for your explorations. Regarding the last two examples: splitting the date and time fields in two groups with the date picker in between is not an option for non pointing device users (which includes keyboard users, screen reader users, switch control users, and dozens of other alternative devices). The purpose of having all the input fields at the top, which we've asked to add for accessibility, is to allow users to set date and time without being forced to go through the picker.

In this regard, I'd also consider to place the reset and save buttons after the fields and before the picker.

Lastly: as far as I'm aware of, the primary button should be on the left. This pattern was discussed at length in the design team and I can remember there was large consensus.

[sarahmonster]

I don't have any particular opposition to putting the primary button to the left, but it looks as though it's typically put to the right (see: publish bar, our Button guidelines, and Modal guidelines). I'd love some additional input here though, since I don't want to be violating an existing pattern.

Moving the primary button to the left and rearranging the buttons and inputs gives us this:

We could go this route, but we do compromise the usability for those who, regardless of access needs, find the calendar view helpful (Vaguely related: #13713).

There's a lot going on in this one wee panel, and simplifying or streamlining the interface should help users enter dates easily and clearly, without introducing additional cognitive overload. For a logical source order and to keep things clear, we want to group related elements together based on the action they represent, which breaks down as follows:

• choose date
• choose time
• save or reset

A logical source order here would also help avoid the situation where I pick a date from a calendar and then save it using buttons above the calendar, which seems suboptimal from both an accessibility and a usability point of view. If I were a keyboard user wanting to use the calendar to select my date, I would need to then tab all the way back up to the buttons above to save my change.

A better solution might be something along these lines:

Can you give me a bit more background on why forcing users to tab through the picker is problematic? Right now, it's three tab presses, which doesn't seem overwhelmingly arduous, but I'm probably misunderstanding the problem. Having more context would allow us to better determine a helpful solution here. Maybe we could have keyboard focus skip it altogether? Or we could pare it down to a single tab step?

An alternate approach would be to hide the datepicker altogether, and only open it on a button press, but that then creates additional work for users who find the calendar view valuable. (I only have guesses that this comprises some number of users, so if anyone happens to have data here, I'd love to see it!)

Alternatively, maybe it's time we just let users enter dates in whichever way works best for them. There are a million natural-language date parsers for Javascript that we could leverage here, and then allow the calendar picker as an extra input method if needed:

Something like this or this or maybe even a simplified version of this where an input would combine with a calendar, might work nicely here.

[afercia]

I don't have any particular opposition to putting the primary button to the left, but it looks as though it's typically put to the right (see: publish bar, our Button guidelines, and Modal guidelines).

Hm that's maybe the pattern established for toolbars and modals in Gutenberg. Not sure it's consistent with what was discussed and agree for core, but I'd encourage you to ask feedback to the design team. As far as I know, the agreed general pattern is:

• Primary button followed by secondary
• both preferably on the left with exceptions depending on specific cases

More background

Can you give me a bit more background on why forcing users to tab through the picker is problematic?

Sure 🙂
Using the Tab key is only one of the ways to navigate content. It mainly applies to keyboard users who don't use assistive technologies. Instead, assistive technologies provide users with a huge amount of keyboard shortcuts and navigation modes to explore content. The tab key is not the primary one.

For example, one of the standard ways to navigate content with screen reader is by using the Down and Up arrows to move sequentially through all elements in a page. That means when users are exploring content, they have to go through all the Calendar. I can witness exploring the Calendar with a screen reader is a terrible experience 🙂

Regardless, there are literally dozens of alternate assistive devices and technologies and we simply shouldn't assume "tabbing" is the only way to navigate content. Ideally, accessible UIs should be designed in a device-agnostic way.

See some resources linked below.

For a logical source order and to keep things clear, we want to group related elements together

Right, and that was one of my points: the date and time fields are logically related and need to be grouped together.

For history

Originally, the Calendar didn't have native input fields for the date, see #1311. It looked like this:

Of course, the Calendar itself was totally not accessible.

As accessibility team, we asked to have native form controls for all the date/time parts and place them at the top. This top part is the main UI and needs to be accessible for everyone.

The bottom part with the Calendar can be considered an additional UI, an enhancement for some users who may prefer to use pointing input devices and are more comfortable with the Calendar.

Then, also the Calendar part was made more accessible thanks to the remarkable work done by @aldavigdis. It's way better know, but still can't be used by all users.

Conclusions

So my reasoning is:

• the top part with native form controls needs to be usable by everyone
• since that's the main UI, Reset and Save should be placed there, to not force users to go through all the Calendar
• the Calendar is additional / enhanced UI: it's good to make it as accessible as possible but it doesn't necessarily need to be 100% accessible, as long as users can set the date and time by other means (the main UI)
• granted, if making a decision was up to me, I'd definitely consider to entirely remove the Calendar 🙂

WCAG requirements

Success Criterion 1.3.1: Info and Relationships
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships

Success Criterion 3.3.2: Labels or Instructions
https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions

Some useful resources

The difference between keyboard and screen reader navigation
https://tink.uk/the-difference-between-keyboard-and-screen-reader-navigation/ …

Visual Disabilities
http://webaim.org/articles/visual/

Motor Disabilities
http://webaim.org/articles/motor/assistive

Cognitive Disabilities
http://webaim.org/articles/cognitive/

Auditory Disabilities
http://webaim.org/articles/auditory/

Seizure Disorders
http://webaim.org/articles/seizure/

Switch access
https://en.wikipedia.org/wiki/Switch_access

Sip and puff
https://en.wikipedia.org/wiki/Sip-and-puff

Computer and Software Accessibility for the Disabled
http://www.mapcon.com/computer-and-software-accessibility-for-the-disabled

Assistive Devices for People with Hearing, Voice, Speech, or Language Disorders
https://www.nidcd.nih.gov/health/assistive-devices-people-hearing-voice-speech-or-language-disorders

[afercia]

Found some references on previous discussions and approved pattern for the Primary button on the left. Most important one:

Addressing Proximity in the admin area
https://core.trac.wordpress.org/ticket/40822#comment:9
From @melchoyce 

I think we should:

• Have the primary action (like update, etc.) on the left, as a primary button.
• If relevant, list secondary actions immediately to the right of the primary action, as secondary buttons.
• List all negative action (cancel, delete) next, as links.

In most cases, the actions should be left aligned, to line up with the forms. This would happen on Settings, bulk edit screens, edit term screens, etc.
In the case of things like the theme modal, actions should remain centered (since the content within the modal doesn't follow the same left-aligned linear path as forms do).

https://core.trac.wordpress.org/ticket/40822#comment:10
From @karmatosed 

The above is more or less what Gutenberg is following. We have a slight variation on actions outside of forms or assumed forms. Our actions are grouped together also which adds a different context in some cases, a strong example of that is an ellipsis (more) menu.

Quoting from the latest W3C "Accessibility Requirements for People with Low Vision" draft
(Editor's Draft 03 January 2019, at the time of writing)
http://w3c.github.io/low-vision-a11y-tf/requirements.html#proximity-of-related-information
(note: it's )

Proximity of Related Information

People with limited field of vision or who use large text have little in their field of view at one time. If related information is not close together, they can have trouble knowing about it, seeing it, and using it. In most cases, it is best if:

• Related information — such as labels and controls, instructions for data fields, matching tests in two columns, and feedback — is in close proximity.
• Feedback is in close proximity to the user’s visual focus.
• Dialog boxes and other such pop-up messages appear over the users' point of regard.
• Users are informed of new information that may be outside of their view — such as a new browser tab opening in the background.

Other references

https://wordpress.slack.com/archives/C02S78ZAL/p1554138401066300
https://core.trac.wordpress.org/ticket/46758
https://core.trac.wordpress.org/ticket/45972
https://core.trac.wordpress.org/ticket/43412
https://core.trac.wordpress.org/changeset/40655
https://core.trac.wordpress.org/ticket/9777

[earnjam]

What if you did something like this one with just input fields when it first opens:

And then open the calendar only when someone clicks in the date field. If using a form of keyboard navigation, you could just use the input directly and we wouldn't even open the calendar.

[melchoyce]

One minor UI note — could we use a link button for "Reset," and a default button instead of primary for "Save Date?"

[adamsilverstein]

Regarding localization, worth noting when designing this UI that for locales using a 24 hour system, AM/PM doesn't make much sense; see #16373 (comment)

[sarahmonster]

Here's what it looks like with default/link buttons:

Note: button positioning will likely be contingent on whatever we decide in #16123

& yes, the time input will definitely warrant localisation as well. (I use 24h time myself, but 12h time is more challenging to handle from a design perspective so I tend to try to design around it first.) Let's focus first on the date, and then we can tackle time input separately. There are a few hidden (or not-so-hiddenl, depending on how closely you're looking!) complexities inherent in there that will likely warrant further discussion once we've landed on a suitable approach for the date input. 😅

[aldavigdis]

As far as I remember, there is an if statement in the relevant component to handle 12-hour and 24 hour time format. The underlying functionality was rather hacky, but it did do its job. :)

[aldavigdis]

Anyway. I'm just happy to see that there is some decision making being done here design wise, because if I remember it correctly, multiple vs single text fields were debated last year with lots of opinions flying around.

[karmatosed]

I know I am coming a bit late to this issue but I do think it's grown from the original intent of just clearing the date picker.

What about a simpler option and then if we do want to explore deeper, sure let's do that in another issue?

Personally, this simple button could be shipped and then exploration happen, whilst solving the problem from November really soon.

[mapk]

There's a LOT to take in here. Some great concepts of bigger iterations too!

A simple "clear" button, similarly to @karmatosed's mockup seems like it might be the trick. I'm suggesting we go with the wording "clear" and use a default button style because that seems a consistent Gutenberg pattern (ie. color settings).

There's a couple places this button may need to appear; the Document Settings sidebar, the popover after clicking the date link, and the pre-publish check slide out. Probably not all of them, but at least two.

Overall this seems like a bug we need to fix quickly. Can we continue explorations on a better UI in another issue?

[sarahmonster]

I'm not opposed to just shipping a "clear/reset" button on its own here, but I think it might make sense to put it in the datepicker popover for the following reasons:

• Introduces a consistent place for resetting the date in the future (rather than having it change again).
• Allows for consistency of the "visibility and status" settings, rather than having one option be out of line with the others.
• Reduces visual complexity and noise to where it's actually needed. (ie, not all users will need a reset button this prominently.)
• Won't interfere with proposed changes in Improve "Visibility" and "Publish" labels in Post Settings #470.
• More consistency with the original (classic editor) interface as well as the potential future interface.

It's worth noting as well that this doesn't solve the problem that there's no mechanism to explicitly save the date changes beyond clicking outside the popover, which is rather counter-intuitive. It would be great to fix this as a part of larger changes, but if we're not ready to agree on larger changes now, just adding a reset button (I'd advocate for something along the lines of the original reset suggestion) would solve the primary issue at hand.

[aldavigdis]

I'm having a look at this right now and I'm wondering if there is anything other than dispatch( 'core/editor' ).editPost( { date: null } ); and saving that needs to be done for a post to be considered non-scheduled?

[karmatosed]

A simple "clear" button, similarly to @karmatosed's mockup seems like it might be the trick. I'm suggesting we go with the wording "clear" and use a default button style because that seems a consistent Gutenberg pattern (ie. color settings).

It is actually unscheduling though, so for me that term makes a little more sense. I also do think having it on the top level also makes sense because that's likely where you want to do exactly that.

[aldavigdis]

Just did a proof-of-concept PR at #16571.

However, there's a bit of an issue there as, the Unschedule button would set the publishing date do be the same as the modified date, but once the post is saved a new revision is made.

This means that the new publishing date would be in the past compared to the modification date of the new revision.

Any input would be appreciated here.

[aldavigdis]

According to https://core.trac.wordpress.org/ticket/39953 and https://core.trac.wordpress.org/ticket/44975, there is really no way to successfully unschedule posts via the REST API, which the Gutenberg editor depends on for this to work, so I'm stepping aside from this for the moment.

[mapk]

It appears that this can't easily be solved without a Core solution figured out in Trac first, as @aldavigdis pointed out with this link: https://core.trac.wordpress.org/ticket/44975.

@aldavigdis is this something you would be able to champion? Maybe @kadamwhite can help with this as well?

Should we leave this issue open, or close until Core has a solution?

[ValentinGratz]

In which version of French WordPress will you put the "reset" function?

[sarahmonster]

@ValentinGratz this is just in the mockup phase as things stand right now, but French WordPress should get the functionality at the same time as other languages, presuming that we can ship a solution.

[adamsilverstein]

I created a potential patch for https://core.trac.wordpress.org/ticket/44975 which would unblock this ticket.

[aldavigdis]

@mapk — This was something that I wanted to champion. I had subscribed to updates to the Trac ticket via email but I had a vacation coming up and felt like I needed to step away from Github during that time.

But as a patch seems ready on the API side (thanks @adamsilverstein), I'm going to finalise #16571 as a proof of concept very soon.

[kadamwhite]

@GlennMartin1 that should take care of things from the API side; I believe a client side change would also be needed unless that’s already be tackled somewhere

[mapk]

Since it appears the technical ability is there, can we just get an MVP out like @karmatosed's mockups: #12048 (comment)

[earnjam]

There is an existing draft PR for this, but it wasn't finished and hasn't been updated since July. I'm going to work on getting a new one put together.