Form Widgets

Published 31 July 06 by Justin French, 20 comments

I think we can safely skip text fields and text areas, and get down to something a little more interesting.

Boolean Data

In my mind, Boolean data (true or false, yes or no, on or off) is best handled with a checkbox, yet it’s quite common to see two radio buttons or a select widget with two options instead.

Checkboxes represent the smallest number of elements on the page the user needs to absorb or interpret—the current state of the checkbox (checked or unchecked), and the text associated with that checkbox. Changing the state of the checkbox requires minimal use of the mouse or keyboard and can be done with one click in one place. As an added bonus, the text is usually positioned right next to the checkbox itself, providing a close visual association.

Radio buttons on the other hand require the user to absorb perhaps five elements on the page — the text associated with the radio button group, the state of the two radio buttons, and the two text labels associated with the radio buttons. Changing the state of the radio button group requires a bit more movement of the mouse or a few more keystrokes to achieve the same result. The final blow for radio buttons is that they’ll take up 2–3 lines of vertical space on the form, and the checkbox will only need one.

I don’t really see select boxes as a contender at all — they require far too much mouse or keyboard interaction to make a selection and you can’t see the possible values until you activate the widget.

So, if the checkbox is such a clear winner, why do some designers and developers stray from the path? I think it all depends on how you label the Boolean field. If the text label can be written as a true/false statement (like “I agree to the terms and conditions” or “Make this article visible on the website”), then everything makes more sense. “Article Status” requires the user to answer “live” or “draft”, but “This Article is visible” simply requires a “yes” or “no”.

I’d love to see some examples of a Boolean field where a checkbox doesn’t work, but in my mind, it’s a winner.

One-to-one Relationships

An article belongs to a particular section of the website, a weblog post belongs to an author, a page belongs to a book, a video belongs to a user, etc.

My knee-jerk reaction here has always been a <select> box, and in most cases I believe it’s the right choice. They take up very little vertical space, can be styled to fit in almost any amount of horizontal space, only allow one item to be selected at any time and aren’t difficult for users to understand and absorb.

The alternative is a group of radio buttons. What I really like about radio buttons is that for a small group of options (like the status of an article progressing from “draft” to “waiting for approval”, “approved” and finally “published”) the user can easily see all the options available to them. But for long lists, they’re prohibitive.

So, could we agree on an arbitrary number of options (like “5”) for which we automatically know to use one or the other, or is it really the combination of the number of options and the context in which they’re being used that dictates what we do?

One-to-many Relationships

When you look at the standard HTML form widget set (yes, I plan to look at non-standard widgets in a future article), the only real contenders for classic problems such as an article belonging to many categories, a programmer knowing many languages or a building servicing many suburbs is a group checkboxes or a combination select box.

The fact that most websites that use combo select boxes usually have to include a line or two of text explaining how to use it should be a dead give away that these things are awkward. You have to hold down particular key combinations to make multiple selections and it’s far too easy to make mistakes.

In contrast, a group of checkboxes are much easier to use, understand and interpret. They’re much for forgiving of mistakes, and since there’s no scrolling, it’s easy to absorb the current state of the entire group.

But a list of 200 checkboxes for book categories just isn’t going to work. It’ll overwhelm the user with information and take up a prohibitive amount of real estate within the interface. Despite their awkward nature, a combination select box showing the options in a scrollable widget is really the only viable standard solution for large collections.

So if we can agree that checkboxes work best for small sets of options, and combination select boxes work best for large sets, can we agree on an arbitrary number of items that helps us decide which widget to use?

I personally think combination select boxes are particularly awkward to use if there’s any less than 10 items showing (using the size attribute), so perhaps the magic number is “10”?

It’s worth pointing out that there are many many other solutions to this problem, including Flickr’s use of a regular plain text field which allows the user to both create and select new relationships by parsing a string of text for the tagging of photos, which I do think works well in this case. I’m going to explore some of these in more detail in a future article.

Dates & Times

The three popular solutions to this problem are:

• a rigid set of select boxes for the year, month, day, hour, minute and seconds (which Rails uses by default)
• a single text field that accepts/expects the the date (and time) in a particular pattern (like “7/21/2006”)
• a single text field that accepts almost any human date string (like “next tuesday 5pm”) and converts it to a “real” date and time on the server-side

Without a doubt, it’s much easier for the user to type “7/21/2006” or “next tuesday” than it is to manipulate 3–6 select widgets with the keyboard or mouse, but you have less control over the quality of the data input (does “6/7/06” mean July 6th or June 7th?), and have to do a lot more work elsewhere.

Pop-up calendars and clocks to help the user select the right date and time are quite popular, but I’m trying to focus on standard HTML widgets for the moment.

Where am I headed with this?

We each have our own particular way of building interfaces and forms. I’m working on some yet-to-be-announced-at-all open source software which could greatly benefit from the collective knowledge and opinions of my readers, but I also just enjoy watching patterns emerge and solidify.

I’d also like to analyse the plethora one-to-many relationship solutions out there in much greater detail (especially tagging), explore & propose a solution or two of my own, and maybe even try to agree on some basic guidelines.

Your comments, opinions, experiences and examples are warmly welcomed.