Match the context, not the pattern
To my knowledge, all credit cards present their “valid from” and “expiry dates” as numerical dates, e.g. 02/06 – 02/09. So why do many transactional websites request the credit card validity in text date format, e.g. Feb 06? Most people will not know their credit card details – they arrive at the credit card details form, reach into their wallet, select the relevent card and work through the form referring to the card that they have placed near the keyboard. When they reach the date fields, additional cognitive processing is required, translating the number on the card to a month on the form. This interupts the process (do not assume that everybody can make the immediate leap from 02 to February. Spend time observing consumers on the task and it will not be long before you see fingers coming out to help with the counting).
So whilst using textual dates may be considered to be more “user friendly” and understandable, in the context of completing the credit card form, it adds complexity. UI guidelines, patterns, heuristics are all well and good, but ultimately you must consider the context of usage and design accordingly, even if it does at first glance result in something that is not immediately user friendly.
It’s also useful to provide both numerical and textual forms of the date in the month field to for maximum clarity.
For example, the month of December could read “12 – December” with the number preceding the word. When focus is set to the field, typing the month number still selects the correct choice.
I just want a text field into which I can enter MMYY. Choosing from a drop-down list (even if they are two digit months/years) is painful.
I mean, how hard is it to allow me to type 4 digits: 0309?
Well, yeah February is not such a good example I think – as that is too easy – but closer to the Sept., Oct. and Nov. you are right.
And did it have to happen that my current CC expires in October 🙂
alex.