- Obey the Law of Locality
- ABD: Anything But Dropdowns
- Pass the Squint Test
- Teach by example
This is about designing forms that everyone can use and complete as quickly as possible. Because nobody actually wants to use your form. They just want the outcome of having used it.
I was chatting with Rachel at work the other day about conversational forms, and I mentioned that I kicked that whole thing off with the mad libs style form on Huffduffer. Here’s the research that Luke later did on whether this style of form could increase conversion.
In some situations, a date picker is overkill:
I have relied on plain text inputs as date fields with custom validation for the site, typically using the same logic on the client and the server. For known dates — birthdays, holidays, anniversaries, etc — it has tested well.
Greg has done a lot of research into developer frustrations with customising form controls.
My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.
It’s all fun and games until you realise that everything in here was inspired by actual interfaces out there on the web.
This starts as a good bit of computer science nerdery, that kind of answers the question in the title:
Alone, CSS is not Turing complete. CSS plus HTML plus user input is Turing complete!
And so the takeaway here is bigger than just speculation about Turing completeness:
Given that CSS is a domain-specific language for styling user interface, this makes a lot of sense! CSS + HTML + Human = Turing complete.
At the end of that day, as CSS developers that is the language we really write. CSS is incomplete without HTML, and a styled interface is incomplete without a human to use it.
- Have a dedicated page for login
- Expose all required fields
- Keep all fields on one page
- Don’t get fancy
In which Matthew disects a multiple choice quiz that uses CSS to do some clever logic, using the
:checked pseudo-class and
I quite like this date-picking interface. It would be nice if browsers picked it up for
Oh, this will be good! Adam has been working on, thinking and writing about forms for quite a while and he has distilled that down into ten patterns. You just know that progressive enhancement will be at the heart of this book.
By the end of the book, you’ll have a close-to exhaustive list of ready-to-go components, delivered as a design system that you can fork, contribute to and use immediately on your projects. But more than that, you’ll have the mindset and rationale behind when or when not to use each solution, which is just as important as the solution itself.
A great collection of styled and accessible form elements:
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
A lot of the issues here are with abuses of the
placeholder attribute—using it as a label, using it for additional information, etc.—whereas using it quite literally as a placeholder can be thought of as an enhancement (I almost always preface mine with “e.g.”).
Still, there’s no getting around that terrible colour contrast issue: if the contrast were greater, it would look too much like an actual pre-filled value, and that’s potentially worse.
This ever-growing curated collection of interface patterns on CodePen is a reliable source of inspiration.
The slides from a presentation by Drew on all the functionality that browsers give us for free when it comes to validating form inputs.
If you’re looking for an accessible standalone autocomplete script, this one from GDS looks very good (similar to Lea’s awesomplete).
The answers to these questions about forms are useful for just about any website:
- Is It OK To Place A Form In Two Columns?
- Where Should Labels Be Placed?
- Can We Use Placeholder Text Instead Of A Label?
- How To Lessen The Cognitive Load Of A Form?
- Are Buttons Considered Part Of A Form’s UX?
- Is It Possible To Ease The Process Of Filling A Form?
- Does The User’s Location Influence A Form’s UX?
Ana goes into exhaustive detail on all the differences in the shadow DOM and styling of
input type="range" across browsers.
I’m totally fine with browsers providing different styling for complex UI elements like this, but I wish they’d at least provide a consistent internal structure and therefore a consistent way of over-riding the default styles. Maybe then people wouldn’t be so quick to abandon native elements like this in favour building their own UI components from scratch—the kind of over-engineering that inevitably ends up being under-engineered.