Hacker News Reader

Comment by HugoTea | Hacker News Reader

The Gov.uk design team published research around data entry for dates https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date... Ultimately they found the best experience was three text boxes, day, month and year. They also have this "pattern" for helping with implementation https://design-system.service.gov.uk/patterns/dates/

View on HN

They don't appear to have tested a dropdown for the month name, with text boxes for date and year. I've read elsewhere in UX research that the month name should be preferred, for clarity, over entering another number. So it's unfortunate that that page's research isn't complete ("we will continue our testing") and doesn't appear to have ever been followed up.

(I worked on this pattern) Our guidance is to accept both names and numbers in the back end so people can enter either. In our testing, text inputs (with a numeric keyboard on mobile) is better than selects. Some people struggle with using selects, we don't see those issues in text inputs. That guidance maybe be about people not knowing the order of the inputs (DD MM YY, MM DD YY) but our pattern is clearly labeled for each input so we don't get that issue.

We did continue our testing which resulted in the pattern in the design system which is linked.

I'm not sure of every type of trouble folks might have using selects, but for the subset where using a hardware keyboard is required, you can usually type into a focused select just as you can type into a text input. Getting an Android/iOS on-screen keyboard to do this without a special configuration might not be a thing, I'll admit.

The only tricky part, for me, is deciding whether I should type a state abbreviation or a few letters of the full state name, which in my case differ enough to be quite annoying.

They did some research elsewhere on dropdowns and found a lot of users do not realise they can scroll through the list and would get confused, might be why they ruled out dropdowns entirely for date pickers.

I'm always confused by the anglocentrism of these kinds of ux "standards" because for example in mandarin we call days (三號）, weekdays （星期二 / 禮拜二）, months （二十月）, and years by numbers... And in Japanese they have similar I believe but also have non numbers for weekdays. I imagine other languages have similar flukes, wouldn't be surprised if there was one out there that had special words for the first couple days of the month or something.

> Ultimately they found the best experience was three text boxes, day, month and year

This is what we found was most acceptable for our banking users. They were coming from terminal interfaces. This is a UI/UX flow that we just had to go with. We experimented with fancy date pickers (i.e., <input type='date'>) and it lasted about a month before we were forced to refactor. We kept a date picker icon (exempt from tab order) for novice / younger employees who prefer the tap-tap-tap bs.

If you are replacing a mainframe app with something on the web, the least you can do is make a half-ass attempt to keep the # of physical fields the same and place them in the same tab order. This can make or break your pitch in a competitive B2B SaaS environment. We sold to the users, not to the business. The users then sold to the business for us. You cannot get end users to help sell for you if they don't like the UX. They know they'll have to live with it every day if they successfully advocate for it.

Reply on news.ycombinator.com