Bug: PSM - publish date validation

[cobbspur]

Summary of Issue

Currently if you edit a post and bring up the post settings menu then keep changing the publish date you will see that losing focus does not always result in a validation.

Steps to reproduce

First go to a post and bring up the PSM Change the date to be one day in the future Click outside field and you should see validation error pop up. Change date back to a valid value. Click outside field - you should see the validation error removed. Sometimes is does but not always Also try and change to an invalid format such as 0 Sep 15. You should get a different error but if you switch between this and a future date (lose focus) then the error does not always change

Video to demonstrate: http://recordit.co/UprnmeJEn3

Working from master - latest commit 40f82b6

[ErisDS]

The post date input is currently very buggy:

• [ ] Clicking in and typing moves the cursor to the end.
• [ ] It also changes underneath you a lot without warning - as reported here, the validation doesn't reliably tell you what it's doing.
• [ ] I've also seen the date revert back to now, rather than the previous date, after a (failed?) interaction.

As well as fixing the bugs, improving the UX here would be great, I'd love to see a cross-browser version of a date & time picker which is still lightweight. I think the jQuery UI one is probably too heavy duty & the popular pikaday seems to only support dates, not times.

Also note the native browser datepicker was, at last check, not widely supported enough and the fallback options were horrible, as well as the UI itself not being great.

Suggestions, as well as bug fixes, are very welcome!

[nightsh]

How about using this beauty? I can give it a shot, but I'd like a green light from anyone more familiar with the project or previous attempts.

[ErisDS]

@nightsh there's no screenshot at that URL which makes it hard to determine whether it's going to work - but I'd recommend doing a bare-minimum spike with that component? That is, get it minimally wired up to appear in place and perhaps record a quick screencast of how the interactions work. It would also be good to further document from that spike what can or cannot be changed / adjusted. It would be great to get this working a little better.

[nightsh]

I can also create a public instance on a demo server, then let you guys take a look at the thing yourselves. A demo is worth a thousand screencasts :sunglasses:

If it works, it'd be anyway better than a partially broken text input. Right?

[kevinansfield]

@ErisDS There's a demo at http://dio-el-claire.github.io/PikadayTime/. I can't find the conversation now but I vaguely remember that when the date input has been discussed previously it was said that we wanted to stay away from pop-up calendar components? /cc @JohnONolan

From a UI/UX perspective my main concern is that we would end up with a popup calendar on top of a pop-out menu plus anything that we put in there will need to have a good mobile story as we're pretty space constrained.

The above considered, @nightsh if you have some time to put a quick spike together showing the input in place it will definitely help the conversation going forward 😀

[kevinansfield]

https://github.com/minutebase/ember-time-field - Literally just released 😁 Haven't had a chance to fully dig in yet but this was my original thinking for the date input UI where individual parts are clickable and can navigated/changed with left/right/up/down key presses as well as reacting to normal text input.

This addon isn't an exact fit for our needs as it's time-only rather than date but it's another avenue to pursue.

[JohnONolan]

@kevinansfield I don't have anything against calendar pickers - I think we just never found one that didn't suck?

[ErisDS]

From what I remember, we've gone without a calendar because:

• The jQueryUI one (that was the best thing available) was too heavy.
• Alternatives were clunky or ugly / hard to configure
• The native one is sucky, not configurable enough, and it was too hard to implement a sensible fallback (see #4472)
• Pikaday has looked good for a while, but only supported dates.

So we've been stuck where we'd have to add significant bloat without achieving a good enough UX & design fit to make it worthwhile.

I think either a calendar or more of an 'interactive field' approach would be great, it just needs to look / feel like it belongs to Ghost?

[nightsh]

@ErisDS @JohnONolan I have found this one, any thoughts? I can try it if you think it's worth it.

[JohnONolan]

I really like the one Baremetrics use https://ghost.baremetrics.com (purely from a UX pov)

[nightsh]

But that doesn't have a time picker. I'll try to integrate the date+time one into a fresh install, see how it works.

[kevinansfield]

There's a related issue with date parsing too (once #6184 has been merged):

1. Start a new post and open the PSM
2. Change the month part of value from MM to MMM, e.g. Dec -> December
3. You're shown a validation error despite there being no apparent change in date Published Date cannot currently be in the future.

Looking into the date parsing, the string 08 December 15 @ 11:33 is parsed with the format D MMM HH:mm resulting in the final date of Tue Dec 08 2015 15:33:00 GMT+0000 (GMT).

[mikebranski]

Any more thoughts on a direction for this? I've never been completely satisfied with datetime combo pickers, but, from a UX perspective, I really like Bootstrap Datepicker (includes time): http://eonasdan.github.io/bootstrap-datetimepicker/

Pros

• You can click and type in the field.
• It supports both date and time.
• It has an inline version that works very well on mobile (texted on a Nexus 6P and using Chrome's device emulator).

Cons

• Very heavy dependencies (Bootstrap in particular).
• Keyboard shortcuts for changing the date prevent you from navigating the input itself with the keyboard (might be able to disable these, though).

It could probably be forked and modified to not be so tightly coupled to Bootstrap, but could it also be worth exploring rolling a datetime picker custom to Ghost (and subsequently opening it up later to be a standalone thing, since there aren't many great options in that space)?

[ErisDS]

I think it would be preferable to simplify the issue here by having 2 separate inputs, one for date, and another for time. By doing this we could use the now quite common pikaday for the calendar input, and leave the time input as the browser's default as this is a relatively simple number spinner.

[nuclearpengy]

I like the idea of two inputs. It'll be a lot simpler. :)

[moebiusmania]

hi there! have you checked out Rome datepicker? pure vanilla Javascript, completely customizable look and feel (just a barebone CSS style by default) and based on moment.js . I'm using it in a couple of corporate projects and it's working very well! Oh, and it's well documented :)

[kevinansfield]

Closing this as we now have a full date/time picker with validation for future/past dates in relation to the post status.