One of the biggest usability problems I’ve run into when viewing sites that are not properly optimized for mobile is forms. They can look terrible, be incredibly difficult to use and are something to be avoided at all costs.
Let’s be honest, forms are generally cumbersome to use on desktop. They always have been. All of these flaws are amplified when you cram them into a 3.5 inch screen.
So what can we do to make the experience better? Last month, I attended a workshop at An Event Apart Chicago, put on by Luke Wroblewski. He had some really great ideas on web form usability — especially in the mobile context. The workshop really got me thinking about all the things we could be doing to create better experiences. So, with some inspirate from Luke, here are several things we can do right now to create them.
Put your labels above the fields, not next to them
If there’s one thing you can do to increase the usability of your forms, this is probably it.
Placing your form labels above the input fields ensures your forms will look great on mobile devices with little effort. Do the same with your error messages, placing them below the field. I’ve illustrated this with the graphic below.
Alternately, you could use a little JavaScript to place the label right in the field. The problem I see with this is that I sometimes tap into the field, and forget what I was actually supposed to type.
Don’t shortchange your mobile users on functionality
Just because someone is accessing your site from a small screen doesn’t mean they need less functionality than the guy pulling your site up on his desktop computer. Don’t remove important features from your mobile sites because of screen limitations. Find creative ways to work around them.
If you’re allowing me to login to your site via my phone, also allow me to request a forgotten password or check a box to remember my login, so I don’t have to relive the painful experience again the next time I come back.
This is critical because simply typing my username or email address and password into a site on your phone is cumbersome enough. Imagine typing various passwords – all incorrect – without a way to retrieve the correct password from the mobile login. It happens.
Define the proper Input Type
We all know that password fields should be defined as <input type=”password“> rather than as <input type=”text“>, but with the ubiquity of mobile devices and touch interfaces, we have several additional Input Types that will greatly enhance usability on these devices. Let’s take a look at a few of them:
<input type=”number”>
Specifying Input Type as Number will give you a customized keyboard that puts an emphasis on entering numbers – not letters or symbols. Here’s how it looks on the iPhone:
<input type=”email”>
Alternately, setting your Input Type to Email will generate something more suitable for entering email addresses:
Setting your Input Type to URL will produce a keypad that is similar to the above, but with minor changes. Notice how the .com can now be added by clicking one button. If the Input Type was incorrectly specified, I’d have to manually type that out. Here’s a screen shot:
Provide clear error and success messages
Here’s the graphic again, illustrating a functional error message. It’s clear, at a glance, that this field is causing a problem and it’s telling me what that problem is.
Taking it a step further, this could validate with inline client-side code, rather then server-side, which would allow us to validate the fields in real time. We could fix the problem before we move to the next one, making sure we don’t lose any information as we often do when we submit a page and it comes back with issues forcing you to, oddly enough, retype the information the was correct as well as the stuff that was wrong.
Also, make sure your error messages are meaningful. Don’t give feedback that is too technical to understand.
Bigger is usually better
Especially on mobile, bigger is generally better. Larger form fields and larger buttons. Anything I may need to touch with my finger should be large enough that I can easily hit it – and not whatever is surrounding it. Generally, I try to make buttons and form fields them entire width of the mobile screen.
Likewise for desktop.
If you want users to input data, make it obvious.
Think about alternate ways of input
I input data differently into all my devices. My MacBook is great for typing large amounts of text. My iPhone, not so much.
Voice and simple touch interfaces are great for inputting data into a phone. Form fields like radio buttons and select boxes are simple and easy to interact with on your phone. Anything that can be done to reduce typing into form fields on your phone is a UX enhancement.
A great addition to the iPhone (and I’m sure lots of other phones) is this nice little voice input button that appears on the keyboard, to the left of the space bar. Touch it and speak into your phone. It will decipher your words and fill in the field for you. So essentially, every field becomes retrofitted with voice capability. I use it all the time. Here’s a screen shot:
Consolidate form fields and simplify
Did you notice how I condensed First and Last Name into one field, rather than two? Here it is again for the third time:
Try to consolidate form fields so less “field hopping” is required. Can you condense fields for credit card type, credit card number, security code and expiration date into one field? Luke can, and he illustrated it beautifully at An Event Apart. If I can track that down, I’ll link to it here.
Ditch the tables
We abandoned tables for DIVs in terms of layout purposes years ago, but using tables to layout forms has always been what I consider a “proper” use of tables. But today, if you want to create forms that are responsive all the way down to mobile, it’s time to put another nail in their coffin of old friend, the Table.
Tables are usually used in forms to create side by side layouts, where the field label appears to the right and the field input to the left. That looks great on desktop layouts, but as I mentioned above, it’s not a layout that favors the mobile world. As I mentioned earlier, simply stacking your labels and validation messages will render tables unnecessarily, thus kind of working out the problem itself.
