We are hit by the bug where a date is not saved, if the the time is empty. There are several issues filed for this but I guess they all have the same or at least a similar cause.
We don't have the necessary mockup knowledge here so I'm offering a financial bounty for fixing this bug. If you feel you can do it and have time for it please contact me to discuss the further details.
tom.schneider [at] fhnw.ch
I built a modified widget that wraps pick-a-date that works for this case (sets time to 00:00 if unentered). The primary purpose of my widget is keyboard entry for date and time, and this works well and is in production.
The catch: it's not in mockup yet. I'm willing to make some effort to do this (gratis) this week, but my issue is that I've used an adapter pattern to instantiate the core widget, then do post-initialization adjustments to how the widget operates re: syncing hidden input, keyboard events. Keyboard entry should have decent l10n.
If I add this to mockup, the path of least mess is to call this widget something different ("TypeADate", or "DateEntry"), and wrap the existing pattern (for now) until things can be refactored. IMHO, there's enough UX fixed here to justify that compromise.
a little unrelated to @tomgross original question:
@seanupton - not sure, if that helps with subclassing: Mockup: subclassing/extending widget patterns
this way you should be able to do near-real subclassing and overload super methods. not sure, if you can call the supermethods - just used it to re-register a pattern under a different name and different trigger.
@seanupton your type-a-date pattern is a lot of code. maybe too much, related your main achievement is to have a default time value and being able to make keyboard based date/time entries. that could be an indicator that pickadate - the base pattern you extend upon - is not the right choice? also there are date parsing libraries, which can be reused.
I'm not totally in love with our datepicker and our time picker sucks a lot. 1) it has all the issues pointed out, 2) it looks like an alien. I do like the various bootstrap datepickers more. But there, a time picker is missing. I'd love to see a time picker like in android (or nokia n9, which was awesome!), based on canvas, with ui patterns like from here: http://anthonyterrien.com/demo/knob/ - still the most efficient time entry method is via a keyboard.
long story short, if a significant amount of time is going to be spent into this issue, we should also consider rewriting it completly and use something else than pickadate.
UK gov have done a fair amount of research on the best date picker and they concluded that simple text boxes or inout was often best but it depends on the date you are askibg for.
A one size fits all solution esp one using js is perhaps not best?
btw, something GDS are very strict on that might get lost in all those links is "progressive enhancement". That means it must still be operable even without JS (even if reduced usability). This is not because they think lots of people turn JS off. It's because lots of things can screw with JS such as slow/intermittent connections or some unforeseen exception.
I think the plone community should defiantly take this to heart. It's a good principle. They call it "designing for all".
I personally think most datetime widgets don't add much except in limited circumstances and our default should perhaps just be text input.
Our original implementation did that, IIRC, but I had some difficulty when moving from Mockup 1.x to 2.x, so I rewrote much of how we approached it. If we replaced PickADate library, I would consider a much different approach vs. current additional layers of progressive enhancement.
This could well be true. PickADate upstream has particular ideological objection to keyboard input, as well.
Yes, we are actually using moment.js to do exactly that, so in theory no unique cost. What I add to the conversation is reasonable configuration to make l10n possible without per-locale configuration, so the payload is in theory going to be smaller with what I have written than including another date parsing library (for the record, Date.js has multiple significant problems).
On size, the TypeADate pattern I wrote is 4.9k gzipped. Half this byte cost for keyboard-friendly input could be made up through efficiencies if we started a new widget from scratch or used something lighter than PickADate.
I agree, maybe the win is in trying something simpler or trying to support better UX out of the gates. That would include deference, IMHO, to native HTML5 pickers on touch devices.