ux

Why Use a Third-Party Form Validation Library?

We've just wrapped up a great series of posts from Chris Ferdinandi on modern form validation. It starts here. These days, browsers have quite a few built-in tools for handling form validation including HTML attributes that can do quite a bit on their own, and a JavaScript API that can do even more. Chris even showed us that with a litttttle bit more work we can get down to IE 9 support with ideal UX.

So what's up with third-party form validation libraries? Why would you use a library for something you can get for free?

(more…)

Form Validation – Part 4: Validating the MailChimp Subscribe Form

Over the last few articles in this series, we've learned how to use a handful of input types and validation attributes to natively validate forms.

We've learned how to use the Constraint Validation API to enhance the native browser validation process for a better overall user experience. And we wrote a polyfill to extend support all the way back to IE9 (and plug a few feature holes in some newer versions).

Now, let's take what we've learned and apply it to a real example: the MailChimp signup form.

(more…)

Form Validation Part 3: A Validity State API Polyfill

In the last article in this series, we built a lightweight script (6kb, 2.7kb minified) using the Validity State API to enhance the native form validation experience. It works in all modern browsers and provides support IE support back to IE10. But, there are some browser gotchas.

Not every browser supports every Validity State property. Internet Explorer is the main violator, though Edge does lack support for tooLong even though IE10+ support it. And Chrome, Firefox, and Safari got full support only recently.

Today, we'll write a lightweight polyfill that extends our browser support all the way back to IE9, and adds missing properties to partially supporting browsers, without modifying any of the core code in our script.

(more…)

Form Validation Part 2: The Constraint Validation API (JavaScript)

In my last article, I showed you how to use native browser form validation through a combination of semantic input types (for example, <input type="email"/>) and validation attributes (such as required and pattern).

While incredibly easy and super lightweight, this approach does have a few shortcomings.

  1. You can style fields that have errors on them with the :invalid pseudo-selector, but you can't style the error messages themselves.
  2. Behavior is also inconsistent across browsers.

User studies from Christian Holst and Luke Wroblewski (separately) found that displaying an error when the user leaves a field, and keeping that error persistent until the issue is fixed, provided the best and fastest user experience.

Unfortunately, none of the browsers natively behave this way. However, there is a way to get this behavior without depending on a large JavaScript form validation library.

(more…)

Form Validation Part 1: Constraint Validation in HTML

Most JavaScript form validation libraries are large, and often require other libraries like jQuery. For example, MailChimp's embeddable form includes a 140kb validation file (minified). It includes the entire jQuery library, a third-party form validation plugin, and some custom MailChimp code. In fact, that setup is what inspired this new series about modern form validation. What new tools do we have these days for form validation? What is possible? What is still needed?

In this series, I'm going to show you two lightweight ways to validate forms on the front end. Both take advantage of newer web APIs. I'm also going to teach you how to push browser support for these APIs back to IE9 (which provides you with coverage for 99.6% of all web traffic worldwide).

Finally, we'll take a look at MailChimp's sign-up form, and provide the same experience with 28× less code.

(more…)

Radios and Checkboxes on GOV.UK

An interesting journey of form UX, documented by Tim Paul. It started with browser defaults. It's unclear why that wasn't working. But interestingly, an alteration that included giant label-based click areas in color-offset boxes didn't help. What actually helped was bigger (and custom) radios and checkboxes.

So far they’ve tested really well. In research, people of all confidence levels are clicking these controls quickly and easily.

I used to think the size of SurveyMonkey radios was awkwardly large. Now I think it's probably a smart move.

icon-anchoricon-closeicon-emailicon-linkicon-logo-staricon-menuicon-nav-guideicon-searchicon-staricon-tag