Flatpickr: Calendar with time lacks visual cue for next action

[neokio]

With the basic flatpickr calendar, the UX is extremely elegant. The moment one clicks a day number, the calendar popup closes. But when the calendar shows the time inputs via enableTime: true, there is no intuitive next step.

Yes, anyone with half a brain will eventually click the background, away from the calendar, to close it. But not before wasting a moment to think "Wait, where's the OK button?". Even darkening the background onOpen and fading it onClose, as I've done in my test implementation, is insufficient in communicating a next step.

Since the user will have to click once more anyways to close the calendar, I'd much rather give them something to click, with a behavior that is universally recognizable. I'm going to add an "OK" button below the time input. But I wanted to mention it here, and suggest you implement this in a future release, as it's one of the few missing elements in an otherwise magnificent offering.

Cheers, and thanks.

[chmln]

Hello,

Thank you for the feedback.
User experience has been a key focus for flatpickr from the start.

But when the calendar shows the time inputs via enableTime: true, there is no intuitive next step.

This one I've found hard to get right.

• display an icon for time picker? then the time picker can go unnoticed
• display an "OK" button? I find it'd disrupt the style of the calendar and look out of place
• Launch a time picker after selecting a date? This would be a terrible experience if the user changes mind about a date or time

[neokio]

Hey!

You're asking the right questions. And your less-is-more approach to UI is sound. Here's the style variant I chose, and my thinking for it:

• The next/prev month arrows are now blue and bolder.
• The time numbers were too small, almost going unnoticed. I enlarged them to 18px, the same size as the month and year. Could benefit from being even bigger. Also expanded the time area vertically.
• I found the time difficult to read at a glance. Bringing it closer together helped.
• The up/down arrows next to the numbers were small to the point of being useless. Having a larger click-area makes them more usable, especially for mobile. The blue up/down arrows indicate action.
• The AM/PM text is blue, indicating it can be clicked to toggle.
• The checkmark is better than "OK". No distraction or reading required, no translation required. If you find the big blue button at the bottom too disruptive, it could be a white button with a blue checkmark. But given the hunt-and-peck obstacle a date/time interface represents, I find the finality of clicking that blue button quite satisfying.

[chmln]

Gotta admit that checkmark is pretty sweet. :cake:
Think it should always be displayed, or only when the user modifies the time input?

[neokio]

I'd suggest always displayed, so the moment the interface appears, the user is immediately clear on what is expected of them.

The checkmark and the arrows above are from Font Awesome, which I tend to use wherever possible, but obviously that's too large a dependency for just a few icons. Using Glyphter, here are those 5 icons mapped to the letters ABCDE ...

Flatpickr-font.zip

[yeluolei]

this will also work when I hide the day select area, to choose month only with this widget. can't wait for this feature.

currently if I hide the day select area with css, there is no way to fire selected event from this widget

[chmln]

Please check out the latest changes https://chmln.github.io/flatpickr/#example-datetime
Time input is now hidden initially, and pops out after a date selection - I find that it establishes a rather clear step.

The checkmark looks nice, but it adds another layer at the bottom, making the calendar too tall and thin

[rsjaq]

Hi guys, just to wanted to add some input on the matter if that's cool :)

I read the issue to be more about what the user does next to confirm their date/time entries.

I don't think having a hidden time input helps, if anything I believe it confuses the matter further and just divides data entry that's being inserted into the same field. It also just takes the user to the already available (when not hidden) "next step" and then once again leaves them not knowing what to do after they have entered their date/time. I believe the "confirmation" part is the "next step" which the OP was trying to refer to.

As a suggestion, which I think will make for a better UX, how about making the time input visible by default again (as with previous versions) and instead, have a checkmark appear once both date and time have been entered? That way, the user is presented with a date/time picker as expected, and then once they've entered a date and a time, they are then presented with a "visual cue for next action", which would be confirming their entries. I think this would make for a much better UX while still retaining the simple and elegant design of the calendar.

Thoughts?

[neokio]

The author doesn't like the OK bar. It adds 10% to the height, which I consider acceptable for the 100% "next step" certainty it gives the user. Hiding the time input just further ambiguates both progression and expectation, moving even further away from what I consider good UI. But this is his creation, and undoubtedly others will appreciate his approach.

[mgibbs189]

@neokio @chmln what about a "slide" between the date and time?

See http://codepen.io/creotip/pen/mPqaGv

Notice how when you click an arrow, it slides to the right.

I'm thinking that when a user selects a date, the UI would "slide" to show the time selector (along with a back button above it). Then we could add the checkmark button without it taking up too much vertical space...

[chmln]

My primary issue with the checkmark row is that the looks are not stellar - wouldn't even hesitate otherwise.
See some examples how this functionality is implemented around the web:

The last two don't look so bad.
I'm going to experiment with various layouts before I make any decisions.

[rsjaq]

I think the 3rd one down looks quite good with the date and time separated, checkmark at the bottom of both, it also allows for clearer controls on the time input and UI still looks quite refined. Out of curiosity, what datetime picker is that?

[chmln]

I think the 3rd one down looks quite good with the date and time separated, checkmark at the bottom of both, it also allows for clearer controls on the time input and UI still looks quite refined. Out of curiosity, what datetime picker is that?

I dig the looks as well. Its from some sort of a PSD UI kit.

I'm going to experiment with various layouts before I make any decisions.

[Wardrop]

Here's another concept, with the OK button on the same row as the time. Needs some more work visually, but you get the idea. I've also added a drop shadow which I think flatpickr should have by default.

EDIT: I think that whole time row needs to be restyled actually. Perhaps I'll have a play with the CSS, add an OK button and submit as a pull-request if I'm happy with it.

[Wardrop]

Ok, ran with my idea and have submitted a pull request for this. Added a bit of extra polish, including appropriate focus/active styling for the ok/tick button.

[Wardrop]

Just noticed, we may need to implement something similar for multi-date selection. A full-width version of this like what @neokio showed. I may amend my pull request with this.

[Wardrop]

Added ok button for "range" and "multiple" modes that don't have time enabled. Screenshot...

[neokio]

I like this one! I suggest making it ubiquitous, and adding a showCheck config option (default to true), which, when set to false, provides the current excellent behavior on the calendar-only interface (closing when day is clicked).

[jaredatch]

Looking good.

My 2 cents:

I think the checkbox should _always_ be on its own line, for date ranges and when using the time picker.

Basically how it was mocked up in https://github.com/chmln/flatpickr/issues/413#issuecomment-261211717

My main thoughts behind this is

• Check is more prominent
• Check will be consistent in placement regarding the date picker configuration, which IMO is important. This way if you have multiple date pickers used on your site in different ways, the check is always in the same place and won't "move around" for the user.
• Check could support text via checkText option. For example, if I was implementing this for my users, I'd like to change it to "✔️ Done", to further guide the users.

Placing it on the bottom in all use cases will address all these :)

[chmln]

Looking good.

My 2 cents:

I think the checkbox should always be on its own line, for date ranges and when using the time picker.

Basically how it was mocked up in #413 (comment)

My main thoughts behind this is

Check is more prominent
Check will be consistent in placement regarding the date picker configuration, which IMO is important. This way if you have multiple date pickers used on your site in different ways, the check is always in the same place and won't "move around" for the user.
Check could support text via checkText option. For example, if I was implementing this for my users, I'd like to change it to ":heavy_check_mark: Done", to further guide the users.
Placing it on the bottom in all use cases will address all these :)

This.
Now here's what's gonna happen:

• The checkmark is a go when enableTime: false :+1:
  
  
  
  • For usability purposes, textual part (localized) will be added i.e. "Done"
  
  
  • I'm also debating whether the checkmark should be on or off by default in these cases, but rather inclined towards the opt-in approach
  
  
• Aforementioned layout issues. As it stands, the layout of flatpickr is rectangular - narrow and long
  
  
  
  • this isn't really a problem, but I found it looks much better when closer to a square shape
  
  
  • whether this will be achieved by extra padding or some other means remains to be seen
  
  
• In case of enableTime: true, docs might recommend using the wrap: true option and implementing an 'OK' button of their own
  
  
  
  • an example will be provided in documentation
  
  

[mgibbs189]

@chmln @jaredatch @neokio Removing the checkbox when enableTime: true seems inconsistent.

I'd argue that time is when the checkbox is MOST useful...

What about like a showConfirm (boolean) option to toggle the checkbox?

[jaredatch]

@mgibbs189 I agree.

In my opinion, what makes the most sense is:

• Only displaying date picker does _not_ display check area, because selecting a date closes the date picker
• Enabling the time picker causes the check area to display
• Enabling date range causes the check area to do display
• showCheck property available to override behavior mentioned above

[chmln]

@mgibbs189 you'll be able to turn on the checkmark in any scenario with something like enableCheckmark: true

Its just a matter of figuring out sensible defaults.

I'd argue that time is when the checkbox is MOST useful...

Totally agree.
I just found no way of having both the checkmark and the time displayed that looks good..yet

[jaredatch]

@chmln I definitely understand now wanting to change default behavior/design, and if that's the case then perhaps having the check area default to off in all scenarios?

IMO the check area is most helpful when the date picker supports multiple actions and don't automatically close on selection (time enabled or date ranges).

[chmln]

IMO the check area is most helpful when the date picker supports multiple actions and don't automatically close on selection (time enabled or date ranges).

Exactly.
And as I mentioned:

you'll be able to turn on the checkmark in any scenario with something like enableCheckmark: true

Regardless, before a decision is made on this I will introduce the layout improvements first.
Those could also largely negate my initial concern with adding an extra row

[mgibbs189]

@jaredatch Yep, let me know if this sounds right:

enableCheckmark should ALWAYS take precedence. If it's undefined, then by default show the checkmark if:

• enableTime: true OR
• mode: range OR
• mode: multiple

[mgibbs189]

@chmln Can't wait to see what you come up with

[yeluolei]

@chmln i use this plugin in production and there is so many request for this feature

[Wyzix33]

Maybe a OK/Close/Clear/Today button can be placed over the input itself when the calendar is open, on top of the calendar

[pbhadane]

Please need a Close button inside DatePicker

[neokio]

@chmln Looking forward to seeing what you choose to do!

[chmln]

@neokio I'm leaning heavily towards a plugin-based approach.
See the confirmDate plugin, which is work-in-progress. And see how plugins work here.

I will likely include options to enable today, clear, maybe other buttons too.

Rather pressed for time right now due to midterms, but with last one being tomorrow I'll be able to deliver this by next week or so.

[creativelink]

+1 just to make it more user-friendly on mobile.

[chmln]

https://chmln.github.io/flatpickr/plugins/#confirmdate

[vitality82]

Too bad there is no confirmTime plugin available - currently if feels silly for people having to click on the background, even more if you have 10+ time pickers on a page.