Modifying Desktop Web Forms for Mobile Use
- #1: Cut Down on the Keystrokes
- #2: Maintain Context and Readability
- #3: Minimize Gestural Interaction
- It's Still a Band-Aid
No matter how adept we become at using virtual keyboards, or those tiny versions of physical keyboards found on various smartphones, the fact is, typing on these things can be arduous. While creating an account on a new website may be a trivial task on the laptop, it can be a chore on an iPhone. Even when forms are short and sweet, they can be marked up in ways that make them more difficult to complete than they should be. And even if your mobile conversion rate is far lower than for desktop web users, your signup form is still a user's first impression, and it could be the one that keeps them around or turns them away. And even if your existing customers almost always use the desktop web version of your site (check your stats: this may not be as true as you think), it's never a good idea to frustrate those who need to do so while away from their desks, perhaps especially when they're people you've already convinced to become customers.
For these and many other reasons, it's vital to start making sure the forms on your desktop site play well with the people holding them in their hands. Here are a few things to consider tweaking until you can finally get a mobile site in place.
#1: Cut Down on the Keystrokes
The primary way to make forms less arduous for mobile users is to minimize the keystrokes needed to complete a form, and there are several ways to do that.
First, cut down the number of required fields, and remove the optional ones completely. Do you really need the user's full name for her to register? Do you really need to know two different phone numbers to handle an incoming inquiry for a pricing quote? If it's non-essential, cut it from the list of things to make the user type.
Second, in registration forms, consider an alternative to the usual "Verify password" field that requires the user to type in his desired password twice. Instead, offer a "Show Password" checkbox just below the Password field that enables the user to verify what he has typed. In this case, enabling the Show Password option should change the displays of the entered password from a bunch of dots into plain, readable text. The user can then easily double-check his typing skills without having to type anything more.
Next, use the correct corresponding markup for the type of data you need to collect. When you need a user's email address, make sure the field is labeled as an email field in the markup so that iOS and other virtual keyboard systems display the appropriate keyboard. Else, the user has to manually switch to the keyboard view that offers the @ character and period (true on iOS) and then manually type the domain extension (.com, .net, and so on). This all takes several more keystrokes than would be needed if the field had been marked up correctly (see Figure 1).
Figure 1 Google Talk’s “Login” field fails to specify whether to enter a username or email address.
To this point, there are times when a sign-in process can accept either a username or email address. In those cases, consider using two fields as an either-or option. The people who need to enter an email address will appreciate the decreased effort it takes to sign in.
Finally, when you display default values in fields to clue users into what type of information to enter there, make sure the default values disappear as the field gains focus. The user should never have to delete the default value manually.