4 ms·

> 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 v

> 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 ago
  It'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.

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 ago
It'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.