Date picker subtleties: Input year by using numeric keys

Question

We are developing a date picker and have run into a problem related to interpretation of user input.

Suppose you have a date picker as the one in the picture below and the user is to change the year by using the numeric keys.

Obviously a year (until far future) is four digits. However, a lot of users are used to a procedure such as this using the numeric keys:

"dd" [tab] "mm" [tab] "yy" [tab/leave]

That is, inputting only 2 digits to indicate the year. My question is thus:

• What is the most reasonable behaviour to accommodate such a scenario?

Our tentative approach is this:

• 00 <= "yy" <= 29 is assumed to mean 2000 (lower bound) and 2029 (upper bound)
• 30 <= "yy" <= 99 is assumed to mean 1930 (lower bound) and 1999 (upper bound)

But what if the user enters "yyy" and leaves the input field - how is that supposed to be interpreted?

In this case our approach is not change anything until a fourth digit is entered. That is:

• "1" -> 2001
• "9" -> 2019
• "7" -> 2019
• "8" -> 1978

If a fifth digit is entered the process starts over according to the rules described in the topmost unordered list above.

Any thoughts on this will be appreciated.

Answer 1

As I see it, there are multiple potential problems with this system

• if I want to enter 1920 and use the double digit format, it will assume it's 2020 instead of 1920
• in the current form it's ambiguous what is actually saved
• if I enter by mistake 20111, it will reset the year and I'll have to start again

Maybe you could use either "XXXX" or current year to give an idea of the expected format.

This is a bit out of scope, but, you could show a friendly notice to the user if the date is outside a large enough range (something like [01/01/1900 - 01/01/2100]) for the honest mistakes. Point being not to limit what the user enters in the box - if they want to enter the correct date they will, if not, they will try to game the system to get to whatever is after the submit button.

Answer 2

A date picker should just be a text box. Make it work behind the scenes to determine the actual date object using your (or your system's) current culture's standard date formats (if you need that). If you want to have some sort of GUI element to let them pick the date via the mouse, then use progressive enhancement to do that.

I would disagree with you strongly that a lot of users are used to the "procedure" for entering the date that you mention. Most of the time, I just see a textbox with the little icon to pop up a calendar control. That actually leads to the question of why are you developing a date picker control? Why not use one of the multitudes of date picker controls already available to you?

As for the part on how to handle two digit years, I would say it's pretty safe to assume that very few people enter two digit years anymore. And if they do, I would also say that it's probably fine to just use 20XX at this point as your assumption, unless you are talking about the year the person was born. In that situation, I would enforce a four-digit year at all times.

Answer 3

As a matter of fact, I am quite sure people who are actually entering dates on a regular basis (as in many times a day in their job) are still very used to 2-digit format. I think it matters on how many times people will need to use the input. If this is once or very limited per user, you can be more restrictive. If this is aimed at professionals working the form many times a day, work with them rather than against them.

I think your solution can work very well if you provide immediate feedback about the actual year. (I could think of an indicator below or besides the input, or displaying the typed numbers in bold/black and the untyped, deduced numbers in lighter grey.)

I also suggest testing the format with the actual users, to see wether they find it confusing or clear, and wether they would like to be restricted to the point of unambiguity.

(And I would think about getting a flexible limit (say, current year + 20 ) rather than a fixed upper limit, because time flies and it will be 2030 before you know it. If you think that is too confusing, you could also include a gap that doesn't accept 2-digit. But only for those very rare cases. In general don't be too restrictive when people have to work with something a lot.)

Answer 4

I think the best solution would be:

• the field becomes blank when users start writing
• This way you can avoid misunderstandings
• and since we all write from left to write -> it will be understood by everybody that the first digit stands for the thousand, and so on...

Answer 5

The way I would expect a nice, friendly date control to work is like this:

"dd" [auto-tab] "mm" [auto-tab] "yyyy" [auto-tab/leave]

1. After I type the day, I expect the focus to move to the month automatically.

2. Same thing after I type the month.

3. Same thing after I type a 4-digit year.

Having said that, you can optimize in order to reduce the number of keystrokes that are necessary, e.g. if I type anything except a 1 in the month field, it's a fair assumption that I'm done and it's safe to have the program move the focus automatically to the year field.

However, this does place an extra cognitive load on the user. This is where you need to test, as Inca suggested. But if I had to pick, I would not optimize the data entry, especially if the app is intended for users would be entering dates a lot.

FWIW, 25 years ago I took on a data entry moonlighting job in order to pay for my immigration lawyer. It was a mind-numbing task that lasted several months; I even wrote a VAX/VMS program that did some range checking. But had I been using your program, I would definitely prefer typing a leading zero (e.g. 09) over typing 9 and having your program auto-tab for me.