Most User-Friendly Form Fields for Entering Date/Time?

  • What are the different ways to have fields in an application for date, time, or both? What are the pros and cons for each?

    The most common seem to be a combination of 2–3 drop-downs, or some form calendar widget. Are there other options available? Which one is the most user-friendly?

    More of a side note than anything else: If your page is going to have an international audience, go for a display format with the month shown as a word instead of a number. Not everyone is familiar American style M/D/YYYY dates. Is "9/11/2001" the 11th Day of September or the 9th day of November? Showing "Sept 11 2001" avoids any ambiguity.

    @Bevan: aaargh! Don't use text representation in dates, _especially_ not if you have an international audience! The ninth month in Italian is "settembre", which would become "sett", not "Sept". The ISO 8601 format is YYYY-MM-DD; starting with the year makes it unambiguous (nobody uses YYYY-DD-MM).

    @Stevenvh - good point. I was thinking of an international *English Speaking* audience - I've lost track of the number of times I've had problems on sites that M/D/YYYY instead of the D/M/YYYY common here in New Zealand.

    @Bevan: I hear ya on that one. It can be quite frustrating. At the very least, you should have a key like you've written under the date field telling the user what each segment means.

    Another important factor here is the device used. Each input date mechanism is not equally effective on desktop vs. mobile devices.

    @Bevan: one additional note on that textual representation—in Australian English, we wouldn't write "Sept 11 2001". We'd write it "11 Sept 2001" (although that specific date has been internationally referred to as "September 11th" or "9/11", rules be damned). Naturally we can understand it in the form you present, but it still sounds awkward. I don't have a solution to offer, sadly.

  • I do believe a regular textbox with an indication of the expected format is often enough. Like Kevin mentioned, if you use a date picker you should absolutely provide a method for direct entry. Many people prefer to simply type the date.

    But this is what I do on

    alt text

    Of course I have client and server side validation in place as well. The only other feature I added is that if they enter 12121999 or 12-12-1999 then the text is automatically formatted with slashes when you lose focus to the textbox. I adopted this technique in June and it has worked quite well for us so far.

    And equally important: *Never* let your system (or programmer's laziness) impose stupid restrictions on the user, e.g., demanding `03/03/1999` when `3/3/99` (or `3/03/99`) is unambiguous too.

    @jensgram. Exactly, there's no sense in beating up the user if you can avoid it.

    @jensgram But you want to make sure you communicate the result of those assumptions to the user. Ie. the loosing of focus should perhaps post back to the server and return the formatted result that will be persisted. This way the user can know whether their variation was interpreted the way they intended.

    @cottsak Good point. I was trying to address the "assumptions" problem by only accepting *unambiguous* data, thus making no assumptions *per se*.

    @jensgram I think i get what you're saying, but to clarify- It's a great idea not to make any assumptions about how the user should express their date format. However, once the user populates the field with their format of choice, the user needs feedback as to whether the system understands their particular flavour (ie. the assumptions you the developer makes about their particular flavour of date).

    @cottsak Indeed.

    @jensgram Demanding to type the leading zeros is out, indeed, but typing them has the advantage that after two digits you can move to the next field without having to hit the `tab` key.

    It would be good to accept any reasonable delimiter (e.g. `., :/-`). Users may type their native format out of habit or paste it from elsewhere. If good part of the audience is international, please avoid the `MM/DD/YYYY` abomination, better to use unambiguous ISO `YYYY-MM-DD`. After the user moves away from the field, parse the date and show it in the proper format (with leading zeros etc.)

    I personally prefer fixed-format text fields (dunno if that's the official name for them) where the delimiters are locked in place, and the user can just type the digits only, or hit the right arrow if they don't want to type a leading zero.

    How can you automatically format 12121999 into 12-12-1999 on blur, if the entry is for example 1111999? It could be 1-11-1999 but also 11-1-1999. Also note that Europeans write DD/MM/YYYY while Americans us the MM/DD/YYYY format.

    @bart - You are quite right. I designed it to only autoformat when there are a total of 8 digits. Entering 1111999 would be one too few and would result in a validation error. Most people, when typing a date without any delimiters, will use 0's in front of the single digit portions of the date... 01111999.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM