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.

I have an application that converts the following invalid dates, with only two-character years into a valid date format automatically while the user's filling out the form:

(NOTE: The application is only in-use by UK organisations, so the dates are all UK format only)

01/01/01 to 01/01/2001
14/05/58 to 14/05/1958
21/11/25 to 21/11/2025

It works out which century to use based on a semi-arbitrary threshold on 2050, so if a user inputs 49, they'll get 2049, but if they enter 50 they'll get 1950.

The conversion happens when the user tabs off the field and is visible immediately.

I recently received a complaint from one user who said they entered 10 and got 2010, but entered 27 and got 2027, not the 1927 they were hoping for. Their reasoning was that the 2027 was in the future, and should therefore convert to 1927 instead (because the future date was impossible).

I think in the long run, I'd love to just get rid of this functionality - I have no idea what's going to happen when we hit 2050... But in the short term, is there a way to alter the existing, basic, algorithm to make it more intuitive or user-friendly?


Background (not related to question)

For those interested, the user can also pick the date from a list of dates, or enter a date in a few other formats with various dashes and slashes and the system will make similar adjustments. If the system is unable to make an adjustment to the valid date format, it alerts the user via a visual cue and validation on the page fails.

The uses of the terms "valid" and "invalid" here are purely in relation to the application and have no bearing on any particular national or international date format.

Similar to this question: Date picker subtleties: Input year by using numeric keys

share|improve this question
    
    
It sounds like a good idea, but really, users will not know how the logic works for the different scenarios. I'd suggest making it clear a 4 digit date is required. In the end, this sounds slower, but if they have to think about how the date will be interpreted, or end up with an incorrect date, they will have less overall success. You could make the autocorrect and then a link next to it to switch to the other option to correct it easily. –  Mark Sloan Mar 7 at 19:08

4 Answers 4

up vote 14 down vote accepted

What is the context of your application? Context really matters for dates. Consider the two following situations.

  1. A budgeting application where users plan spending for future years
  2. A college reunion signup where users enter their graduation date

Clearly if people are planning, they would be annoyed to get a date in the past and if people are entering dates that have happened they would be annoyed to get a date in the future.

I would suggest looking at the years that your users enter in aggregate and see if you can find patterns. Your users may expect to enter dates up to ten years in the future, but also dates way into the past. In such a case, you might want to change the cutoff from "50" to "10 plus the current year". But again, it all depends on the behavior of your users in your particular context.

share|improve this answer
1  
+1: Good point about the future/past date question. It's a database of people and tasks (among other things), so some dates will always be in the past (i.e. birthdays) and some will generally be in the future (i.e. task due date). I expect I could alter the function to include an Expected Date Direction parameter, or something, with the following options: Mostly Future and Mostly Past, then adjust the guessing feature accordingly :) –  LordScree Feb 25 '13 at 17:32
    
I liked how you thought of two different situations. Very nice answer in general to problems similar to this! –  Samuel M Feb 25 '13 at 17:49
    
+1 the answer I would have given (and did without fully reading your answer--voted to delete!) –  Charles Wesley Feb 25 '13 at 18:05

As Stephen already said: the purpose of the entered date matters a lot.

I recently developed a date entry widget that also does this (and more). It allows entering the dates in basically any format. When it recognizes the entered data as a date, it shows a passive popup under the widget with the possible matching dates for the entered text. The ordering and availability of the matches depends on users locale and the valid date limits set on the widget. So, for entering a birth date, valid dates are only dates in the past up to and including today, while for making appointments, valid dates would be dates in the future, starting from today.

That works quite well. When users enter a two digit year, they are presented with the interpreted date before even before they leave the widget, and they are able to select another than the primary date from the list of suggestions if needed. It is even possible to not enter a year at all, and still get valid suggestions. That is useful for things like appointments (close future is assumed as the most likely suggestion) or for contexts like police reports (close past is assumed for the year for the most likely suggestion).

share|improve this answer
    
+1: I love the idea of showing both options to the user and allowing them to pick the one they want. –  LordScree Feb 26 '13 at 17:17

Firstly, don't use two character years. We finished with the Y2K horrors, so please let's learn from them.

Then, assuming there is some critical reason to use two character years: If your users aren't entering future dates, or if those future dates are bound to something near the current date (say a few years in the future), then you should not use the method that you are using now.

You should vary the threshold in your date conversion application to some variant of the current date.

E.g. threshold = current_year + 5

share|improve this answer
4  
It seems to me that he's not using two-character years, as he has explicitly stated that they are "invalid dates". He's helping users who refuse to enter 4-digit dates by immediately (onblur) prepending the century on the client before persisting them as 4-digit dates. –  msanford Feb 25 '13 at 17:07
1  
Thanks @msanford, that's exactly what I was just thinking :) –  LordScree Feb 25 '13 at 17:29
1  
@msanford You shouldn't accept 2 character years. It's safer to let the user know that they need 4 character years than try and guess the year. –  JohnGB Feb 25 '13 at 18:00
    
@JohnGB But that's precisely it: it's not accepting them. You would prefer a design in which a field is flagged as invalid upon submit/blur, an error message pushed and submission interrupted? That design is from a time when we couldn't do anything better. I find the proposed solution far more elegant & probably rarely causes data consistency problems: the user sees the correction immediately. Yes, add a big message cautioning users to enter 4-digit dates when they use 2. I agree that guessing has a flaw, but that is the question the OP asked (i.e., how do I make guessing less stupid). –  msanford Feb 26 '13 at 3:37

Yes it's possible. By using a well designed GUI date picker. GUI always solves problems like this.

share|improve this answer

Your Answer

 
discard

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

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