4 ms·
> that one fact alone makes this trash. Like - hot garbage "screws up your conversion rates" trash. That's a pretty hostile and condescending way to talk about
by root_axis 8y ago
> that one fact alone makes this trash. Like - hot garbage "screws up your conversion rates" trash.
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.
- folkhack 8y ago> Your statement is also incorrect if applied as a general rule. 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...
- fnordsensei 8y ago> It is a generally accepted "case" that additional validation barriers on conversion experiences cause users to drop off. 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?
- folkhack 8y ago> 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.
- root_axis 8y ago> additional validation barriers on conversion experiences cause users to drop off 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".
- detaro 8y agoIt's not just a mask. 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. ...
- g105b 8y ago> That's a pretty hostile and condescending way to talk about someone else's work. 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.
- hamiltonkibbe 8y agoI can’t imagine ever being in a situation where I’ve already entered enough digits of my credit card number into a form to trigger some sort of formatting and then decided that I no longer want to continue the transaction because no formatting happened, e.g. because it’s just a plain old input. Is this a real thing?
- folkhack 8y agoIt COULD be a "real thing" but 100% don't believe it until someone links a study backing up a claim like that. 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.
- leeoniya 8y ago> there's no good way to "auto-format" it even if you knew the issuing PCN of the card before hand. 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.
- root_axis 8y agoWe speculated that it was the result of less frustration when entering the card number. Perhaps the visual parity between the distribution of the numbers on the card and the form causes customers to make fewer erroneous entries. I'd be lying if I said I knew the exact reason but that is what we observed. 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.
- anoncake 8y agoWhen someone creates trash, calling their work trash is perfectly appropriate.