Usability issues in DateField/DatePicker

[ttsirkia]

Provide your feedback here.

The documentation writes the following:

Accessible – Each date and time unit is displayed as an individually focusable and editable segment, which allows users an easy way to edit dates using the keyboard, in any date format and locale.

However, after my experiences of using DateField/DatePicker, I've found the following issues which - at least in my opinion - decrease the usability quite a lot when user is typing the dates.

Some of these findings are only related to locales in format "dd-mm-yyyy" or "dd.mm.yyyy".

• Even if the placeholder indicates "dd.mm.yyyy", it does not accept a leading zero
  • This might be related to shouldForceLeadingZeros and how it behaves without this forcing. If the locale doesn't show the leading zero, maybe the zero-digit typed by the user should be shown but could disappear after the focus changes to another cell.
• If the value has only one digit, it is not possible to move to next cell by typing the separator character (such as dash or dot)
• Typing the digits automatically moves the focus to the next cell but backspacing does not move back to the previous cell (Backspace on an empty DateSegment should focusPrevious #5261, fixed with Fix backspace to shift focus to previous element in useDateSegment #5715)
• Some dates cannot be entered at all, such as "29-02-2020" (DateField/useDateField doesn't accept leap day on initial input #4181, bug: useDatePicker sometimes limits day of month to 30 #3256)
• It is not possible to copy & paste dates (Copy and Paste support for DateField and TimeField #5285)
• The field cannot be emptied by pressing Ctrl+A and Backspace/Delete
• It is not possible to use normal arrow keys to move inside a single cell to correct writing because arrow keys always moves between the cells

🔦 Context

Users who expect that the DateField would behave more like a traditional text field will find different kind of issues which might decrease the usability of the component.

💻 Code Sample

No response

Version

October 02, 2023 Release

What browsers are you seeing the problem on?

Firefox, Chrome, Microsoft Edge

If other, please specify

No response

What operating system are you using?

Windows

[reidbarber]

Thanks for the feedback!

Even if the placeholder indicates "dd.mm.yyyy", it does not accept a leading zero

Wouldn't the leading zero get cleared on blur of the segment anyway? I can see how the user might be confused that the input didn't update, so there is an argument for that. Maybe this is more important if leading zeros need to persist in some locales.

If the value has only one digit, it is not possible to move to next cell by typing the separator character (such as dash or dot)

This seems like a good enhancement.

Typing the digits automatically moves the focus to the next cell but backspacing does not move back to the previous cell

I think this would be good behavior, but probably needs some more discussion. I think this would only make sense if the field segment has just been cleared, or is still empty.

It is not possible to copy & paste dates (#5285)

This would be a good enhancement, and we could use useClipboard to achieve this.

The field cannot be emptied by pressing Ctrl+A and Backspace/Delete

This is a difficult one since I don't think there is a way to select multiple inputs at once. We could consider another key combination that could clear the entire field, however.

It is not possible to use normal arrow keys to move inside a single cell to correct writing because arrow keys always moves between the cells

I don't think we'll want to change this behavior. Users are going to be accustomed to using left/right to go to the next/previous segments so this would be a big change. Users can use up/down arrows or can clear and type to edit fields, so I don't think the user experience would be improved.

[ttsirkia]

Even if the placeholder indicates "dd.mm.yyyy", it does not accept a leading zero

Wouldn't the leading zero get cleared on blur of the segment anyway? I can see how the user might be confused that the input didn't update, so there is an argument for that. Maybe this is more important if leading zeros need to persist in some locales.

The issue is that when showing the pattern "dd-mm-yyyy" for the user, it explicitly tells to have the leading zeros. If they are not required, the pattern should be "d-m-yyyy". This at least the interpretation in fi-FI locale and there is a difference if you have one or two letters.

Now if the user notices that two digits are required, it is very confusing that visually nothing happens although there is a behavioral difference: when typing 01 the cursor jumps to the next cell but when typing only 1 this won't happen. User cannot see any difference here as the zero is not shown when typing.

Typing the digits automatically moves the focus to the next cell but backspacing does not move back to the previous cell

I think this would be good behavior, but probably needs some more discussion. I think this would only make sense if the field has just been cleared, or is still empty.

Even if there is an earlier typed value filled in the field, one could expect that by backspacing it is possible to empty the whole date. If the cell automatically jumps forward, it should also jump backwards - or do nothing in both cases. So basically when the cell is empty and you still press backspace, it should remove the last digit from the previous cell and jump to that cell.

[reidbarber]

I think this would be good behavior, but probably needs some more discussion. I think this would only make sense if the field segment has just been cleared, or is still empty.

I should have used segment here instead of field.

[ttsirkia]

Backspace can now be used to move previous segment, although one additional keystroke is required compared to a traditional text field. #5715

[ttsirkia]

To shorten this list, I have the following implementation suggestion for the topic "Typing a separator should move to the next segment".

There could be a new internal state variable inside useDateSegment to indicate if the value of the segment has been changed by typing while the focus has been inside the segment and the value of the segment has changed. This internal state would be reset every time the segment gets the focus.

With this addition, the following rule could be implemented: If the user has typed a value and after that types any of these characters .:-/ and the value of the field is not its placeholder value, the focus manager should move the focus to the next segment.

I would like to allow all those characters because especially with mobile devices, the keyboard does not show all relevant characters in numerical input mode and you could, for example, use always a dot to move to the next segment.

Two examples, locale with format dd.mm.yyyy is expected:

• User types 1. which after the day is set to 1 and the focus is in the month segment
• User types 13. which after the day is set to 13 and the focus is in the month segment.

Notice especially the behavior in the second case: you can always type the separator but as the month field either contains a placeholder value or existing value which is not changed, the focus remains in the month segment instead of jumping to the year segment. User can always type the separator character regardless of the number of digits in the segment.

What is your opinion @reidbarber and @devongovett ? I'd be happy to open a PR for this if you agree with the details.