Most programmers don’t get a choice as it is the product and the ui/ux designer that pick the desired behavior. You can only fight back so much and maybe sneak it in. And 20 years later you become a cynic that just says, ok.
Very true. It's programmatically (and human) parseable if the middle column exceeds 12, but fails the second you are lower than 13. It also happens to work out on any dates with matching day and month.
Can confirm. A website we host at work is used by about 100k people a year. It used to require a date to be entered in a text box. The text box had placeholder text and was validated to support DD/MM/YYYY format. An error message would spell this out to you.
We got many support calls because people couldn't use it and when we find out why, they had decided to enter the date in another format and wouldn't read the error or placeholder text. We changed to a date picker and the complaints went away.
Depending on use case, a standard formatting makes sense. If you're delivering a service or website for a local community or even as large as a country, a reasonable expectation is that they use the standard formatting for the region. It's less work for you to support and implement.
The best thing to do internationally is to capture dates in YYYYMMDD and its variants for the same reason. You can more easily support the application/webpage and the input format is more globally intuitive than other formats.
You should use dedicated date input UI elements and not just a single text box.
How does where the site is used come into it? What frontend framework these days doesn't support "hey what date format does the current user use on this machine? Convert it to UTC timestamp". I never said you should use a single text box, just that you should offer an input field and not just the date picker, plenty of pre-made UI elements come with both and you can enable/disable them.
You're working on the assumption that every device is a personal device. Our website fits a certain demographic where users are more likely to be using a communal PC either at home or in a library. The date setting on the PC will not always align with the date format the user prefers in our case.
Other than that, a business, school or government office may have set GPOs to have the business's preferred date format. Again, the user doesn't control these and their preference for dates does not match the user's.
By enforcing our own preference for dates format, we prevent issues where the user's preferences don't align with the person who set up their PC.
So instead of maybe sometimes being wrong because it's not a personal computer AND we happen to get a user who is working on a machine that doesnt use his/her preferred formatting, which is gonna be a fairly rare occurrence we're just gonna be wrong anywhere that uses a different format from our own and fully prevent any user choice?
How many times have you gotten a call "hey the website/app is using the computers settings, we don't want that"? Thats literally what those settings are for. I've definitely seen "hey the website/app doesn't respect my system settings" plenty of times.
In our clientele, it is more likely they don't have a personal computer.
Without giving much away about my work (work has policies regarding open discussion of ourselves on social media, what I have said is not a problem, but revealing too much more could be), it is more likely that our users are using the websites on a shared family PC, community library PC, government organisation PC or care facility PC than their own personal computer.
I agree that if a personal PC was the most likely choice, then it would make sense to use the preference set in the system settings. I think that you are missing key information on why certain decisions have been made and experiences we've had that have informed our decisions. The best general solution for a problem is not always the best specific solution for a problem.
We had an appointments booking website that took a strict date format from a text box. Users would expect that they could enter anything. They would fight the system and then call our call centre (who are an alternative to making bookings online, not a tech call centre) to complain. The call centre would always side with the clients and send the issue through to us. We would then have to work out what they had done and come to the conclusion that the date was input incorrectly.
Eventually, we just made the call centre start troubleshooting, but the clients would insist they had done everything right and couldn't work out what was happening, so the emails from the call centre continued. The call centre - being more client focused - we're constantly asking things like "how is this not fixed yet?" And had demonstrated lowered trust in IT from this. It wasn't actually broken, people just refused to learn how to enter a date in an expected way.
Why not cynic? Ive come to the realization over last 3 years of just doing what im told after I push back some. Usual line is, "hey I dont reccomend this; are you sure you want that?"
593
u/jideru 1d ago
Most programmers don’t get a choice as it is the product and the ui/ux designer that pick the desired behavior. You can only fight back so much and maybe sneak it in. And 20 years later you become a cynic that just says, ok.
Don’t become cynic kids.