feat(input-date-picker, date-picker): improve date picking experience

[anveshmekala]

Related Issue: #3455

Summary

Update calcite-date-picker & calcite-input-date-picker UI & UX.

Key changes

• display two calendars for range irrespective of layout.
• No longer switches focus from day to end input when startDate is selected initially.
• input is replaced by select menu for year and month.
• No longer positions the date-picker component relative to endInput when endInput is focused in range.
• Dates from previous months are not visible in range calendar.
• Divider indicator icons are removed in horizontal layout for range in input-date-picker.
• No longer uses chevron icon which indicate the open status of input-date-picker in startInput field.

Other issues resolved :
#9167
#6321
#6410

Wiki https://github.com/Esri/calcite-design-system/wiki/date%E2%80%90picker-enhancement-%238402

[macandcheese]

Is the intention that these are separate public components? Or all housed within one public component?

I know the native input can be type="month", but from my understanding, across other design systems, this approach seems (more?) common: https://mui.com/x/react-date-pickers/date-picker/#views

[anveshmekala]

Is the intention that these are separate public components? Or all housed within one public component?

I know the native input can be type="month", but from my understanding, across other design systems, this approach seems (more?) common: https://mui.com/x/react-date-pickers/date-picker/#views

Yeah, the idea is to have independent input-month-picker and input-date-picker components which makes it easier to maintain. Started off with month-picker though which can be used in input-month-picker and also integrated to current date-picker to allow user change month from a dropdown style.

Concurrently, I am testing a different approach to use combobox for input-month-picker and input-year-picker (similar to input-time-zone) which seems promising but wouldn't work if we need to display two scroll bars one for month and one for year.

I also dig the idea mentioned in the issue for input-month-picker which is more like a table with year at the top. It doesn't require two scroll bars.

[macandcheese]

Concurrently, I am testing a different approach to use combobox for input-month-picker and input-year-picker (similar to input-time-zone) which seems promising but wouldn't work if we need to display two scroll bars one for month and one for year.

IMO, this approach is just an implementation of a Combobox, a user can already set something like that up. I'd think ours would be more custom picking experiences like the examples linked in the original issue / Material example (however the components are structured).

I also dig the idea mentioned in the issue for input-month-picker which is more like a table with year at the top. It doesn't require two scroll bars.

Agreed, I think that's more appropriate for a component offering. If it's just a Combobox, we're only setting up an existing component with a set of pre-configured options, not providing a unique selection experience.

[anveshmekala]

Appreciate the feedback @macandcheese . Most of the design specs are updated regarding select menu width, spacing and chevron dimensions.

Some of the items that might need discussion:

Hover state for select menu. Current we do not have a hover state styles for calcite-select and date-picker uses it internally. Do we want to add hover styles specific to date-picker case or is that something we would prefer adding for select component irrespective of the use case

We might want another visual state for a "day item you are about to select but is already part of a range" - it currently just appears grey - when in reality it is about to be selected - MUI has an additional "bordered" visual state for this.

Regarding above, i agree this can be misleading. In the current build while using keyboard, we preserve the highlighted color for the day and add a border to indicate the current focused date. Does this sound like a good option to opt for mouse users as well?

I think the grey "current day" should only apply to the current month + year. Currently it shows for the current "day number" in other months / years in range:

I think this will help the user to understand the active date in a given month. Without the indication, it is hard to guess atleast for the keyboard users which day will be focused when tabbing. Alternate could be focusing first day of the month without the visual grey representation for month-year which are non-current. Thoughts?

cc @SkyeSeitz

[geospatialem]

a11y-wise this is good to go - working great with JAWS and via keyboard. Nice work, @anveshmekala!! ✨

[SkyeSeitz]

Hover state for select menu. Current we do not have a hover state styles for calcite-select and date-picker uses it internally. Do we want to add hover styles specific to date-picker case or is that something we would prefer adding for select component irrespective of the use case

Since Select currently matches Combobox, I don't think I would recommend adding a hover state beyond the existing behavior to Select for now. It somewhat matches MUI's month picker with just a hover state on the chevron itself.

Regarding above, i agree this can be misleading. In the current build while using keyboard, we preserve the highlighted color for the day and add a border to indicate the current focused date. Does this sound like a good option to opt for mouse users as well?

Agreed, this works great for keyboard usage and would improve mouse usage as well.

I think this will help the user to understand the active date in a given month. Without the indication, it is hard to guess atleast for the keyboard users which day will be focused when tabbing. Alternate could be focusing first day of the month without the visual grey representation for month-year which are non-current. Thoughts?

IMO current day should be specific to “today’s” month and year. Same day in another year or month should not display as current day. Focusing when current day is not in view, focusing first day of the month feels expected.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. Please close your PR if it is no longer relevant. Thank you for your contributions.