Microsoft-ui-xaml: Proposal: Ability to type a date into CalendarDatePicker

[tbolon]

Proposal: Better keyboard input on CalendarDatePicker

Summary

Allow the CalendarDatePicker to be better used with the keyboard, allowing direct date input with numeric values (numbers and date separator) instead of relying on the calendar navigation (space/enter/arrow keys) which is really slow.

Rationale

• better feature alignment with existing native controls (winforms and wpf): both of them allow to type the date value when the control is focused (eg. 5/5/19)
• address more LOB scenarios where date fields are used a lot, remove pain points when converting from other ui frameworks
• focus more on efficiency (number of key press required)

Scope

| Capability | Priority |
| :---------- | :------- |
| Allow end users to quickly type a date only using numbers and date separator | Must |
| Use system short date format to parse input | Must |
| Allow relaxed inputs (suppose current year if missing) | Must |
| Ignore any invalid input and revert to last valid value | Should |
| This input method is optional and could be disabled to keep current behavior | Should |
| Allow number block navigation using keys (pressing right key while focused on month part should move to the year part) | Could |
| Allow date computation using quick formulas (+2d to add two days to current date) | Could |
| Handle complex input with custom date format | Won't |

Important Notes

We are considering migrating our lob app on WinUI, but are not really impressed by the native controls exposed.

Open Questions

I know that this framework is still quite new, and is still a lot oriented on smartphones/tablets and mouse/touch input, but if you want to allow developers to create more LOB apps, I think you should add more keyboard and efficiency focused features.

I also created this suggestion because a demo was presented at the build for an input control with a calculator feature (#483). This feature seems to be oriented on business users, like this one.

Related: this feature could also target the DatePicker control to better allow keyboard based input (still based on date value instead of control navigation) and/or allow typing a value using arrow keys without needing the popup control.

[YuliKl]

@tbolon - To summarize, you're proposing the ability to type in a date without the need to open any sort of picker. Is that correct? While this capability is relevant for both CalendarDatePicker and DatePicker, you don't need multiple controls that support this? Would a TextBox with date-specific data validation meet your needs? (I'm not proposing that we add more complexity to TextBox, just trying to fully understand your requirements.)

[mdtauk]

What about an IsEditable property on the DatePicker where you can type in a date even when the scrolling pop-up or calendar flyout opens - maybe it can even try to autocomplete as you type?

[tbolon]

To summarize, you're proposing the ability to type in a date without the need to open any sort of picker. Is that correct?

Yes, but more important, to be able to do it quickly.

While this capability is relevant for both CalendarDatePicker and DatePicker, you don't need multiple controls that support this?

Beside the TimePicker, I don't think of other controls which could benefit from easier keyboard input. We could discuss about the sliders which could accept the number pressed by the users (for a slider moving between 1 and 100, if the user press '4' it moves to the value 4, then '0' within a certain delay, it moves to '40'), but I think the date input is the most

Would a TextBox with date-specific data validation meet your needs? (I'm not proposing that we add more complexity to TextBox, just trying to fully understand your requirements.)

It could, but only if the calendar picker is still available, because we don't want to restraint to this type of input. We want to allow users to input values more easily when possible, but still make the control easy to discover.

Also, a TextBox with free typing is not the best method I could think of. See this screenshots from the default winforms DateTimePicker, and how it allows to quickly type values using only the keyboard.

Here I pressed TAB, 1, 0, /, 4, /,1, 8, TAB

Here I pressed TAB, 1, 9, -, 1, 2,-, 3, 1, TAB

Note that I can also move between date parts using the left and right arrow keys, and that the control recognize a lot of characters are part separator (,, /, -, ...)

I don't want you to use the exact same feature, but I want to emphasis the fact that I could type any date really quick using this interface.

[kikisaints]

I'm in agreement with @mdtauk here - similar to how we did IsEditable on ComboBox, we could do the same on CalendarDatePicker. Same mental model, wouldn't be introducing any new concepts or controls, and we could still fine-tune it to make sure it was easy and fast to do.

[tbolon]

I just wanted to point that as of now, the control seems to be really focused on mouse/touch input, and barely usable with keyboard only compared to controls available on other UI frameworks.

Of course, adding too much complexity is not desired, as it could be solved with a custom control.

Finding a way to address at least partially this problem without adding any complexity or new controls is the best I could hope :)

[rapcgutz]

Use Flyouts for CalendawView the show it when the users click the Calendar Icon and create a separate Textbox for users input and bind the Text Property with Notify property change.

Validate and Format the text every time the users input a new value. hope it help!

[kikisaints]

Following up on this - I think it's a great suggestion, but at this time we don't have the resources to implement right away because of our WinUI 3.0 effort.

[robloo]

I ran across a strong need for this as well. When selecting a date close to today the calendar flyout selection works fine. However, when the date is say 10 years before present, that requires a lot of clicks in the calendar flyout. Additionally, those clicks are not 100% intuitive for all users (navigating back to decade view, etc.).

The ability to type in a date directly will be extremely useful and bring this control more-or-less to parity with WPF's DatePicker.

Some concerns: localization and parsing of the date format must be handled correctly. C++/WinRT and C#/.net have two different ways of handling localization and this is causing concerns with these types of scenarios. (NumberBox as well #483)