Start your free trial now, and begin learning software, business and creative skills—anytime, anywhere—with video instruction from recognized industry experts.

Start Your Free Trial Now

Input types


Web Form Design Best Practices

with Luke Wroblewski

Video: Input types

Form organization gave us a sense of how we structure the elements that make up a Web form, the labels, the input fields, the actions, where replace things and how we lay them out across pages and even within the form. Form interactions are really where people start having conversations with us and the services that we provide online. There's a lot of back and forth and a lot of interactivity that happens inside of the form. So let's look at some of the details around what makes that happen. We'll start with input types.
please wait ...
Watch the Online Video Course Web Form Design Best Practices
3h 46m Appropriate for all Oct 14, 2011

Viewers: in countries Watching now:

In this course, interaction designer Luke Wroblewski shows how to create web forms that encourage visitors to enter information and covers ways to capture input without the use of forms. The course covers boosting conversion rates and customer satisfaction, organizing the structure of forms, aligning and grouping form elements, assigning the correct input field types, validating input, and handling data entry errors. The last chapter highlights alternatives to static forms, such as using dynamic inline forms, using web services, and leveraging device capabilities, which can be used to gather additional information or replace a traditional form altogether.

Topics include:
  • Understanding why forms matter
  • Deciding on the form length and structure
  • Adding tabs to a form
  • Creating required fields
  • Adding input masks
  • Creating selection-dependent inputs and actions
  • Displaying success and error messages
  • Adding inline validation
  • Understanding gradual engagement
  • Enabling touch and audio input on devices
Luke Wroblewski

Input types

Form organization gave us a sense of how we structure the elements that make up a Web form, the labels, the input fields, the actions, where replace things and how we lay them out across pages and even within the form. Form interactions are really where people start having conversations with us and the services that we provide online. There's a lot of back and forth and a lot of interactivity that happens inside of the form. So let's look at some of the details around what makes that happen. We'll start with input types.

Input types are the bread and butter of interactivity on the Web. There are several input types that are available to us inside of Web browsers through HTML. Many of these you're probably familiar with, the checkbox, the radio button, the password field, drop-down lists, ways to pick files, submit, and plain text inputs. These guys are the real work horses of Web forms and we call on them in many different situations to help people provide the right kinds of answers in their forms.

Now, input types don't live on their own. We're not just placing a single checkbox on a form asking people to figure it out for themselves. They tend to live with a number of different elements. Here's an example of the different ways an input type can live on a form and the structure that they usually take. No matter what input type we're using and how it's being structured in a form, generally there is a title through a label. There's the actual data we're collecting which may have a prefix or a postfix, there maybe some associate actions, and some indicators of what's require or how to get help.

So there's more going on around the input field than just the input field itself and all of this stuff really helps people understand what should go inside of that input field. Selecting which input type we use is also something that we need to take into consideration. So let's take the simple task of a form that allows a novice, first-time user coming to the site to select up to six ticket totals from three different classes of tickets. The design that we develop should really optimize for learnability, obviousness, and error prevention.

One way we can do this is with an open text field, a plaintext input. Here, people can enter 0 to 6 tickets for each type of ticket: General, Senior, or Child. One of the challenges with this design is that it's not very good at error prevention. That is, I could enter 8 or -15, in which case the form would have to respond with an error state. I also find myself having to move between mouse and keyboard or strictly moving between keyboard and tabbing through the fields in order to make my way across the form.

Another way to solve the same problem is by using a drop-down list input type. Here we take a much more aggressive stance against preventing errors. In other words, each drop-down menu only has options 0, 1, 2, 3, 4, 5, and 6. You can't put in 8 through -15, so errors are much less likely to happen. However, the obviousness of the solution and the usability of it is a little tougher than the open text field. In order to manipulate a drop-down menu, somebody has to either move your mouse to the little arrow, click, select the field, let go, and repeat that process across each drop-down field. Little harder than tabbing between fields and typing as you can do with an open text box solution.

So while this solution provides more aggressive error checking, the usability takes a little bit of a hit. Option three of solving the exact same problem uses radio button input type. Here I've only included the first four ticket types as radio buttons and you can see you can put 0, 1, 2, 3, or 4 for again, three types of different tickets. This solution again takes a pretty aggressive stance against errors. You can't really pick something that would fall outside the range, but it introduces a lot of visual elements to the form, making things feel a bit more complex.

Imagine moving this out to 6 or 8 and quickly the scalability of this approach starts to break down. So which input type is right? Should we be using open text fields, drop-down menus, or radio buttons? Hopefully as this example illustrates, there's a number of things to consider. Not just error prevention, overall usability, but also how things get represented on the form. Where the layout gets too dense, where there's too many choices, all these things play a factor in picking the right input field. When picking input types though, it's important to stick with the standards.

Both browsers on the desktop and mobile will do their best to make interactions useful and usable when you use a standard UI element. Let's look at it on the iPhone. So if I use a drop-down menu here, standard select, and I tap that with my finger, up pops a Device Optimized UI Control. What I mean by that is, rather than the small little drop-down menu you get on a desktop which would be very hard to manipulate with your fingers, you get a big scrollable area with large touch targets. Just flick the wheel to get to the year you want and tap it.

The touch target is large and the wheel can simply be scrolled. Similarly on an Android device, the same standard UI element of a drop-down menu has a series of device-specific affordances. So when I tap on a country drop-down field on Android, I get a nice big dialog window with again, scrollable area and large touch targets. Each device does its best to optimize for its capabilities if you're using a standard control. Now, there are some limitations of this series of standard inputs we looked at earlier.

Checkboxes, radio buttons, and plain text boxes aren't necessarily going to do all your heavy lifting for you. Luckily, in HTML5 and beyond, there are a number of new input types that can be used to make things easier. While support for these isn't huge, there is no harm in using many of these today, as browsers that don't understand them will simply ignore them and use input type text. But browsers that do understand them can start to do some really valuable things. In particular input types like number, range, and date give us a lot more control over errors and of how people could provide input inside of our fields.

Let's take a look at number. With number I can now specify a minimum value, a max value, a step function, and an initial starting value. The way a browser would represent this is an input field that start with 6 and a spinner control that allows me to step that up by going 6, 8, 10, until I hit the max value of 10. Similarly, an input type of range can also have a min, a max, a step value, an initial value, but here a browser might represent a range as a slider, same type of idea.

Specifying a more direct input type gives us more control beyond just a plain text input. Here is a more obvious one: input type date, guess what kind of control the browser will give you here? That's right, a little date pop-up that you can use to select not only a month, a year, but a specific day as well. How each browser represents this date control is up to it, but it takes the burden off of you from creating JavaScript solutions or custom HTML to allow people to select dates. Simply specify the type and let the Web browser take care of everything else.

Now as I mentioned before, there isn't that much support for these things on a desktop, but on mobile browsers, there is a lot of advantages to already starting to specify input types. For example, specifying an input type of number as we saw earlier on a text field will bring up a numerical keypad on a device like the iPhone. This makes it a lot easier to provide accurate input when you're being requested for a number. The keyboard is defaulted to numerical values, there is a Period (.) there in case you're doing prices, and there's actually a punctuation mark like Dollar Sign ($) and Colon (:) that allow you to provide really accurate numerical information.

Specifying input type instead of email will bring up another custom soft keyboard control. Here we see a series of letters and at the bottom an At (@) symbol and a Dot(.). Most email addresses contain an at (@) symbol and a dot (.), so there you have a quick shortcut to providing that input accurately and effectively. One more example, let's specify an input type of url and we'll see that the soft key shows up with a dot (.), a slash (/), and a shortcut feature of .com, once again making it faster, easier on mobile to provide input while reducing the potential for errors.

And that's the great thing about these new input types. They make things easier for people. If a browser doesn't understand the input type of url, no problem. It just defaults to a plain text input. Text inputs on mobile devices can also be enhanced with a couple of additional attributes. Specifying auto-capitalize and turning it off on fields like e-mail, password, and URL allow you to get rid of the errors that come up when the first letter in a word is automatically capitalized. Auto-correct is another big one, turning that off on e-mail, password, URL, and other non-alphanumerical inputs help save people the problem of having things auto-corrected for them.

How often is the computer going to know what your password should be through auto-correct? Not that often and if any you've had things auto-corrected for you automatically, you know that sometimes that can be a frustrating experience. Trimming the trailing spaces that come through auto-correct features is another important consideration, especially when you start putting those values into your database. Additionally, you can specify other things such as language mode and format, where they're supported by devices. The idea here is, do small things to make the act of providing input on mobile easier regardless of whether each device supports it.

Those that don't understand it will ignore it, and those that do understand it will make these little details like auto-capitalize and auto-correct much better for your customers. Additionally, mobile devices by their nature are great at providing numbers. So specifying numerical declarations to resolve HTML5 or Wireless CSS can also go a long way. Even in cases where the mobile device doesn't have a virtual keyboard, people won't have to switch to numerical mode. It'll happen for them by default so they can just start tapping and have numbers entered into the input field.

It's also common for numerical values on forms on mobile to use a single line. After all, these devices were created for entering phone numbers. Why break phone numbers across multiple input fields when a single input field suffices? Similarly on price fields, there's a dot (.) right there on the keyboard and you don't need to have two separate input fields, but as I mentioned, sometimes the standards aren't enough and there are cases where defaulting to common input types just doesn't get the job done.

Let's look at an example on the Windows Live Hotmail account. Here when I select a secret question by which I can get back to my account, I see the following list of questions pop up in the Device Optimized UI Control: Favorite... cal person. I wonder what that could mean. Here we're seeing that the Select menu, as displayed inside of the scroll wheel, is actually suboptimal. In other words, there isn't enough room to actually see the content. And so when you encounter a situation like this, it may actually better to think about a custom control rather than going with the default standard.

Here, because these questions can run long and there's a decent list of them, you may be better off with a separate screen list where people can select rather than using a drop-down menu. Similarly on the American Airlines form for selecting traveler information when booking an airline ticket, you may have a better option for actually picking day, month, year, and setting some of these defaults such as the number of people traveling in each category. Looking at the Mobile Web solution for the hotel search site KAYAK, you can see where they've applied some custom controls in place of where American Airlines uses standard drop-downs.

One place is with the Spinners. The Spinners here are set to common defaults. When booking a hotel room, most people book a single room for a single guest. If they need to change that value, one tap on the Plus (+) sign is all it takes and in fact, on KAYAK, you can only book up to four rooms at any given time. So at most, getting this value up to four takes an additional one, two, three clicks, which is roughly the amount of clicks it takes to manipulate a single drop-down menu on the American Airlines site.

You tap the drop-down menu, you move the scroll wheel to the value you want, you tap on that, and you click Done. Four taps versus a single tap on a Spinner to achieve the same effect. When you have multiple questions like this, these controls tend to be a lot more efficient. Similarly, selecting a day on KAYAK has a custom control. When you tap on the little calendar, you get Device Optimized Touch Targets, that is the size of the controls are designed for the size of your fingers. So you can really quickly move between months and tap the date you want and again, without having to manipulate multiple drop-down menus like you need to on the American Airlines site where you can see month, day, and time are actually three separate drop-down menu fields.

On KAYAK, the date and the month all happen with a single touch. Now, just because custom input controls make sense in some areas, it doesn't mean they make sense everywhere. Here's an example of a native iOS control that is actually quite convenient. So selecting a height which consists of feet and inches actually brings up two of these spinner controls. You can select feet in one and inches in the other. Similarly, you can do this for a date, month, day, and year each having their own Touch Optimized Spinner Control.

The effort of taking this native control though and putting it inside the Web browser is a little extreme. As we can see on Qantas airlines, they've taken great steps to making this work inside of a Web browser. In fact, they've even got an animation upfront that shows you how it works. While I applaud the amount of effort that went into creating the selector field, this is a control that's specific to Apple's iOS system. Therefore on the Web, it may not make sense on an Android device or a BlackBerry device or a Palm device. Native controls, just because they work in a particular operating system, don't necessarily make for a better experience in the Web browser.

Wrapping up on input types, there's definite pros and cons for each input type and when you make decisions about which one to use, consider not only error prevention, usability, but also the overall layout and density of information on the screen. All these factors and more can lead you toward the right solution for an input type. Heavily favoring standard input types gives you a lot of benefits as browsers both on mobile devices and the desktop will do their best to create the best experience for people possible. They'll create large-sized touch targets, device optimized controls, and anything within their power to make it easier for people to select the values.

A custom solution should only come in to play if the standard is really falling short. As we saw earlier, when it's a lot more work to manipulate a standard and you can get things done to a single action with a custom solution, that maybe a good solve, but think twice about just porting over native controls both on a desktop and mobile. What works well in a native solution might not be the best experience in inside of a Web browser.

There are currently no FAQs about Web Form Design Best Practices.

Share a link to this course

What are exercise files?

Exercise files are the same files the author uses in the course. Save time by downloading the author's files instead of setting up your own files, and learn by following along with the instructor.

Can I take this course without the exercise files?

Yes! If you decide you would like the exercise files later, you can upgrade to a premium account any time.

Become a member Download sample files See plans and pricing

Please wait... please wait ...
Upgrade to get access to exercise files.

Exercise files video

How to use exercise files.

Learn by watching, listening, and doing, Exercise files are the same files the author uses in the course, so you can download them and follow along Premium memberships include access to all exercise files in the library.

Exercise files

Exercise files video

How to use exercise files.

For additional information on downloading and using exercise files, watch our instructional video or read the instructions in the FAQ .

This course includes free exercise files, so you can practice while you watch the course. To access all the exercise files in our library, become a Premium Member.

* Estimated file size

Are you sure you want to mark all the videos in this course as unwatched?

This will not affect your course history, your reports, or your certificates of completion for this course.

Mark all as unwatched Cancel


You have completed Web Form Design Best Practices.

Return to your organization's learning portal to continue training, or close this page.


Upgrade to View Courses Offline


With our new Desktop App, Annual Premium Members can download courses for Internet-free viewing.

Upgrade Now

After upgrading, download Desktop App Here.

Become a member to add this course to a playlist

Join today and get unlimited access to the entire library of video courses—and create as many playlists as you like.

Get started

Already a member ?

Exercise files

Learn by watching, listening, and doing! Exercise files are the same files the author uses in the course, so you can download them and follow along. Exercise files are available with all Premium memberships. Learn more

Get started

Already a Premium member?

Exercise files video

How to use exercise files.

Ask a question

Thanks for contacting us.
You’ll hear from our Customer Service team within 24 hours.

Please enter the text shown below:

Exercise files

Access exercise files from a button right under the course name.

Mark videos as unwatched

Remove icons showing you already watched videos if you want to start over.

Control your viewing experience

Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.

Interactive transcripts

Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.

Learn more, save more. Upgrade today!

Get our Annual Premium Membership at our best savings yet.

Upgrade to our Annual Premium Membership today and get even more value from your subscription:

“In a way, I feel like you are rooting for me. Like you are really invested in my experience, and want me to get as much out of these courses as possible this is the best place to start on your journey to learning new material.”— Nadine H.

Start your FREE 10-day trial

Begin learning software, business, and creative skills—anytime,
anywhere—with video instruction from recognized industry experts. provides
Unlimited access to over 4,000 courses—more than 100,000 video tutorials
Expert-led instruction
On-the-go learning. Watch from your computer, tablet, or mobile device. Switch back and forth as you choose.
Start Your FREE Trial Now

A trusted source for knowledge.


We provide training to more than 4 million people, and our members tell us that helps them stay ahead of software updates, pick up brand-new skills, switch careers, land promotions, and explore new hobbies. What can we help you do?

Thanks for signing up.

We’ll send you a confirmation email shortly.

Sign up and receive emails about and our online training library:

Here’s our privacy policy with more details about how we handle your information.

Keep up with news, tips, and latest courses with emails from

Sign up and receive emails about and our online training library:

Here’s our privacy policy with more details about how we handle your information.

submit Lightbox submit clicked
Terms and conditions of use

We've updated our terms and conditions (now called terms of service).Go
Review and accept our updated terms of service.