When client and server side validations occur, doesn't it make for a better UX to only do server validations?

Question

I find a problem on the MVC4 project I am working on now, using Fluent Validation, in that some validations are delegated to the jQuery client side validation, while some, such as the NotNull rule for dropdowns, and some conditional validations based on field values, must be done on the server.

This results in the user leaving some dropdowns, and some textboxes blank, or selecting a certain value in a dropdown. They then press Submit and get messages for the client side validations, which they correct. They then click submit again, and again get other messages for the server side validations, which they must the correct and click submit again.

I have about 5% of my pages where server side validation isn't required, so I figure turning client side off will make for a much better UX. They user will get all their validation messages at once, can attempt all corrections at once, resubmit.

Answer 1

I use the rule server-side validation for security and client side validation for usability.

I can't trust any client, but I can write a standard client which quickly (without the network) validates inputs, so the user can get a response sometimes even while typing.

This also minimizes the wrong requests my client sends to my server.

-- EDIT --

What I want to say is:

You can do the validation without spending any time to client side validation and get decent results.

Pro:

• Just implementing one validation.
• No 2 level error messages, just one from the server.

Contra:

• For every faulty input you get one faulty request to your server, even just the client you implemented is used.
• The users have to wait for a server response to know what's wrong.

What you need is probably implementing two validators, which take the same configuration, so you don't have to write the configuration for client and server. Which would eliminate the problem with the 2 level-errors and get you the benefits of client side validation.

Answer 2

This is annoying. Your user fills out the form, submits, and gets back "3 mistakes". He corrects those 3 mistakes, submits, and gets back "2 new mistakes" in fields he hasn't changed meanwhile. His reaction:

"Why did you not tell me about those 2 mistakes in the first place"?

And he's right.

Clientside validation was meant to help the user by providing faster feedback. Waiting for the user to click "submit" makes you lose most of that edge: you only save the round-trip time to the server, which these days often is minimal. Especially when it comes with the cost of two submits, your clientside validation is not helping the user, but annoying him.

Two fixes:

1/ Have the clientside solution be immediate: as soon as a user enters a wrong email address (field goes out of focus), give a clue (show a box, color the field red) that the email address has the wrong format and will not be accepted by the server anyway.

2/ If the clientside solution cannot be immediate, disable it altogether. Have one serverside validation that catches ALL the errors, and shows them ALL at one (not stop at the first error, have the user fix that, repeat for every error).

In a perfect world, clientside verification catches every possible mistake a user can make, but we often know this is not possible. Users got used to this too: noone will get mad if the clientside validation only catches a subset of the mistakes the serverside validation catches.

This is why I often only code the 80% most common errors in the clientside, and leave the edge cases for the serverside. If a most common error can only be checked at serverside (eg "username already taken"), a small AJAX request can do wonders: while the user continues filling out the form, he'll notice his username was already taken and can change it to something else.

Answer 3

I'm a huge fan of on-the-fly server validations.

When you're not dealing with huge amounts of data (large file uploads, etc), it's not too difficult to automatically AJAX-submit parts of a form to the server for validation. This is commonly seen in sign-up forms where users need to pick a unique username in addition to entering their email, password, etc.

---

Using the client + server validation model

1. Enters a username "I-Love-Kittenz"
   • Client side error "You can't have special characters"
2. Changes username to "ILoveKittenz"
   • Client side gives no error
3. User submits form
   • Server side error "That username is already taken!"
4. User is frustrated and tries another username

---

Using the on-the-fly server validation model

1. Enters a username "I-Love-Kittenz"
   • Client polls server and gets error "You can't have special characters"
2. Changes username to "ILoveKittenz"
   • Client polls server and gets error "That username is already taken!"
3. Changes username to "ILoveK1ttenz"
   • Client polls server and gets OK
4. User submits and is happy!

Answer 4

Client side validation is usually desirable because it is fast. The validation gets done before the form is submitted. The user doesn't have to wait several seconds before the server responds.

Server side validation is usually required because users without javascript or malicious users could submit bad data without it.

Best practice is usually to have both do the same validation so that it is fast for users, but the server is protected from bad data.

Answer 5

The user need not know how or where something was validated.

Perform both validations and show both validations' erros in the same dialog. Doing so will remove the disappointing experience of having validated, corrected, and the validated and corrected again. The user right away knows what is wrong and knows to fix all the problems after the first error prompt.

Answer 6

You can do without client-side validation, but you cannot do without server-side validation.

No ifs, no buts.

If you want your site to get hacked, rely on client-side validation.

The client-side validation should be used to minimise the amount of errors that server-side validation will detect. It shouldn't be used instead of server-side validation.

However, if you rely on server-side validation, you can end up with a real mess, if the form is remotely complicated. So use both if you want the best result, or use server side only if you want ease of programming and a single point for your business rules. But never use client side only. Ever.

Answer 7

You should validate on BOTH client side and server side, see above answer for the reasons why. Your user will get a faster/responsive experience and your server will thank you for stopping invalid attempts before they are submitted.

I think you are having another problem: improper use or lack of knowledge of MVC 4 methods for validation:

1. Yes, you can and should validate not null rule for dropdowns on the client side. See Required attribute.
2. Yes, you can and should validate conditional rules on the client side. See Remote attribute and other custom attributes.

Answer 8

Your problem isn't that you have both client and server-side validation. Your problem is that your client-side is validating things the server doesn't. That's completely pointless.

Client-side validation should never validate more than the server does. It's entire purpose is to not waste user-time/server-resources to discover something that can already be determined on the user's computer, which is that it will fail. The server very frequently validates things the client never should, by using business logic you wouldn't want exposed to the user.

So yes, any time you have something on the client setting stricter rules than the server, turn that off. If you're using a one-size fits all solution on the client-side, you might want to consider a solution that you can custom tailor to each scenario.

Answer 9

If you turn off client-side validation on all your pages as you suggest, will you really get all your validation messages at once? I find that in practice, most non-trivial forms require two-stage validation regardless of client vs. server side validation technique:

1. Input validation - e.g. required fields
2. Business rule validation - e.g. combination of selections are valid in the larger business context.

That being said, I gave up on client-side validation years ago. I found that the cons consistently outweighed the pros.

Cons:

• Duplicate programming effort (validation must be done on server as well), or reliance on libraries like FluentValidation to work the way you need them to.
• Duplicate testing effort
• Inconsistent user experience. i.e. client-side validation is usually nearly instant, almost jerky. While service-side validation has a delay.
• ...

Pros:

• Faster for the user
• Less load on the server

However, if you do go 100% server-side, you'll want to move from full page POSTs to Ajax POSTs, if you haven't already. That will make your request / response time much faster (in the event of validation failure, you only return e.g. a list of validation results, rather than needing to rebuild the whole page). Easier said than done, there aren't a lot of ready-to-go libraries / frameworks out there supporting this paradigm, but well worth the effort on many counts including validation we discuss here.

Answer 10

You say "They then click submit again, and again" which sounds more like a test case than a real situation.
In my experience, the users don't submit forms with that many errors, albeit this is not impossible.
Depending on your application, most users might walk through it without seeing any error messages, so any concern about the origin of the messages is void.
It's also void if the user sees a single message.
If my users were seeing several messages while trying to perforn a task, then I'd check my UI to find out why.