That's a pretty hostile and condescending way to talk about someone else's work. Your statement is also incorrect if applied as a general rule. I have personally administered A/B tests for this type of masking behavior on a sales funnel and observed an increase in conversation rates (specifically for credit card number masking) on our site.
Breaking up long numbers into smaller input fields CAN help with data-entry (think dyslexia etc.) but in the case of CC numbers that are of different formats (ie: VISA vs AMEX) there's no good way to "auto-format" it even if you knew the issuing PCN of the card before hand.
So - best practice generally is, ignore the dashes and let it be entered as a 10-19 digit numeric only field (or 13-19 if you're not worried about ancient cards). Just don't allow non 0-9 characters in the input via JS which is SUPER easy. Then, before submission, ensure it passes a mod-10 Luhn check to let someone know they fat-fingered it! Easy-peasy.
this is plainly wrong. you can swap the mask as soon as you know it's amex from the prefix. i know because we do it without any issues. it's 4-4-4-4 for visa/mast/disc and amex is 4-6-5. you have more than enough info by 4 digits to choose the correct mask in all cases.
edit: I want to add that this wasn't a scientific study, we did a lot of A/B tests so we felt pretty confident about it but I wouldn't claim that it's a general rule.
And before you link that "A/B Testing is Still Needed" HBR article - know that I 100% agree with it but on the premise of testing MULTIPLE solutions under the traditional "A/B testing" model. As far as you've posited in this conversation - you guys only tried one thing. You're also admitting it's not a "scientific study" so I assume you did nothing to minimize other changing variables/conditions in regards to the input masking.
TLDR: Input masking CC fields is probably a bad idea beyond filtering non-numeric/non-slash characters. I will make that generalization. I'm not convinced you've got a valid argument against that with your "A/B test" experience.
You're skeptical of people who test their business process and follow the data where it leads them rather than taking the advice of arrogant internet curmudgeons that try to puff up their opinions with flippant allusions to statistical significance and vague appeals to the authority of "board room" war stories? That doesn't speak very well for your own credibility.
> You're also admitting it's not a "scientific study" so I assume you did nothing to minimize other changing variables/conditions in regards to the input masking.
Well that assumption might make it easier for you to justify your haughty screed but it's also incorrect (you can apply that to your edits as well). Unlike you, I'm not arrogant enough to suggest that the insights I've gained in my own personal experiences are totally absolute and generalizable to every other business and circumstance.
> I'm not convinced you've got a valid argument against that with your "A/B test" experience.
That's the aspect you don't seem to be grasping; I have no reason to care about your opinion since it flies directly in the face of the data I've seen and you haven't provided any support besides your own feelings about why formatting credit numbers kills conversation rates. At best, both our experiences are anecdotal, the only difference is I'm not a dick about it.
If it was a 50% increase in signups over a set of 1000 cases, I’d be inclined to say it’s statistically significant.
Overall, seeing the UX crap produced by many data-driven companies (Google included), I have low trust in their methodology.
I would absolutely disagree with you here. It is a generally accepted "case" that additional validation barriers on conversion experiences cause users to drop off. I have seen this scientifically proven by hard numbers time and time again over my ecommerce career.
> That's a pretty hostile and condescending way to talk about someone else's work.
Sure, I'll take that criticism. I still think it's a horrible practice and would professionally advise anyone against implementing this.
I do love how we like to rip on the JS community when it's convenient for us (npm, every new framework ever, etc) but when I say a front-end lib is "hot-garbage trash" because it breaks something as simple as backspace it's over the line...
When a JavaScript framework has the job of improving user input and it actually massively downgrades it so far that USER INPUT IS IMPOSSIBLE if I press backspace / or use tab / or highlight some text / or paste ... then this feedback is justified.
Presumably the introduction of validation barriers that don't guide the input to the intended form, then. How would the ability to type an arbitrary amount of numbers, or letters, in a credit card number field lead to higher conversion?
Sure - I'll bite. But I'm also going to point out that you're swinging to the other end of the extreme. Obviously no one in their right mind would just allow arbitrary input...
Clearly every CC number can be represented by numbers alone (by omitting the slashes). People are absolutely familiar with this and often will omit the dashes in their fields all together without any filtering of characters. Personally I key off of the "keydown" event on that field and e.preventDefault/return false on anything non-numeric. In the future, I hope the "inputmode" HTML attribute catches on with non-Chromium browsers - that would eliminate my need to do this.
After the number is entered, or (personal preference) before the form is posted, you do a simple Luhn check and show a dynamic error message RIGHT ABOVE the field saying "hey invalid CC num yo" - ideally you keep the "process" button and CC num field close to each other so this happens within the same document view without having to auto-scroll/anchor to the invalidated field.
Then, as always - ensure you have the capability to validate that data using the same rules on the back-end before it's allowed to be sent to your processor, or w/e.
There ya go - there's the "everyman's" approach to CC validation on the front-end.
It's not a validation, it's simply a mask - it does not block the user, only formats what they enter into the text field.
> I do love how we like to rip on the JS community when it's convenient for us (npm, every new framework ever, etc) but when I say a front-end lib is "hot-garbage trash" because it breaks something as simple as backspace it's over the line...
Personally, I think "ripping on the JS community" is always a waste of time; jQuery still works in 2019, if you think that's the best way to go, have at it, but even in those threads I think it's pretty rare to see someone openly regard others work with such disdain as "hot garbage".
The phone number field tries a lot of clever stuff, and when I went back and inserted digits near the start of the number it wiped half the entered digits, presumably because the temporary state didn't fit its idea of a valid phone number, so it cut off everything that was "wrong"
Changing the year in the date field destroys the months and days in some cases. Editing the month left it happily in a state with a day number of 0.
Same issues with the time fields.
...