1

There are a lot of cool client side validation options in HTML, and even more now in HTML5.

While these don't change the amount of server side validation required, they give an instantaneous feedback loop to the user for basic mistakes, basic mistakes where there is need to wait for the user to submit the form before warning them.

However, I recently received a bug about an inconstant user experience on this input field:

<input type="email"/>

The tester had tried two different invalid email addresses, resulting in this:

Caught by the browser based on the type attribute:

client side validation

Caught by my server side code:

server side validation

Here's the problem. The tester/user was surprised that the messages would be different. I can only agree, that despite the advantages, it is an inconstant user experience, which evidently has lead to user surprise (a bad thing). Have I therefore made a poor design choice?

My response to this bug has to respond briefly to the client with the pros and cons of browser validation and I'll implement it in the way they decide. But if I have to give advice on which is best, what should I say?

Note: I've avoided discussing writing my own JavaScript validation as I consider it old fashioned, more brittle than the html approach, and all together to much effort. But I would get more control, so perhaps I'm wrong.

  • So the problem is the content of the error message not the position or both? I'd personally be more thrown off by the position. Firefox lets you define the error message in html attribute though but no other browser does. – locationunknown Jun 8 '15 at 9:45
  • 1
    I think, in your case (since this is a login form), it's better that you remove the client validation (except the required validation) and let the server validate the inputs. – Yellen Jun 8 '15 at 10:32
  • Sadly browsers don't allow you to style the validation elements - stackoverflow.com/questions/5713405/… – Stephen Keable Jun 8 '15 at 14:54
  • As @StephenKeable noted you can't style the built in validation messages in browsers and they are wildly different in rendering across browsers/devices... As a result for consistency alone, I'm avoiding using them. – scunliffe Jun 10 '15 at 3:35
  • You could also use a regex validator in this example and keep everything client side. – Marcie Kaiser Jun 12 '15 at 20:48
1

Use both methods, just make them look the same. It's not the difference in client-side vs server-side the tester/user notices, it's the different text, position and markup. Not the method, but the endresult.

So just style your server-side message like the client-side one; text bubble floating over the field with a red outline.

  • You are aware that there is more than one kind of browser? – Nathan Cooper Oct 11 '15 at 11:08
  • I am, but I'm also aware that you can sort of customize how the browser messages look. Or even replacing them completely with JavaScript: developer.telerik.com/featured/…. And I'm aware that all of the (common) browsers use a floating text bubble, inline, whereas your server-side example adds a footer to the form - that's a more significant difference than having a black or red outline. It may not be perfect, but it's a lot better than you have now. – PixelSnader Oct 11 '15 at 12:10
  • ++ I'm not entirely sure I agree (I don't know what I think anymore), but it is an interesting suggestion. – Nathan Cooper Oct 11 '15 at 20:50
0

If you made the e-mail input box have type="text", the browser won't validate it and only the server will.

0

I think this question is more a code than an UX one, but you could easily do this:

var email = document.getElementById("mail");

email.addEventListener("keyup", function (event) {
  if(email.validity.typeMismatch) {
    email.setCustomValidity("Please enter a valid email");
  } else {
    email.setCustomValidity("");
  }
});

Additionally, you could check the Constrain Validation API that will help you to customize validation messages and states as needed

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.