We have to anticipate how the user is going to think or react and everyone is different. Well designed systems can get us close to intuitive. .Even a perfect UI would be less than ideal. The ideal is to have no middleman at all. No translation layer. Historically speaking, this hasn’t been possible because we can’t "speak" to computers.
The breadth and depth of knowledge to absorb in the web performance space is ridiculous. At a minimum, I'm discovering something new nearly every week. Case in point: The
Save-Data header, which I discovered via a Google Developers article by Ilya Grigorik.
If you're looking for the tl;dr version of how
Save-Data works, let me oblige you: If you opt into data savings on the Android version of Chrome (or the Data Saver extension on your desktop device), every request that Chrome sends to a server will contain a
Save-Data header with a value of
On. You can then act on this header to change your site's content delivery in such a way that conserves data for the user. This is a very open-ended sort of opportunity that you're being given, so let's explore a few ways that you could act on the
Save-Data header to send less bytes down the wire!
So what's up with third-party form validation libraries? Why would you use a library for something you can get for free?
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.
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.
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
While incredibly easy and super lightweight, this approach does have a few shortcomings.
- You can style fields that have errors on them with the
:invalidpseudo-selector, but you can't style the error messages themselves.
- 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.
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.
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.