[pickers] Research the best approach when using a calendar view in composition with the new Date fields.

[joserodolfofreitas]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Summary 💡

In spectrum and kendoUI, the keyboard navigation is drastically different when the Focus is on the calendar view vs the text field. The focus moves to the calendar view after event (usually click) on the calendar icon, and when the focus is on the view, you can navigate the dates with arrow keys as you navigate on a grid. Up and down decrement/increment weeks, left and right decrement/increment days. In this case, the navigation affects the text field indirectly only, by updating the value handled by the component.

Retool opens the calendar view when the text field has focus, which means the calendar view never gets direct keyboard Focus (tab moves forward to another field, or end date in date-range). The calendar view is updated indirectly, as the value handled by the component updates. Up and down decrement/increment days, Left and right move the cursor in the text field.

With a property like openCalendarOnFocus the user will be picking between:

Behavior 1 (openCalendarOnFocus === true):

• Calendar doesn’t get keyboard focus (no grid-like navigation on dates).
• Keyboard navigates inside input only
  • Up/down arrows updates month/day/year/etc isolated
  • left/right arrows moves the cursor in text field
  • calendar view is updated accordingly
• Direct interaction with the calendar view is basically through mouse/trackpad only

Question: Would we show the calendar icon? (probably unnecessary - users could still add the icon adornment if they wish)

Behavior 2 (openCalendarOnFocus === false|undefined):

• Calendar view gets keyboard focus when open
• Keyboard navigates in calendar view (grid-like navigation enabled)
  • Up/down arrows decrement/increment weeks
  • left/right arrows decrement/increment days
  • Text field is updated accordingly
• Keyboard still navigates in input (when calendar view is not open*)
  • Up/down arrows updates month/day/year/etc isolated
  • left/right arrows moves the cursor in text field

*Question: Spectrum and Kendo close the calendar view if focus moves back to text field (Kendo still shows calendar until first update on text field). Once the calendar view is open by user interaction, is it feasible (does it make sense) to default to Behavior 1 if the focus moves back to the text field? A potential problem is: how would keyboard focus return to the calendar?

———————————————

From a product perspective, those two are very different behaviors to the end users. As a component provider, it’s potentially great to have the flexibility to support both workflows, but:

1. How feasible (and how costly) it is to have both behaviors implemented.
2. If the answer to the prior question is positive. I assume it makes sense to have Behavior 2 anyway (because of our legacy implementation), but considering limited “implementation resources” and everything the implementations entail, we’ll probably have to pick what we’re going to implement first. This leads to the next question:
3. When the two behaviors are available, what’s going to be the default? openCalendarOnFocus === false? Maybe we need UX research to make a decision on this.

Context

• Date pickers UX goals

Examples 🌈

Spectrum: https://react-spectrum.adobe.com/react-spectrum/DatePicker.html

Retool: https://retool.com/components/date

KendoUI: https://www.telerik.com/kendo-react-ui/components/dateinputs/datepicker/

[joserodolfofreitas]

Cal.com has an interesting approach here. It opens the view on focus, and keeps the selection state mirrored.

Overall, the component UX feels good (if you use it without pushing the edges), especially on the date field combined with mouse input. But the keyboard navigation on the calendar view is very poor, basically you have to navigate day by day with tabs. (You also reach the view with tab, after the focus on the adornment) (I don't understand why they are not using the arrow keys on the calendar view, could there be a technical challenge, @flaviendelangle? )

But there are other behaviors on cal.com that seemed a bit off:

• it needs at least the years to mirror the state on the calendar view (it could assume the current year), since the year is usually the last input on an empty field)
• Editing the range on the calendar view is not mirrored by the input (which I understand it adds too much complexity with little value in return).
• Seems to be easy to make the calendar view lose track of what month it needs to show.

Here's a demo usage video:

https://user-images.githubusercontent.com/550141/191995795-c07a170e-54bd-4baf-b3a3-6f22b1354ed5.mp4

[LukasTy]

Directly related to https://github.com/mui/mui-x/issues/5368, which should (would) be solved together.