Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Just finished reading Caroline Jarrett and Gerry Gaffney's Forms that Work and I noticed that while the publisher used a screen shot on the front cover with that date format the authors didn't actually tackle the issue of DD/MM/YYYY in the book ... which provoked discussion about it when we reviewed the book at UX bookclub earlier this week.

Has anyone tested the use of the DD/MM/YYYY format string to communicate to users how to enter a date in a single or even triple text field? Or have you found it's easier just to provide year and month drop down lists?

What about for credit card detail forms where the input format must match the card so you have to use numerical dates in MM/YY format?

What are some alternatives that allow quick date input with text fields and also ensure the correct order?

share|improve this question
    
Who are your users? It would seem like this question depends very highly on what population you are talking about. –  Alex Feinman Mar 29 '10 at 16:48

10 Answers 10

Whether users understand the DD/MM/YYYY prompt will depend on the audience of course. For people who spend time on other sites, or using applications in general, I think it's become pretty well known in most communities.

I like to support free-form entry with the system being intelligent enough to figure out what you mean. So Google Calendar understands "tomorrow" and parses accordingly, and treats 10/3 as 10th March (although of course this is locale-dependent).

For credit card expiry, the preferred format has to be anything except the one that forces you to choose the month by name (as this forces the user to "translate" from the numeric month printed on the card to the calendar month)!

share|improve this answer
    
You're right, the smart date feature on things like Todoist, Google Calendar and RTM have set an expectation for me. I'm pretty disappointed when I come across websites that DON'T support "today" or "next tuesday" etc. –  Nathanael Boehm Mar 27 '10 at 1:32
1  
The problem I have with free-form entry for dates is along the lines of what Adrian mentions in his answer - the US typically does MM/DD/YYYY and other countries do DD/MM/YYYY - free-form entry makes it impossible to determine if 1/2/2010 is January 2nd or February 1st. –  Charles Boyung Mar 29 '10 at 13:13

This is the standard German date format. However, in German I would expect the localized string "TT/MM/JJJJ" :)

share|improve this answer
    
Not to be picky but… the standard over here is TT.MM.JJJJ – no slashes ;-) –  Sascha Brossmann Mar 30 '10 at 3:12
    
Oh, dear me, you're right :) –  Brian Mar 30 '10 at 14:02

Well - I know from experience that folk from the US often mistype "DD/MM/YYYY" since they're used to "MM/DD/YYYY". For a site that addressed UK & US audiences we found that we got a lower error rate with "YYYY/MM/DD" :-)

As for alternatives that allow quick text entry - you might want to look at the ways you can enter dates on nationalrail.co.uk, which has several options.

share|improve this answer
    
Interesting. YYYY/MM/DD is also the preferred format in Japan. –  Marcus Coghlan Mar 28 '10 at 23:53
4  
Logically, YYYY/MM/DD is the correct way of writing dates. As with standard numerics the left most number is the highest; Thousands, Hundreds, Tens, Units. I kind of wish we could all change and everyone write dates like this. But then that's just the pedant in me! –  JonW Mar 29 '10 at 13:38
    
Nice example, Adrian. The refresh National Rail site is pretty accommodating in that respect. –  Janel May 27 '10 at 10:46

To require a user to enter information in a free form text field in a format that you have defined is not good at all.

I think a date picker (calendar), multiple select boxes (with Jan, Feb, etc - showing clearly which field is for what), or a highly intelligent free text form is much better. However, I think most people would have to stop and think, not being used to a system understanding things like "tomorrow", which would make a more clear UI like the 2 first I suggested better.

share|improve this answer
1  
Although in general free form fields with an "input tip" such as mm/dd/yyyy seems to be the overall recommended way to do this. –  JeroenEijkhof Sep 28 '12 at 19:07
    
@JeroenEijkhof: because they work, especially when accompanied with date picker. –  ya23 Jan 9 '13 at 10:32

For Europeans, DD/MM/YYYY probably works fine, although I'd add an example date. So it would something look like this (not sure if the formatting comes out):

[..] [..] [....]

DD / MM / YYYY (e.g. 25 / 05 / 2010)

(As you can see, one tricky thing is whether the leading "0" for the first 9 months is required or not)

Using a date-picker only works for nearby dates (either nearby the current date, or another know date). So they work great for appointments in the coming month, but not for birthdays or other random dates.

For credit card expiry dates, I'd use two drop-downs for months (1-12) and year (current year + next 5?).

share|improve this answer
    
5 years might not be enough: uxexchange.com/questions/2098/… –  Lisa Daske Apr 1 '10 at 11:07

William Hudson investigated this issue last year. He conducted a survey of nearly 1,000 people, asking them simply how they would write a given date (‘the second of August this year’ was how it was phrased). They typed their answer into a free-format text field. Respondents were then invited to choose the closest ‘template’ date from a list of 32 – half of which were in day/month/year order and the other half month/day/year (‘other’ was the final option).

People used a wide variety of date formats. Participants who used month/day/year ordering had a slightly stronger preference for a purely numerical date with no leading zeros in the month or day (8/2/09) but the close second used the full month name (August 2 2009). These two categories accounted for 53% of that group.

share|improve this answer

Some people may not understand "dd/mm/yyyy". To be clear, use plain English (day/month/year) and include an unambiguous example like 30/4/2010. Here's an example.

      ________
Date |________| day/month/year - for example 30/5/2010
share|improve this answer

Never had a real problem with DD/MM/YYYY - for Australian or New Zealand audiences. Most people seem to get what it means.

Did come across a functional spec though where the client wanted DD/MM/CCYY.

That got a red flag and a flat out "No" from me. :)

share|improve this answer
    
Did they give a reason for wanting it that format? It seems VERY odd! –  Toby Jun 6 '10 at 20:01
    
It's does make some technical sense - CC for century (e.g. 21st), YY for the year. It's just über confusing. –  Matt Aug 31 '12 at 19:59

Just as a bit of background, there's an International Standard (ISO) for date format:

It's YYYY-MM-DD

http://www.w3.org/QA/Tips/iso-date

Its actually quite complex as to which country uses which format - and there's quite a nice Wikipedia guide (normal Wikipedia reservations applying...)

http://en.wikipedia.org/wiki/Calendar_date#List_of_the_world_locations_by_date_format_in_use

share|improve this answer
    
+1 Only format I'll ever find logical, but then again I'm from Sweden where slashes are weird ;) It also feels more logical for my thought process to figure out the year first, then the month and finally what day I'm after - so this seems entirely cultural/locale-dependant. –  Oskar Duveborn Jun 26 '10 at 18:24
    
Further exploration of the W3 site reveals this comment "No ideal solution exists for this problem. Weigh the options and choose according to your preferences and your situation. If there is likely to be any ambiguity on the part of the user, it is usually best to use explicit month names and 4-digit years for Gregorian dates, or at least indicate on the page how to read the dates. Dates can be reformatted using dynamic techniques to match the linguistic context of the page." see w3.org/International/questions/qa-date-format –  Nathan-W Jun 26 '10 at 22:40

DD/MM/YYYY means of course "Dam* You" - perhaps in the user's mind ;-)

Serious though, over the years developing applications that will receive dates - if typed manually they always become a problem, no matter what you do. There are just too many ways not just to think of dates, but also to type them. The format varies from country to country and so forth.

IMO date fields need to be child proof by offering drop downs - one for year, one for month and one for day - or a calendar to select the date from the grid.

Never ever let any user type a date manually!

share|improve this answer
1  
Strongly disagree with "Never ever let any user type a date manually". Power users would find this limitation quite annoying. Imho ideal way is to offer a user an intelligent textbox with a format (e.g. dd/mm/yyyy) and a date picker. Power users would go for a textbox, others would use date picker, everybody's happy. –  ya23 Jan 9 '13 at 10:30
1  
Your're right @ya23, I'm too generic in the last statement - though, I worded it in hope that the exaggeration came through :) It eventually boils down to: who is your audience. But working a lot with power users where main task is to enter dates for hundreds of reports daily (time report sheets), the amount of errors is noticeable - even then. There are techniques to "fix" these, but to specific for being a general solution - so, weighting audience and frequency etc. are important planning factors. –  0x2bad 0xdeadbeef Jan 9 '13 at 11:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.