Has anyone had any experience where adding or removing client-side validation has affected conversion?
Other comments talked about client-side validation being mainly for UX and user convenience. But I'm wondering if it has a noticeable effect on whether or not people actually submit the form all the way to completion (i.e. no errors).
I made a tool that I have server-side form validation. I found that saving the invalid input so that I could examine it later was extremely valuable in understanding what people were entering, so that I could make the tool smarter. A good example is like with Parsley's demo where it requires http:// for the website URL. After seeing that people tried to enter URLs without http://, I knew I could change my code to automatically infer it. http:// is obvious, but a lot of times, people will surprise you. I don't have stats, but presumably this kind of change increases conversion. I realize this anecdote is a different effect than what I'm asking about client-side validation.
At a past company, we for a period had an (extremely invasive) script hooked up to a form that would log events on every change on the form, keypress by keypress. We could pretty much watch people type by tailing our log for a while... It probably wasn't a very nice thing to do in terms of privacy (I've more than once accidentally pasted stuff into a form that I wouldn't like to submit...), but for the day we did it, it taught us a lot of things about user behaviour we never thought about before (and we made sure to wipe all the data).
E.g. users at the time anyway, had massive problems with dropdown lists (a substantial number of errors were down to users who had clearly started typing, and got what the dropdown moved to as a result of them typing out the correct value). We ended up avoiding them (expiry dates in our billing form, for example).
(This was more than ten years ago, though, so our specific finding might very well be invalid now, with people more used to websites)
I'm not sure how this type of validation would play out. On one hand, if done well, it gives people immediate feedback. On the other hand it gives you no hints about what causes common mistakes like that. I like the idea of logging the values on error...
I don't have hard stats on conversions; but I know that when I added some JS to turn form fields a nice green colour when validated filling out the form felt much more satisfying.
You can do the same thing with Google Analytics events. Use a non-interactive event with "form validation" as category, field name as action and entered value as label. You may miss some events based on the service limits, but the common trends will be obvious.
This is a clean way to solve the low hanging fruit of form validation, stuff like isItAnEmailAddress().
What I always find messy in web frameworks is doing validations which are more complicated.
For example a radio button choice which hides another form element which would otherwise be mandatory but should now not be filled in at all. Or where supplying a value between certain dates changes another date field from optional to mandatory and also must check that these dates are between certain values dictated by the first date field.
For one of my new projects, that is precisely what I am doing - making it possible to define complicated validation rules in a simple manner (and lots more). Would there be interest if we open-source it?
Data binding solves this generically. It allows you to build state machine trivially Stuff like angular and ember do this amazingly well though it would be nice to have a nice standalone library. (no idea if one exists)
Using a declarative DSL designed for validation rules should make it much simpler, it would minimize the amount of writing the boilerplate stuff that comes with a general purpose language and would focus solely on the actual validation rules.
It could be used in the same way as templating for javascript is used, a script element with a custom type or validation-src attribute in the form or something.
Looks cool, but the demo right at the top of the "examples" page has two things that IMHO aren't as "UX aware" as described on the landing page:
- The "website" field requires the http:// part of the address
- After typing three letters into the "message" fieldarea, an error pops up and tells me the message needs to be at least 20 characters long, while I'm still typing away
I realize this could be tweaked by the user but the demo shouldn't have such logical flaws for a script that's described as "Super #UX focused". ;)
1- Client side validation is easy to circumvent. If you use this you have to make sure it is for UI only and that the real validation happens server side.
2- Using regex for email validation is fraught with issues. Probably the most salient one is that there are a million expressions out there. People run a quick google search, grab one and move on without knowing what they just plugged into their code. This particular tool will, for example, pass "m@apple.comm" as valid.
Other than that, I am sure this is a great time saver.
Virtually every attempt at email address validation is overly strict, because the relevant RFC standards are vastly more liberal than people realise. Non-ascii characters above U+007F are valid since RFC 6530. An IP address in the domain part is valid. An @ in the name part is valid if it's escaped.
"異常.(),:;<>[]\".ຜິດປົກກະຕິ.\"அசாதரண@\\ \"অস্বাভাবিক\".არაჩ"@[IPv6:3ffe:1900:4545:3:200:f8ff:fe21:67cf] is a perfectly valid email address.
1. I agree, of course. Surely, everyone knows this right?
2. True, but you have to do something. :) What exactly is wrong with m@apple.comm? That could be valid domain at some point, right? You could filter those out but it's almost a preference sort of question. Does anyone think it would make sense to have "warning" level of validation for email addresses and let the user decide on these sort of examples? Just throwing it out there.
Just be careful when you do this. If you don't use an absolute FQDN you can trigger severe delay in getting a response from the resolver. It can take twenty or thirty seconds (or more) to get a response.
I don't see a problem with using a regex to validate email, unless you get false negatives. Rejecting anything that could be a valid e-mail address is bad and will cause frustration for someone at some point.
I don't think allowing validly formed e-mail addresses that don't have corresponding accounts (or even domains - consider a web app working in offline mode) is a bad thing, especially when taken with point 1, as surely the point of client side validation is a heads up to the user that the data is wrong, rather than actual validation?
Say it's a signup form. Your validator lets a bad email through. The potential client/customer left. You can't email them to ask for correct email. They are gone. They may never come back (depends of what they were there for, right?). In that case I would want to do as much as might be reasonable in order to ensure that I capture someone who might eventually translate into revenue.
In other cases it might be just fine to store absolute gibberish and deal with it later. That said, if you have an incredibly popular site and are receiving thousands upon thousands of sign-ups per day, do you really want to store junk? Someone is going to have to go clean it up before it is of any use.
Anyhow, my main point, perhaps, is that one should understand what these magic regex email validators are and are not. That's all.
The reason I bring this up whenever relevant is because I have been bitten by this problem in the past. I only understood the problem when an existing customer informed me that they could not sign-up to receive info on a new product because my email validator was kicking them out. He just picked-up the phone and called me. I never did learn how many people I lost because of that damn regex I grabbed from an authoritative source on the 'net.
I think you are missing an important point. This isn't about email addresses that don't exist. You can't fix that. This is mostly about malformed or "illegal" addresses.
Scenario:
I somehow find myself at your landing page.
You have a single field for may email and a "Sign me up!" button.
I enter my email and sign up.
Your regex lies to you by thinking that the email is fine. In reality I made a mistake when I typed it in. I didn't notice it. Neither did your regex.
How are you going to contact me?
OK, if it is a small shop you can probably afford to have a human being review bounced emails and try to make some sense out of them. Well, what if you are signing up a thousand people a day?
Anyhow, the point is that a bad email addresses can cost you money both in customers that might never come back and also potentially in the manual work required to try to fix them manually.
Why use <input type="text" data-type="email"> rather than... <input type="email"> ? You're already using HTML5 data attributes, so why not use HTML5 input types? Added benefit is that the browser also has an idea of what kind of data goes there - this helps on mobile devices especially, where email fields won't auto-capitalize and might include extra buttons like the ".com" button and "@" right on the normal keyboard.
Client side and server side validations need (should!) not be the same — i'd make serverside validation stricter. Client side is for eliminating honest mistakes not preflighting exploits.
The web is brimming with examples, here are a few:
1) You can only do a mod 10 check (aka the Luhn algorithm) for client-side credit card validation. Beyond that, you'll need to hit a server to run a CC authorization.
2) In the email check one commenter criticized re: correctly parsing "m@apple.comm", there are practical limits. Syntactically, that's a correct email address. To that you could add content checks such as validating against known TLDs. Then you've got to ensure that your whitelist is correct and that it remains up-to-date as the TLD namespace changes. As for evaluating the registered domain name client-side, ehhhh.. maybe not. At some point you've just got to go do the DNS lookup and send an email to find out if it's going to work.
In general there are classes of problems for which some lightweight validation is practical on the client, but full validation requires extended information or transactions that are im{practical,possible} on the client.
About the only way to validate an email address (short of sending it an email) is to parse the email address using BNF from RFC-2822 (I use LPeg to do that) and if that passes, then do a DNS MX lookup on the domain; if that fails, then do a DNS A lookup on the domain. That will at least tell you that an email can be delivered, not that it will be delivered and short of sending email, that's about the best you can do.
At the risk of spamming (since it's my own blog), anyone still wondering about that question should read this or similar tuts - explaining that question and all the basic mistakes people make in validation & security
Great question. I would usually prefer server side validation, and with the nice integration that Rails provides between form errors and validations on the model, I am not sure how I can use this. Does anybody who uses a Rails stack combine both server side and client side validations?
I thought it was standard to have both. Server side validation to keep bad data out and client side validation to provide a nicer UX for the user than a complete page reload and them searching around for what went wrong.
Yeah, for some reason people always bring up server side validation on these kinds of posts about client side validation ... doesn't server side validation go without saying?
You'd think it goes without saying, but I've seen enough code where people didn't. Including code where the client side JS validation was pretty much a guide to hacking the site (trying in vain to protect against SQL injection attacks in one of the most horrific examples, where the SQL injection checks essentially told you exactly what to try to post directly to their server...)
From a Django background which also provides form errors very easily, it seems at first glance that this would not be needed (and it technically isn't). However, it's often nice to the user to let them know of silly mistakes like passwords not matching or invalid emails before they hit submit and get bombarded with everything at once.
Javascript validation provides convenience, not security.
Adding client side validations offloads some work from your servers. It could reduce the number of total requests that hit your server and overall increase your speed.
This may be premature optimization for a lot of cases but for form heavy apps this could be a useful optimization.
Also saving a round trip to the server can make the UX seem snappier and overall give a better user experience.
I usually use both for anything public facing. Server side is for security, client side is for UX. keeping it dry is a problem, obviously, but you don't always want the same validations server- and client-side.
Parsley's aim is to have think about validation just once back end and seamlessly do the same front end with no extra work. But yes that do not exempt you to validate backend ;)
I didn't write this, but I would say yes. You would have to check twice just incase someone tried to POST directly to your URI bipassing your form page.
The url validation seems a bit strict, requiring "http:// at the start. No one types that these days, and I think in practice it might be a real roadblock for less computer literate users. I notice also that "ftp://" is valid, but not other protocols like, say, "afp://" or "git://".
Other than that, great job! I'm actually really looking forward to using this in my next project - form validation is usually such a pain.
Looks very similar to the unobtrusive validation used in ASP.NET MVC (which in turn relies on jQuery validation) although this does seem to add richer configuration of behaviour (such as when the validation is triggered etc.)
from here: http://bradwilson.typepad.com/blog/2010/10/mvc3-unobtrusive-...
<input class="text-box single-line" data-val="true" data-val-length="The field LastName must be a string with a maximum length of 60." data-val-length-max="60" data-val-required="The LastName field is required." id="LastName" name="LastName" type="text" value="" />
<span class="field-validation-valid" data-valmsg-for="LastName" data-valmsg-replace="true"></span>
I suppose this is more suited to when your models and schema are also defined on the client side?
Having just hit this situation (validating a form client-side), I found the best solution was to transport the form schema from the server (because I use Django, I can easily whip up a ModelForm), then push that into a simple Javascript Form object which renders the schema and adds validation. Maybe there's better ways, but that's what worked for me. Curious what others have done .. :-)
Nice to have a full-blown client-side equivalent of schema definitions and validation rules, but for most of my forms, I just add it quickly and dirty. Sometimes it feels bad, but most web toolkits treat JavaScript as a second-class citizen and not an integrated part of its core (and no, throwing in a jQuery does not count).
Yii framework (PHP) supports validation through Ajax (serializes the form, sends for regular server-side validation and displays the errors on the form). A godsend if your form does not change, and impossible to work with if it is dynamic (consider batch entries with "Add line" features, etc.).
I haven't seen a seamless integration on this higher level.
This library looks great! I really like the functionality and the html requirement definitions.
I don't want to hijack, but I just want to link to the form library I wrote a couple years ago. It has a little less functionality, but it is a little lighter and has no dependencies. It is here: https://github.com/rickharrison/validate.js
Hey! I use that! Thank you for validate.js. validate.js + humanize.js works very well (but this morning I was considering using parsley.js. I'll evaluate it over the weekend I guess)
I am working on a library which takes a data definition, renders the form and then validates it before submitting it via ajax. It supports various hooks like manipulate the data before submission etc.
IMHO form rendering (in a standard way) is also a common pain point along with form validation. Anyone interested in this type of library? Any inputs will be highly appreciated.
Other comments talked about client-side validation being mainly for UX and user convenience. But I'm wondering if it has a noticeable effect on whether or not people actually submit the form all the way to completion (i.e. no errors).
I made a tool that I have server-side form validation. I found that saving the invalid input so that I could examine it later was extremely valuable in understanding what people were entering, so that I could make the tool smarter. A good example is like with Parsley's demo where it requires http:// for the website URL. After seeing that people tried to enter URLs without http://, I knew I could change my code to automatically infer it. http:// is obvious, but a lot of times, people will surprise you. I don't have stats, but presumably this kind of change increases conversion. I realize this anecdote is a different effect than what I'm asking about client-side validation.