[date-picker] Add UX guidelines, cover birthday

[oliviertassinari]

Summary 💡

The UX of the current DatePicker is optimized to help you find end-users a date they don't already know. The date picker optimizes for picking dates that are close to the time the user is using the component, and often with extra informations like availabilities, price, etc.

The problem with a date of birth is that we all know it, what we need a component that is optimized to quickly input it (clear information, fast input, quick feedback loop when making a mistake). We shouldn't have to click 20 times to find the right year, and not get confused about the order between days and month, and so on.

Examples 🌈

• https://www.smashingmagazine.com/2021/05/frustrating-design-patterns-birthday-picker/

• Facebook

• Google
  

Motivation 🔦

I started to look into this from this request: https://groups.google.com/a/mui.com/g/custom-work/c/sz1Xo0_mGAE. https://www.smashingmagazine.com/2021/05/frustrating-design-patterns-birthday-picker/ goes into great length about this problem.

Proposed changes

Going in more depth, I would propose the following actions:

• 1. Encourage developers to ❌ never use the DatePicker component for a birthday (in its current shape).

• 2. Remove the label "Birthday" in https://mui.com/x/react-date-pickers/getting-started/#native-pickers based on point 1.

• 3. Fix the UX to edit the date in the input. When I want to change 18 to 19, as soon as I remove the 8, I'm lost.

  

  https://mui.com/x/react-date-pickers/getting-started/

  I think that we should move away from this textbox implementation, not a great UX.

• 4. Instead, we can encourage to use of 3 autocompletes for the birthday pickers.

• 5. Move to the promotion of https://mui.com/x/react-date-pickers/date-field/#basic-usage once we can display the month in a plain string by default (otherwise what's a day and what's a month? I don't know). I assume would fix all the concerns in https://www.smashingmagazine.com/2021/05/frustrating-design-patterns-birthday-picker/.

e.g. https://retool.com/components/date

Order ID 💳 (optional)

No response

[oliviertassinari]

What not to do with the date picker, I think that we should help developers to avoid this, it's so painful as an end-user:

[LukasTy]

@oliviertassinari Maybe suggesting developers setting

openTo="year"

in cases where they want to use date picker for DOB inputs would help avoid such cases?

[MonstraG]

I've did openTo="year" which was received nicely, but the next immideate concern was that it opened on the very start of the range:

And people will need to scroll down to find their year because pretty much nobody [alive] is born in 1900's.

So, my follow up proposal is to have it open on somwhere around current year instead.

[LukasTy]

@MonstraG The year picker scrolling to the selected date is fixed with but the change would only be released in upcoming v6 release.
What do you @alexfauquette think. Maybe we should cherry-pick your fix into the upcoming patch release?

[oliviertassinari]

Maybe suggesting developers setting openTo="year".

@LukasTy I think it could help, but wouldn't be a great UX. I have updated my initial comment to be clearer with possible steps forward.

[flaviendelangle]

3. Fix the UX to edit the date in the input. When I want to change 18 to 19, as soon as I remove the 8, I'm lost.

The field are going to replace this component so I guess we will never do this one right ?

once we can display the month in a plain string by default (otherwise what's a day and what's a month? I don't know

Not sure to understand this one
The default format is in the adapter and indeed by default the month is in digits
We could reconsider and switch to a full letter month format if the team feel that it's a better default.
Otherwise, if we do a "Recipe" for birthday picking, we could set a custom format on it for full letter month.

---

Side note: We have to make sure that what we are describing above it mobile compatible.
And for now mobile is clearly the weak part of the fields.

[oliviertassinari]

The field are going to replace this component so I guess we will never do this one right?

@flaviendelangle I had the date field in mind as the "fix" when I wrote this :)

Not sure to understand this one

I'm happy to clarify. Say you have entered your birthdate but you are interpreted, you come back to the tab and now you see:

You wonder, is 08 the day or the month? Did I input it right? For example with https://media.interieur.gouv.fr/attestation-deplacement-derogatoire-covid-19/, I was always double checking on this field 😁

are describing above it mobile compatible

Great point

[flaviendelangle]

@flaviendelangle I had the date field in mind as the "fix" when I wrote this :)

👌

I'm happy to clarify. Say you have entered your birthdate but you are interpreted, you come back to the tab and now you see:

OK so you would be in favor of changing the default date format for date field / date pickers ?
Or just to say to people that for birthdays we suggest using a format with full letter months ?

I think I agree that with the new editing, full letter months have better UX once they will be stabilized (you can still type the number, you will type 1-3 letters thanks to the autocompletion, so no longer to type than digits, unlike in today's implementation).

[oliviertassinari]

OK so you would be in favor of changing the default date format for date field / date pickers? Or just to say to people that for birthdays we suggest using a format with full letter months?

@flaviendelangle I was considering birthdays and other cases where you already know the date you want to input.

For the general use (default), I don't know what would be best. But yeah, maybe it should be the same answer for both. Maybe there are multiple valid options:

1. inlined when it needs to be information dense:

2. a placeholder below the input when there is enough space https://next.material-ui-pickers.dev/demo/datetime-picker#basic-usage. It used to be the default, but we removed it because it was taking too much space for most use cases.

3. numbers only for when YOLO is enough, like when you need to localize and it's too much complexity with the full string.

@gerdadesign might have some perspectives on this.

[gerdadesign]

The new date field would certainly be a huge step up for this experience!

I'm not sure if we want to set the default formatting to optimize for birthdates or for other use cases, but it's definitely important to have options to customize it to 19/9/1999 or Sep 19, 1999, etc.

For birthdays specifically, perhaps this could be a good candidate for a Recipe or blog article showcasing customization options and best practices around using multiple indicators for formatting, as well as contextual clues from the rest of the form/page. I suspect there are other factors outside of MUI's input itself that will determine how the user chooses to display the date.

Overall, it seems that no matter whether you choose to display numbers vs words, having more than just the placeholder text show the format is clearer: