Hacker News Reader

Comment by sethist | Hacker News Reader

This looks nice, but I ran into an immediate usability issue. The Card Expiry requires a leading 0 for January. It seems like bad UI to prevent a user from enter 1/13 or 1/2013 in those fields.

View on HN

We don't prevent that. If you type '1/' the library turns it into '01 / '.

Fair enough, I haven't dug into the code yet. I was basing my comment on the live demo which prevents it.

Huh? If you literally type '1/13' into the live demo it works as one would expect. '113' works too, it just assumes the month is eleven, and the year starts with 3.

I was referring to the live demo at http://stripe.github.com/jquery.payment/example/. Either way, I wouldn't consider the library interpreting 113 as 11/3 as a "working".

So what do you suggest "113" should be interpreted as?

I think he's suggesting that 113 should be interpreted as 1/13. I'm not sure how simple that logic would be to implement, though.

113 is ambiguous. Its an error

There are three ways to interpret it. It is either 11/3, 1/13, or an error. Since 11/3 isn't a valid date, I think it is safe to rule that out as an incorrect interpretation. Either of the other two interpretations seem acceptable to me.

Er, since when is 11/3 not a valid date?

Not for a credit card expiration date...

How would you type in 11/30 if it blurts out a big error the moment you type 113?

The same way the system allows you to type in 0213 without blurting out a big error the moment you type 02. Just don't validate the input while the user is still inputting it.

Secondly, remember this is for credit card expirations and not normal dates. You can probably make an assumption that 11/30 (November 2030) isn't currently valid input either. I have never seen an expiration date further than 10 years in the future. Although more research on the topic would be needed to figure out the true restrictions.

I don't know why the live demo is broken, or why they even need is since there is a live demo on the main page, but the usability for all cases strikes me as exceptional on the main page where it works as intended. I am not convinced that your cherry-picked restriction improves the usability.

If you literally type '1/13' into the live demo it interprets it as '11/3' because it does not allow a '/' character to be entered as cpeterso mentioned

The example page on github has an "Expiry formatting" field that says it expects "MM/YY", but it does not allow a '/' character to be entered:

http://stripe.github.com/jquery.payment/example/

Reply on news.ycombinator.com