[pickers] UX design review v6.3.0 TimePicker component

[oliviertassinari]

This is a design review on #7958, reporting all the design issues that I can spot cc @gerdadesign

Same as #7440, I think that these could be great items that Nora could work on.

1. Input blur

On https://mui.com/x/react-date-pickers/time-picker/#basic-usage, the input is blurred when reaching for the icon to open the panel and focused back again. It's distracting & confusing:

Screen.Recording.2023-05-12.at.02.27.12.mov

To compare the UX with https://mui.com/material-ui/react-autocomplete/#combo-box feels better, it doesn't blur:

Screen.Recording.2023-05-12.at.02.31.49.mov

2. AM/PM early exit

https://mui.com/x/react-date-pickers/time-picker/#basic-usage I don't understand why selecting AM or PM validates the value, I didn't press the OK button yet.

Screen.Recording.2023-05-12.at.02.33.57.mov

3. OK button & Autovaliation

https://mui.com/x/react-date-pickers/time-picker/#basic-usage I don't understand what the OK button is for.

When I blur or press Enter the value is still persisted.

If the value would be cleared, I would understand, but it's not the case, it's not like with Ant Design: https://ant.design/components/date-picker#components-date-picker-demo-switchable.

I think that it would be great to have two modes:

a. the current one but without the OK button, it's sets a wrong expectation
b. the Ant Design like UX (a tradeoff that reduce end-user mistakes).

4. Laggy keyboard interaction

Open https://mui.com/x/react-date-pickers/time-picker/#basic-usage and start using the keyboard, it feels like it lags behind

Screen.Recording.2023-05-12.at.02.37.17.mov

when you press a bit too much the button, the list doesn't move. I would expect no animations and an instant handling of the keyboard events.

I understand the use case for the mouse though, since you can't spam clicks, it makes sense to have this smooth animation.

5. Time slot spacing

I feel like there could be a bit more right spacing for the scrollbar:

maybe a few more pixels (1? 2? 3?) like in Ant Design, this feels better:

https://ant.design/components/date-picker#components-date-picker-demo-switchable

But overall, I think that the design direction taken by the Ant Design and the native time picker feels better:

A smaller height (to see more options at once), a larger width (to still have enough space to click/tap on it).

[oliviertassinari]

I have found another important design issue:

6. Handle touch start

On https://mui.com/x/react-date-pickers/time-picker/#basic-usage the clock only responds on "touch move" and "touch end". It should respond on "touch start" too, this is wrong:

Screen.Recording.2023-05-12.at.15.18.17.mov

You can compare the UX on a native Android time picker, this feels good:

Screen.Recording.2023-05-12.at.15.51.56.mov

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time

It also feels correct in http://react-toolbox.io/#/components/time_picker too.

[gerdadesign]

@oliviertassinari Can you elaborate on 1? I'm not seeing any blurriness.

2 & 3. These should be two methods:

• If no action bar, selecting the final column should accept the input & close
• If action bar is present, selecting OK should accept the input & close

4. I think this has been fixed? I don't experience the same thing now.

5. Our current pickers and ant design are same width (48px). However, I am exploring updates for small / large sizes, primarily to adjust for desktop / mobile. Here's a preview with the scrollbars (Mac: on hover + on focus)

[oliviertassinari]

Can you elaborate on 1? I'm not seeing any blurriness.

@gerdadesign I'm referring to https://developer.mozilla.org/en-US/docs/Web/API/Element/blur_event

2 & 3. These should be two methods:

I was thinking of something in this line:

• If no action bar, any value selected is instantly propagated
• If action bar is present, selecting OK should accept the input & close

The close of selecting the final value feels really strange to me. I'm not picking the value in the order they are shown. I think that it would be great to test this with end-users, but alternatively, is there any other date picker that behaves like this end users would have been taught on? I can't remember any.

4. I think this has been fixed? I don't experience the same thing now.

I can reproduce it on the latest version. It might be because of my setting:

[oliviertassinari]

I have found a few other design issues, that are probably not important in the context of a time picker, since they are keyboard related, and using the popular to use the keyboard is strange, why are you not using the input in the first place?

However, they feel noticeable in a date time picker https://mui.com/x/react-date-pickers/date-time-picker/ or range #9528.

7. Unstable element position

Compare these 3 cases:

a. https://v4.mui.com/components/pickers/#time-pickers

Screen.Recording.2023-08-11.at.15.18.36.mov

b. https://mui.com/material-ui/react-autocomplete/#combo-box

Screen.Recording.2023-08-11.at.15.18.07.mov

c. https://mui.com/x/react-date-pickers/time-picker/#basic-usage

Screen.Recording.2023-08-11.at.15.18.22.mov

a and b feels great but c feels really annoying not to have a stable element focus position.

8. Keyboard arrow left & right

I wonder if we don't miss the handling of ArrowLeft & ArrowRight. For example https://v4.mui.com/components/pickers/#time-pickers

Screen.Recording.2023-08-11.at.15.13.15.mov

9. No contrast of focus visible

The focus visible has barely any contrast. In

Screen.Recording.2023-08-11.at.15.15.05.mov

Can you see the focus move?

[noraleonte]

1. Seems to work differently now, but there's a flickering so I'm opening an issue for that. It's the same for all pickers.

   time.picker.flickering.mp4

2. There's a closeOnSelect prop that is true by default for desktop pickers that we can set to false and this behavior is overriden 👌

3. I agree that the flow is a bit weird. By default, any change caused by an interaction with the views is registered. I think we need an easier way to control what happens on closing the pickers. Something like:

   • if there is an ok button, closing the picker resets the value.
   • users should be able to easily override this behavior with onClose and onAccept lifecycle methods for instance
   • if there is no ok button, the behavior should be the same as it is now.
     [TimePicker] Design review - Refine onClose and onAccept behavior #14739

4. Seems to be fixed 👌

5. Same as [pickers] Time section scroll bar gets in front of section column #9311

6. Fixed 👌

7. [TimePicker] Design review - Unstable element position in picker #14740

8. [TimePicker] Design review - Left and right arrow key handling is missing #14741

9. [TimePicker] Design review - Contrast of focus visible is too low #14742