Datepicker dropdown editable anchor-button?

[czlang]

Would you consider adding the feature to allow edit date right in anchor-button part (that looks like input anyway)? Maybe optional feature by param? User would invoke date-picker by clicking on the zmdi-apps icon.

I have a working quick&dirty prototype of this in our project (I created editable anchor-input component similar to anchor-button) but I think it would be better if you do it in your style ;-)

[metasoarous]

Wow; Perfect timing! This has just come up as an issue for me as well. My clients are frustrated that they have to click the month arrows hundreds of times when they need to select a date that's a few years away from the current date. Being able to edit the text representation would resolve this issue for us. So major thumbs up from me.

Assuming there's a nontrivial timeline on getting this into re-com, would you be willing to share the source for your implementation @czlang? I'd be putting it into Datview/Datsys and would naturally add you to the contributors list.

An alternative solution for us would be to have a second set of arrows that lets you navigate by year. But I agree that it's intuitive to want to edit the textual representation directly, and would overall prefer that.

[czlang]

need to select a date that's a few years away from the current date

yes, that's exactly use case, birthday etc. Year select also came to my mind, but I also think that straight edit is just better (I certainly don't want to scroll year 80 years ago in select or destroy my finger by clicking that arrow 80 times ;-)).

So here is gist with what I have right now.

I added anchor-input component and input-date component. I'm also playing with some basic format errors alert in input-date. And there is param :input-label (don't like that name) which switches editable input or not.

Maybe that's something to consider or start with ;-)

[danielcompton]

There's a few use cases we should consider here:

• Selecting dates within 2 months either side
• Selecting dates within 5 years either side
• Selecting dates greater than 5 years either side

Selecting dates nearby benefit from the spatial awareness a calendar gives.

Date pickers are helpful when your concerned dates fall within the context of a month or so but not several years apart as jumping between years would require laboriously many clicks.

http://ux.stackexchange.com/questions/49741/when-and-why-should-date-pickers-be-used

When selecting dates more than a few months away, a calendar interface ceases to be helpful (as your users have mentioned). In this case, typing the date may be easier.

When selecting dates many years away, the calendar ceases to be a benefit at all.

I have seen calendar widgets which when you click on the year step backwards to show the months, then the years:

I'm not giving any conclusions, but I think we need to be clear on what use cases we're trying to address with date selections, as it may be more appropriate to give a more straightforward date selector without the calendar at all in some cases.

[metasoarous]

@danielcompton Very reasoned response. For my case in particular, most of the time, the date picker will still be helpful (last five months or so), but every now it'll need to select outside that normal range by a significant number of years. So having both control modes be part of the same widget would be useful. But perhaps I'm in the minority; I don't know. I'd more or less be okay with having to choose between a more straightforward selector and a calendar selector. But assuming there is such a choice, is there harm in providing an option to have both rolled into one (as opt-in) for situations where it's warranted?

[Gregg8]

As mentioned by @danielcompton, the calendar component is generally designed to make it convenient (and visual) to select dates around the current date.

If you had a genealogy app or one where birth dates are routinely entered, then this is probably not the component to use. For that, I would be thinking along the lines of three dropdowns for date, month and year, perhaps each having associated text box.

Our philosophy is that if possible, never leave the component in an invalid state. We worked hard to make the input-time component work this way but achieving the same for an input-date component is much more involved. You would need to work with multiple regional formats (dd-mm-yyyy, mm-dd-yyyy, yyyy-mm-dd, possibly with 2 digit year version as well). You would take into account the differing days in each month and leap years. If you'd entered 2016-08-31 then try to change the 8 to a 9, what should happen?

It's a lot of code to get right.

Daniel's screen shots above are how we would envisage this component be expanded to better cater for dates further away from today. Well, at least the year changer. The decade changer would be optional but nice.

We would certainly be interested in a PR for this.

PS: Currently there's a bug (reported as issue #97) where the datepicker doesn't jump to the date specified by the model and we'll be fixing this shortly.

[czlang]

Just thinking out loud here:

• year select as in picture above imho does not really solve the problem - If user wants to select 1982, its still lots of clicks away
• if user entered 2016-08-31 then try to change the 8 to a 9, there is 2016-0-31 for a moment - in this moment, component should not change inner state of date, but somehow let user know input is invalid and wait for valid input (try parse input date with given format param and catch errors?)
• three dropdowns for date, month and year with inputs - if this would be solved (invalid dates), dropdowns would imho be almost redundant - how do I select 1982 in dropdown? I'll type it. And what if 1982 is not in the list?
• seems to me that day and month selects in @danielcompton picures are useful ok, only year is the problem here
• I don't think I want user to choose if he/she wants datepicker or input. I'd rather remove this step and provide component that can do both in the same time

Let's see how others solved it:

• http://www.daterangepicker.com/#examples - there is datepicker and input. If you type in invalid date, inner state is not changed. Dropdowns for convenience.
• https://jqueryui.com/datepicker/#dropdown-month-year - datepicker, input, dropdowns. Again if you type in invalid date, inner state is not changed.
• gmail - month dropdown, day and year input - looks very good to me. But datepicker is missing ;-)

[Gregg8]

Thanks for persisting. In reality, we don't require a feature like this for our own purposes but clearly you and others do, so it should be done and we would accept a PR for this feature.

We did load your gist and review it and would have the following additional requirements for a PR:

• In the gist, the date you enter must be in the exact format shown (08 Dec, 2016), including leading zero, capital D, comma and 4 digit year. People type dates in many different ways, slash/dash/space delimiters, numeric or alpha month, so it should be happy with all of these, but also, it should know how to interpret dates entered in the current locale. When you enter 8/12/16, it could be either 8-Dec or 12-Aug, depending on the current locale.
• Although you have made it clear when the entered date is invalid through the red border, we still really prefer this never to happen, but with a freeform text field this take a lot of coding, especially when using different separators and locales, but if you can achieve it then great. I guess we're saying this is not 100% mandatory but highly desirable. Certainly it would only update the model when a valid date is found.
• Again not 100% mandatory but given all this work involved, wouldn't it be useful to port the feature to the standard datepicker as well? What do you think? To this end, the best datepicker example above is the jQuery UI one: https://jqueryui.com/datepicker/#dropdown-month-year. It has a solution for selecting distant dates in the main datepicker component as well, using the dropdowns. Note also for the jquery version, when you select the first date in the list, it then repopulates the list so that this new current date is surrounded by older and newer dates, not limiting the year input. The default for the number of older and newer dates could possibly be an argument.

Perhaps you have already enhanced your version of the gist as originally presented so there may not be as much work to turn it into a PR?

[mike-thompson-day8]

When I say "fib ratio", I mean to multiply the existing height of that "top bar" by 0.618 to obtain the "width" of the two buttons on either end.

And, no, this doesn't solve the issue of keyboard entry.