search

mui / mui-x

MUI X: Build complex and data-rich applications using a growing list of advanced React components, like the Data Grid, Date and Time Pickers, Charts, and more!
https://mui.com/x/
4.04k stars 1.25k forks source link

[date-picker] Add UX guidelines, cover birthday #5021

Open oliviertassinari opened 2 years ago

oliviertassinari commented 2 years ago

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 🌈

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:

Screenshot 2022-05-26 at 15 54 42

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

Order ID 💳 (optional)

No response

oliviertassinari commented 2 years ago

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:

Screenshot 2022-07-26 at 23 57 23
LukasTy commented 2 years ago

@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 commented 1 year ago

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: image

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago
  1. 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 commented 1 year ago

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:

Screenshot 2022-09-19 at 17 53 40

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 😁

Screenshot 2022-09-19 at 17 55 38

are describing above it mobile compatible

Great point

flaviendelangle commented 1 year ago

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

:ok_hand:

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 commented 1 year ago

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:
Screenshot 2022-09-19 at 20 00 32
  1. 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.
Screenshot 2022-09-19 at 19 58 57
  1. 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 commented 1 year ago

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: Screen Shot 2022-10-04 at 5 33 12 PM (2)