Improve datepicker styles

[tofumatt]

There's been discussion in #7621 around improving the styling/UX of the datepicker. @jasmussen has some great ideas here: #7621 (comment) and in the same issue @karmatosed referenced a datepicker she dug: #7621 (comment)

We should do these things for sure, but I'm creating this issue separately to document the styles/UX we want to implement that we can work on after #7621 is merged.

[jasmussen]

I think this ticket is solid, but I think it's also a somewhat big undertaking. As such, I think perhaps this ticket should be in "Ideas". Because the improvements to be made involve parsing input fields like how Google Calendar does it. Not easy. Doesn't mean we shouldn't do it, but means we might need to do it in 5.1 instead.

So as to keep this repo, for now, focused on immediate future things, would you mind if I close this ticket? I've added it to Ideas for now https://github.com/WordPress/gutenberg/projects/8

Edit: to clarify — the idea isn't to close it as invalid, the idea is to file it in Ideas as valid, but future, as a means of triage.

[tofumatt]

I don't think it's useful project management to close tickets we will work on, but it's fine to tag them as something like "future" or some other milestone.

If we close this and someone else thinks "oh, we should improve the date picker styles" and they search through open issues (like I did) to make sure it isn't a duplicate–they won't find an issue and then they'll open another one.

If we are going to work on something we should keep the issue open. Understanding that a closed issue isn't closed will be opaque to community/occasional contributors, and honestly I feel like even as a regular contributor I'll forget too.

[jasmussen]

Alright, but I'm unassigning myself because this is out of scope of my skills to address, as the improvements suggested would require a fair amount of rewriting of the component, as was also briefly touched upon in the original PR. Here's the type of improvement that I'd like to see:

[tofumatt]

Oh, hey, totally, sorry. I thought your GIF was basically it. My bad, sorry! 😅

[jasmussen]

Not at all! It's just that natural language parsing and ensuring the accessibility of it, while totally doable, is beyond my skill ;)

[karmatosed]

I actually think putting in projects 'ideas' for this makes sense. Sorry but that is what we should do for this as it's means we can come back to things. We can each phase evaluate and consider, but we should be ok about closing and having in ideas iterations.

[tofumatt]

I don't understand why we would close an issue that isn't fixed. Closing this issue makes it appear like it's either:

• done
• not going to be addressed

but that's not the case. It also makes it difficult to search for; where do I find this issue and make suggestions or ask questions about it now that it's closed?

[sarahmonster]

It's a wee bit unclear from the description here what threshold we need to hit to consider this issue closed, but it seems like we're looking for:

1. A simpler interface.
2. Ability to enter dates and times in a natural-language-ish kind of fashion.
3. A fully accessible solution.

I started playing around with some ideas for all three over here: #12048 (comment); would love some additional feedback there to see if this might be an approach to closing this issue.

[sarahmonster]

Circling back here to share the suggested improvements as per #12048, let's look at the current issues with the existing datepicker:

• Entering a date using a keyboard requires three individual, disconnected selections.
• Natural-language processing may not work effectively for all languages WordPress supports.
• Closing the datepicker popover can only be done by clicking outside of the popover, causing accessibility issues.
• The boxes of different sizes everywhere creates leads to a bit of a mess. Cleaning it up declutters the interface.

Instead, let's opt for a solution that:

• Simplifies input for keyboard users.
• Displays a calendar for users who find this helpful (showing the calendar being useful to visualise dates and weekends, as well as to see when existing posts are scheduled), but doesn't make calendar input the primary or most prominent entry so as to allow for a more inclusive interface.
• Reduces visual complexity and noise.
• Won't interfere with proposed changes in Improve "Visibility" and "Publish" labels in Post Settings #470.
• Allows for more explicit "save" and "reset" behaviours.

More discussion and mockups on #12048, but here's the solution I think would work best:

Using a simpler input allows us to vastly simplify the interface for users who'd prefer a plaintext input as well as for users who'd prefer to use a calendar input, and it significantly reduces the cognitive overload of what was once an overly-busy and overly-complex interface.

Internationalisation is handled by hinting at the format required, combined with helpful error messaging and sensible validation (not pictured, but we can programmatically correct for user errors or format variations, as seen in the Eureka example.)

At that same time, this also solves the original problem in that there isn't a clear location in the current interface for the "Reset" button that makes it clear what that button will do, making the interface more understandable, consistent, and predictable for users.

This is a good model to follow in terms of implementation: https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker

See also: http://adrianroselli.com/2019/07/maybe-you-dont-need-a-date-picker.html (Thanks @afercia!)

[afercia]

as seen in the Eureka example

Link 🙂http://eureka2.github.io/ab-datepicker/

For the accessibility feedback, please see comment on #12048 (comment)

Note: User input validation would play a role here. Using select elements makes the task easier. For example: if the month is 2 (February) we know 30 and 31 are invalid values and 29 is only valid for leap years. Instead, parsing a string like 02/30/2020 is a bit more complicated (if it's not already handled by the adopted library).

The current Gutenberg date-picker auto-corrects invalid dates.
In the Classic Editor, submission of invalid dates is prevented:

[melchoyce]

It seems like Eureka handles i18n, and is accessible — could we use that? Is there anything stopping us?

[mapk]

It would be great to see @sarahmonster's iteration implemented if possible. Surfacing timezones as in #15673 which was recently reopened is a nice addition.

[brentjett]

I'm jumping into this conversation late but I've been working with DateTimePicker in another context and having trouble just getting it centered up and looking nice. There seem to be a lot of container divs (some don't seem like they are contributing to the layout) and several hardcoded widths. Even inside the block editor it doesn't appear to be centered and spaced properly.

My Question: Is there any reason not to implement the calendar with flexbox so that it fluidly adapts to the width of its container?

[mapk]

@brentjett, I'd love to see flexbox work here! ❤️ +1 to minimizing the amount of HTML.

[youknowriad]

@jasmussen Feels like we iterated a lot on this component during the recent weeks/months. Is this done?

[jasmussen]

Yes, I think that the next actionable step requires an entirely new component, the existing one as Brent alludes to, comes with sufficient challenges, and what we have as is, works.

So I think this is closable, and any new ticket should come with a fresh appraoch and new design.