I've read many articles about the best UI practice for a user to their own birthdate, but what would you consider the best practice for a user, such as a nurse, to enter in a patient's birthdate?

When entering in your own birthdate the UX argument is a user has entered their birthdate so many times that a specific pattern works best.

But the same logic doesn't apply to the nurse entering a patients birthday. So what do you reckon? A single text field? Dropdowns? 3 fields (MM-DD-YYYY)? I think we all can rule out a datepicker.

4 Answers 4


I recently provided an example of an app I was working on for this exact use case, a nurse entering a patient's birth date: Should I ask the user to enter their age or their birthday?

  • I think this would be a great solution if our app wasn't solely a desktop app. Using your solution on desktop mean a user would use a mouse to choose month and day, then have to use keyboard for the year. When we expand to mobile, I will definitely consider this solution though! Commented Dec 9, 2015 at 23:43

Assuming this is a desktop application I would use a date picker in tandem with a single field that automatically masks the entry. The input should be masked using mm/dd/yyyy so the user doesn't need to worry about format. The user should be able to tab to the field and I would provided some type of example format close by such as a placeholder or example below the field. I work designing business applications for efficiency. While date pickers can helpful, most of the time I observe users, when given the choice to enter or pick from a datepicker, enter directly in the field as they tab along the form. It's faster to key the date when filling out the form repeatedly throughout the day, especially when your on the phone with a customer and your call que is backing up. Datepickers require you to switch from keyboard mode back to a mouse and slows down the process.

For an example of a decent datepicker see this date picker that is also tabable and can be masked.

  • Not so fast. It should use the regional settings configured by the user on their machine. As a New Zealander working in New Zealand, I expect every application to work with dd/mm/yyyy because that's how we do things here - an app that forces something else slows me down a lot. Similarly, if I were Japanese and living in Chicago, I'd expect to be able to choose between the yyyy/mm/dd that I grew up with and the local mm/dd/yyyy convention.
    – Bevan
    Commented Nov 22, 2015 at 17:49
  • The Op never indicated the need for internationalization or even indicated a country. Therefore the answer can only be given based on limited input and from my perspective. Assuming internationalization or multicultural use as a requirement is a bit presumtious and may introduce requirements that are not needed. However if the Op can provide further clarification I would be happy to clarify my answer.
    – Mark
    Commented Nov 22, 2015 at 18:36
  • In addition the Op sounded like a business application need. Many companies do not allow for customized settings on internal hardware.
    – Mark
    Commented Nov 22, 2015 at 18:49
  • Both good points @Mark. I'd suggest a minor edit to: "The input should be masked (e.g. mm/dd/yyyy) so the user doesn't need to worry about format."
    – Bevan
    Commented Nov 22, 2015 at 19:14
  • Our app is used by criminal justice departments in the US only, so no need for internationalization at this point. Commented Dec 9, 2015 at 23:51

If we're talking HTML, I'd consider using a single field of type date so modern browsers can provide the user with dynamic date validation and input help, and mobile browsers will display a native date spinner or other similar control.

This could be a slight problem if the staff don't use modern browsers, since the date input format (a.k.a. its presentation format) will vary by browser (older browsers will mandate the uncomfortable YYYY-MM-DD format, newer browsers use the system locale for date format, very old browsers will treat the field as a plain text field without validating it at all). That means it's impossible to provide useful input format hints (placeholder text or equivalent) because it'll be wrong for at least some of your users.


Thanks everyone for the great answers. Our app is desktop only at this point and our users are used to doing data entry behavior. Therefore the best solution for our users was a single text field with a mm-dd-yyyy mask, no datepicker.

enter image description here

enter image description here

We could make it better by giving the user more grace so if they typed in months or days without the leading zeros we'd still format it properly, etc., but that can wait for a future iteration.

  • Have you considered the accessibility of the "MM-DD-YYYY" text? How does a screen reader handle it?
    – A. Sim
    Commented Dec 10, 2015 at 0:07
  • The aria-label. Commented Dec 10, 2015 at 5:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.