Pick your winner
| 2:34 pm on Jun 10, 2003 (gmt 0)|
| 2:58 pm on Jun 10, 2003 (gmt 0)|
While server side validation is necessary some of the time, it's my belief that client side validation of some form is needed all of the time.
| 3:00 pm on Jun 10, 2003 (gmt 0)|
Is there anything you can do to improve your form? Should you be providing clearer instructions?
So given that it is only rarely brought into play, there is your argument for taking it off the client and doing all validation server side, since you have to anyway (cannot trust anything from the client) and saving yourself perhaps several megabytes of bandwidth a day on a busy site.
Sure, there will be occasional round trips which may inconvenience the odd modem user, but probably not that much, and certainly not more than one round trip otherwise you really do need to reconsider your layout!
| 3:09 pm on Jun 10, 2003 (gmt 0)|
|saving yourself perhaps several megabytes of bandwidth a day on a busy site. |
I didn't want to jump into this discussion, but I will.
I totally disagree with the argument above with respect to form validation and design flaws. Take an email address. You can't be clearer about "email address". If a person leaves out the @ or the . then there is nothing short of a 2 x 4 against the head that will remind the person to use it.
It is better to catch simple mistakes on the client, and have only one trip to the server when the form is ready.
Server side validation is then used to check the validity of the data - is this a duplicate ID? Is the person eligible to go further?
All the basics should be handled client side to save bandwidth.
| 3:19 pm on Jun 10, 2003 (gmt 0)|
|You can't be clearer about "email address". If a person leaves out the @ or the . then there is nothing short of a 2 x 4 against the head that will remind the person to use it. |
But that doesn't defend the client side case in the face of my argument. I'm saying people won't get their email address wrong often enough for you to justify the overhead.
I just thought of an analogy to help support my case.
Consider the police. They patrol the streets normally in pairs in a single car. Most incidents they come across don't require the back-up of a prison van in which to take prisoners, so they don't have one. On the rare occasions that they need one, they'll call one in.
| 3:31 pm on Jun 10, 2003 (gmt 0)|
[edited by: ShawnR at 3:34 pm (utc) on June 10, 2003]
| 3:32 pm on Jun 10, 2003 (gmt 0)|
I would aurgue that it is the second officer in the car.
It really is not a design issue either. There are bad and good forms. You can only try and make your site useable for the majority of your audience. If your audience is very focused then you might have a very low error rate, but instances like these are few and far between. Most general sites cannot get a small error rate no matter how good the design. The higher the trafffic rate the more this error group rises in numbers and needs to be dealt with.
| 3:35 pm on Jun 10, 2003 (gmt 0)|
|I'm saying people won't get their email address wrong often enough for you to justify the overhead. |
I wish that would be true. Always remember that internet users are not all as savvy as you (and all of us here I guess). Some just don't know that they have to put the ENTIRE address, including the '@whatever.foo'. And even if you write that just under the text box, they won't read it.
Then there are the typos. People don't really check what they're writing on the web, so more typos happen.
And then there are always people who will try to send a form without completing all the mandatory fields, or just write some random characters. I know even with a JS check they can give a bogus address, but still it helps.
In short, there are lots more mistakes detected through JS than you might think. I have no stats to 'prove' that, but I get enough calls from friends and family asking why they can't send in a form and just overlooking something which seems obvious to me.
| 3:36 pm on Jun 10, 2003 (gmt 0)|
Let's consider it from the users point of view. He/she is entering some information into a form and mistypes something - let's say for arguements sake that they hit the 5 key instead of the "r" in their surname.
Using client-side validation this error is picked up immediately, they are given an error message telling them that there is an error with their surname - they check and see the error, fix it and submit the form. Fast, useable and intuitive.
Consider then the server side case. Using the same example, the user submits the form, waits for the reply page which tells them that there is an error with their name (hopefully repopulating the data they submitted!), they correct the error and resubmit. In this case, the time taken to correct the error and re-submit the form is hitting close on twice that taken for the error to be caught and the form resubmitted using client side validation.
| 3:41 pm on Jun 10, 2003 (gmt 0)|
In Web Programming there is module called "client-side-scripting" which offers this and that functionality. It depends on my expectations of the availability of client-side-scripting on the client ("are they using a webbrowser like IE, Mozilla or Opera?"):
- If I expect it is there, I can use 100% functiality (and take bandwidth balances into account to decide client<->server-side)
- If I must expect, it is NOT there, I don't use it.
- If I'm somewhere in between, i don't RELY on it. (In case of the ongoing email-verification topic here, I would need both solutions server+client for the plausibility!) [I personally don't validate email-addresses. The client might not have it available, wants to stay anonymous or is drunk, but he still has something to say/send.]