> > 4. Use masks for such fields as dates and phone numbers so that users don't guess the correct format.
> Strong disagree, with prejudice. Masks are evil. Unqualifiedly so. It’s difficult to implement them in a way that won’t lead to unpleasant surprises anywhere, and outright impossible on the web. Do not use masks. Rather, prefer to validate and reshape data afterwards. e.g. accept all kinds of date formats, then on blur rewrite it to an unambiguous and well-understood format if possible, or at least a canonical and clearly-described format (e.g. for dates if you really want to put the month as a number rather than a name, make sure the order is clear, otherwise you’ll confuse either those pestiferous middle-endian people or the rest of the world).
I get the argument, but how would you determine something like 06/09/2021? In the US, that would mean 9th June, but in most of the world it means 6th September. The format doesn't give us any clues as to which.
Granted, masks, don't help us out here either (!), but structuring the input might?
The gold standard for avoiding ambiguity is to normalise to a format with month names: so for a US-centric thing, you’d normalise “06/09/2021” to “June 9, 2021”, and for the rest of the world, you’d normalise it to “6 September 2021” or a similar format. This is one way of clearly describing what you’re doing. But if you’re definitely doing numeric dates, then you need to label it to at least minimise the scope for confusion, like writing “DD/MM/YYYY” above or below it. (Another option, shown by the OP, is splitting day, month and year into separate text boxes. I have mixed feelings about that technique, as it suffers from expectation issues: if you shift focus automatically as you type, you’ll upset some users, and if you don’t you’ll surprise other users.)
As an example of doing all this well in practice, I like how snoozing an email in Fastmail for a custom period of time works. You get a little popup with a date text box and a time text box on one row, then below it a couple of renderings of the date and time it’ll snooze until, and the Save button on the right of that. If I type “tuesday” into the date text box (which it interprets as “next Tuesday” since it needs a future time), the two lines below change to “Tue 25 May 8:00 AM” / “In 3 days 9 hours”, and when I then blur the text box, its value is normalised to “25/05/2021”. (I also feel like mentioning that when the date is in this normalised format and there is no selection, the Up and Down keys work as you might desire, wherever your cursor is in the date field, increasing or decreasing the date by a day, month or year, and keeping the cursor in the same position. nmjenkins does a thorough job on this sort of interaction design, he was a pleasure to work with when I was at Fastmail for a few years.)
(This is all proper-endian dates because I have Fastmail in the British English locale. If it was in American English, it’d have normalised to the middle-endian abomination that is “05/25/2021”, and the first description line might have been similarly ordered differently, though I haven’t confirmed that one.)
Of course, the types of values you should accept will vary by the semantics of the date. If you’re asking someone for their date of birth, parsing “tuesday” is probably not useful or helpful!
> Strong disagree, with prejudice. Masks are evil. Unqualifiedly so. It’s difficult to implement them in a way that won’t lead to unpleasant surprises anywhere, and outright impossible on the web. Do not use masks. Rather, prefer to validate and reshape data afterwards. e.g. accept all kinds of date formats, then on blur rewrite it to an unambiguous and well-understood format if possible, or at least a canonical and clearly-described format (e.g. for dates if you really want to put the month as a number rather than a name, make sure the order is clear, otherwise you’ll confuse either those pestiferous middle-endian people or the rest of the world).
I get the argument, but how would you determine something like 06/09/2021? In the US, that would mean 9th June, but in most of the world it means 6th September. The format doesn't give us any clues as to which.
Granted, masks, don't help us out here either (!), but structuring the input might?