# Date picker subtleties: Input year by using numeric keys

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.

-

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.

-
A modeless warning is a great idea. – Patrick McElhaney Feb 1 '11 at 16:29
An indication of the format is always a good idea, I believe. – agib Feb 2 '11 at 8:01
I think it is fair to assume the user meant 2020, when entering "20". Otherwise the user can just return and input a four digit year. Since inputting 20111 resets to 2001 you just input "11" to get back to 2011. A modeless feedback is an interesting option. However we haven't got such feedback elsewhere in our product, so this would not be internally consistent. – agib Feb 2 '11 at 8:09

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.

-
We are developing a date picker control to have complete control of the behaviour and appearance and to make it fit with our product. Actually we have, to the right of the date inputs, a dropdown calendar control in order to provide several means to accomplishing the same task (not shown in the mockup picture in my initial post). – agib Feb 2 '11 at 8:29

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.)

-
This is our assumption too, however not empirically supported by hard and fast figures. We have now implemented a working prototype with the features suggested in my initial post. It actually works quite well. You might have a point with the division at 30. A more flexible, "floating" approach would probably be better. – agib Feb 2 '11 at 8:17

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...
-
If the field becomes blank, an indication of the format is lost, which probably is not desirable. And the option to input just two digits to indicate year would also be gone. – agib Feb 2 '11 at 8:11
yes it is true, but most people can remember 2-3 sec and recall that he or she has to type 4 numbers – Roland Pokornyik Feb 2 '11 at 14:28
if you have an almost ready version, than test it! and try what Inca suggested – Roland Pokornyik Feb 2 '11 at 14:33

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.

-
Auto-tab is one of the most annoying things you can do to a user. – Charles Boyung Feb 1 '11 at 19:07
I do find it annoying when it's optimized (as I wrote), but certainly not if it works consistently. I stand by what I wrote. – Hisham Feb 1 '11 at 19:31
I actually recommended against optimizing. I mentioned it because that's what the OP had in mind. – Hisham Feb 1 '11 at 22:11
@Charles: Actually auto-tabbing is often quite useful and very handy for users. When copying long data from paper e.g credit card numbers and other data which is formatted into logical groupings, it is very much desired not to have to tab to the next field. The only irritating behaviour is when I make a mistake, tab back to the previous field and the auto-tab implementation sends me straight forward again because the field I tabbed into is full. But this is easily prevented. Admittedly having a single field is better, but four fields with auto-tabbing can be very usable indeed. – Marjan Venema Feb 2 '11 at 7:04
We have implemented auto-tabbing between fields, and from our own initial testing it works quite well - if the year is that last field and if we do not auto-tab away from that last field. One have to be careful, however, when it comes to cultures, because in some areas of the world the year is placed at the beginning of a date, making the auto-tab after a two digit input a suboptimal (and probably annoying) approach. – agib Feb 2 '11 at 8:24