[pickers] Time Picker / Date Time Picker do not include a UI view

[sphinx9]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Steps to reproduce 🕹

Link to live example: https://next.mui.com/x/react-date-pickers/time-picker/
Link to live example: https://next.mui.com/x/react-date-pickers/date-time-picker/

Current behavior 😯

The desktop variation of TimePicker does not include any form of picker for selecting a time - it's basically the same as the new 'Field component'. Additionally, the desktop variation of the DateTimePicker component includes a date picker, but not a time picker. The mobile and static variations of the aforementioned components are fine and include a time picker, as expected.

Expected behavior 🤔

...there should be a time picker in the Date Time Picker and Time Picker components.

Context 🔦

No response

Your environment 🌎

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Order ID 💳 (optional)

No response

[flaviendelangle]

Hi,

Thanks for your feedback
You have more context on the migration guide and on #4483.

From the feedback we gathered from the community, the Clock is not a good way of picking a date on destkop.
We preferred to rely only on the field editing at first, to be able to remove the Clock in a minor release without waiting for v7.
This seems to be a good trade-off because people can add back the Clock very easily if they want to.
The work is already quite advanced for this new UI, so it should be for one of the first release after the stable, but we can't give a precise deadline yet.

[flaviendelangle]

Maybe we should add a note on the TimePicker and DateTimePicker v6 pages to briefly explain that

[oliviertassinari]

If I understand the use case correctly, the "popover" is meant for end-users that are using their mouse pointer, but are either:

1. too lazy to switch to the keyboard. It makes sense, it can be more effort to move its hand to press a keystroke than moving the cursor and clicking a bit.
2. are used to the popover UX pattern. They don't even think about using their keyboard.

?

[LukasTy]

If I understand the use case correctly, the "popover" is meant for end-users that are using their mouse pointer, but are either:

1. too lazy to switch to the keyboard. It makes sense, it can be more effort to move its hand to press a keystroke than moving the cursor and clicking a bit.
2. are used to the popover UX pattern. They don't even think about using their keyboard.

?

Yes, I'd agree with both of your assumptions. We need to take care of as many possible use cases as possible and it's probably only a small percentage of power users, who, would be very happy with the approach of the new field and use only it to enter data, but the majority of casual users are probably used to having some sort of mouse/view based behaviors of interacting with data. 👍

[oliviertassinari]

@sphinx9 So to be clear, we moved your pain point to #4483, you can subscribe to this issue close event.