Ready to watch this entire course?
Become a member and get unlimited access to the entire skills library of over 4,900 courses, including more Web and personalized recommendations.Start Your Free Trial Now
- View Offline
- 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
Skill Level Appropriate for all
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.
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.