Forms On Mobile Devices: Modern Solutions
Mobile forms tend to have significantly more constraints than their desktop cousins: screens are smaller; connections are slower; text entry is trickier; the list goes on. So, limiting the number of forms in your mobile applications and websites is generally a good idea. When you do want input from users on mobile devices, radio buttons, checkboxes, select menus and lists tend to work much better than open text fields.
But constraints breed innovation, and mobile forms are no different. The limitations of mobile devices have forced developers and designers to find new ways to allow users to input data faster and more easily. Thanks to the modern solutions covered in this article, the mobile space may not be a place to avoid forms much longer. Instead, it may become the place to encourage them.
Field Zoom
In many mobile Web browsers, when a user selects a form’s input field, the “field zoom” feature expands it to fill the screen’s viewable area. This makes an otherwise tiny field large enough for people to actually see the data they are entering. Given that many form errors are caused by people not seeing their inputs well enough to correct misspellings, the usability of this feature is clear.
The Safari browser on Apple’s iPhone makes use of field zoom together with a “form assistant.” The form assistant displays “Previous,” “Next,” “AutoFill” and “Done” buttons below the magnified input field, giving people an easy way to move through and complete a form. No need to worry if an input field is off screen: the user just hits “Next” and won’t miss it!

However, not everyone will know about the form assistant or know how to hide the keyboard. So, make sure the controls on the Web page still allow them to complete the form. Excessive spacing around the “Submit” button can tuck it behind the keyboard.
Field zoom is another great reason to top-align input field labels in forms. As you can see on Google’s registration form (screenshot below), left-aligned labels disappear when input fields are expanded to fill the screen. With no visible label, the user can easily forget what question they have to answer. Long input fields also suffer a bit with field zoom.

Mobile browsers that don’t have field zoom also run into issues with left- and right-aligned input field labels. Anyone using such a form on Google’s Android OS (below) faces the problem of disappearing labels. The screen simply does not have enough room for both the input field and its corresponding label. Top-aligned labels avoid this issue.

Input Formats
Some mobile Web browsers recognize specific input types (part of the developing HTML5 standard) and adjust their input modes accordingly. For example, specifying an input of the type url brings up a virtual alphanumeric keyboard with “.”, “/”, and “.com” keys. Specifying an input of the type email brings up a virtual alphanumeric keyboard with “.” and “@” keys. Specifying an input of the type number brings up a virtual numeric keyboard.
These input-specific keyboards make entering the particular type of data required by each input field much easier. Even browsers without virtual keyboards benefit from the use of number, because users would not have to switch to number mode to enter numeric data.

Password-Masking
Most password input fields in forms instantly obscure all characters that a user enters to keep sensitive information hidden from prying eyes. Automatic masking of passwords may provide the appearance of security, but it can also create usability issues when people are left staring at a row of bullets that they hope (but can’t verify) is their password.
Many mobile devices address this issue by displaying the most recent character the user has entered, and then obscuring that character as a bullet only after a brief delay. This technique has made its way onto the desktop, as illustrated in this password-masking solution from ZURB.
Pop-Up Menu Controls
Drop-down select menus are one of the hardest input types to use. First, you have to click on the menu to open it. Then, you have to maneuver through a potentially long list of small targets. Once you find the value you want, you need position your cursor on the right target and select it. To top it off, many implementations of drop-down menus on the Web require you to keep your cursor on the menu while navigating the list, or else the menu closes!
Even dexterous users often miss them and need to start over. Couple this interactive challenge with the small screens of mobile devices and the need for a different solution for select menus becomes quite obvious.
For drop-down select menus on Web forms, Apple’s iPhone presents users with a pop-up menu control. This control displays the options in the menu in a contained list that can be scrolled at various speeds though drag, nudge and flick gestures. The large touch targets also make it easy to select the right value once you’ve found it.

Similarly, Google’s Android provides a larger touch target for select menu options. When the user taps a drop-down select menu on an Android device, a scrollable list of menu options appears in a dialog window over the Web page.

Compound Menu Controls
Pop-up menu controls can be applied to compound inputs as well. So, instead of requiring three separate input fields for the month, day and year of a requested date, one date field can bring up a set of pop-up menus that allow people to scroll through three lists at once to find the right date. This approach can be applied to other kinds of compound inputs as well, such as height in feet and inches.

Google’s Android has a compound input field solution, though it makes use of visible interface elements to move through a list instead of relying on gesture-based scrolling alone.

Native Input Controls
In addition to having compound menu controls, most mobile operating systems have several other custom input controls available to application developers. Sliders, split buttons, rating widgets and scrubbers are just a few of the components worth considering in place of standard form controls to make inputting easier for users.

Orientation
Because people like to hold mobile devices both horizontally and vertically in their hands, mobile forms should adjust accordingly to take advantage of the changing screen space. The compose email form on Google’s Android does just that.

When held vertically, the screen shows three input fields with several action buttons. In the horizontal position, the email body input takes over the screen, and one action button is shown on the right. This layout maximizes the screen space available for the message content.
Voice Input
Google’s Nexus One phone allows people to use voice input for any text field in an application. Users can swipe the virtual keyboard to switch the phone to audio input mode, or they can use the microphone button. The video below demonstrates both of these options in action. With effective voice input, typing any characters into the mobile device becomes a thing of the past.
What’s Next?
Mobile is growing exceptionally fast, and as more designers and developers focus on the space, we’ll hopefully see even further innovation in mobile forms. After all, anything that makes inputting (both on mobile and desktop devices) faster and easier will do a lot of good for both companies and their customers.
About the Author
Luke Wroblewski is an internationally recognized digital product design leader and the author of two popular Web design books. You can follow Luke on Twitter @lukewdesign or by using RSS.
Smashing Magazine readers can get a special 20% off discount on Luke’s latest book: Web Form Design Filling in the Blanks. Just use discount code MIX to order.
(al)




Gport
March 11th, 2010 4:50 amGreat article, gives a good insight on how forms work on mobile devices!
Blaze Pollard
August 12th, 2010 11:56 amHere is a form that works on mobile devices also, validates, and it sends a fancy email :)
http://bit.ly/b6GSWE
Check it!
Jack H.
December 6th, 2010 9:08 amLove the form. Thanks man!
tony
March 4th, 2011 2:48 pmI don’t see anything about a mobile web form on that link?
Krunal Mehta
October 14th, 2011 12:12 pmHi Blaze, the link you provided does not work, can check and post again? Thanks.
Greg Babula
March 11th, 2010 4:52 amAwesome, thank you!
sunil
March 11th, 2010 5:25 amWhat about the file upload button ? :(
Ryan Yates
March 11th, 2010 5:49 amAny examples of good UI design on a Nokia?
oskar
March 11th, 2010 6:04 amOrientation is great – how is it implemented?
Andi
March 12th, 2010 1:23 amtake a look here http://articles.sitepoint.com/article/iphone-development-12-tips/2
Ionut Botizan
March 11th, 2010 6:10 am@Ryan
Well, the iPhone Password-Masking way is not actually the iPhone way. Nokia had that long before the iPhone came out, so here’s an example of good UI design. :)
Russ
March 11th, 2010 8:11 amI don’t think it was suggest that it was the ‘I-Phone’ way ;)
Andrew Sipe
March 11th, 2010 6:13 amI’ve been a recent iPhone converter and I’ve noticed on several occasions while filling web forms, of how simplistic and intuitive it is.
I am curious though, is there a way to set the phone up to have a specific keyboard come up as default. I tend to have to fill in my email address often, but the URL keyboard seems to be the default on my input fields. The EMAIL keyboard would be preferred, but it’s likely not specified. What’s a work around for this, or would it be more prudent for a designer to set EMAIL as the default keyboard out of the gate?
Tom - Airopia
March 11th, 2010 7:28 amGood idea for an article.
I’m starting to scratch the surface for ideas in develpoing a mobile version of my site, and this helps. I was also wondering if it would be a good idea to make a rss feed app for the iPhone?!
Wendell Fernandes
March 11th, 2010 8:07 amA good way to get this going as well, is to create a form where if you click on a specific field, you can get another screen template just for forms, since you are going to at lease design the whole app, why not a better form screen template?
Thany
March 11th, 2010 8:13 amHow do you make such “compound menu controls” in html? Or did I overlook the html code for them?
Andi
March 12th, 2010 1:20 amI also hope Luke can tell us how to do them.
I’ve searched on Google but i can’t find anything about that.
Jayphen
August 17th, 2010 4:34 pmThe compound menu controls are OS-native controls rather than Webkit-native controls, so it is not possible to use them in HTML.
There is a JavaScript solution at http://cubiq.org/dropbox/sw/, but keep in mind that if you use this, people on other mobile devices may be confused. It is not good practice to emulate OS-specific interface elements in this way. If you’re on a Mac & a webpage uses Windows-native interface elements for example, it will not be a comfortable experience for you.
sahil
March 11th, 2010 9:58 amOne thing that this article didn’t touch upon is form inputs such as search boxes that depend on the user pressing the Enter key to search (without any “submit” button) or select menus that perform an action (such as navigating to a new page) when the user clicks on a particular choice. Such controls fail on many mobile platforms.
Steve
March 11th, 2010 10:43 amI have just myself begun working on converting some forms for mobile devices … very handy.
m4c
March 11th, 2010 12:41 pmAwesome! Ok, but “mobile devices” is not only iPhone and Android. Where is eg. Symbian and its mobile web philosphy and interface?
BBL
March 12th, 2010 2:50 amAwesome, thank you!
steve mg
March 12th, 2010 7:28 amThis is a great article and more and more we should be seeing these kinds of postings. One thing though, your examples are showing web development for the big 3 of mobile browsers. What I mean by that is that they are the most powerful and should only be one facet of your mobile web dev kit. Many device manufacturers have their own browser “baked” into the device and allow little control for appearance. The legendary RAZR for instance had its own (horrible)font that no amount of style sheets could override. Sure each manufacturer is or has made an Android and possibly Web OS friendly phone, but many of their offerings in the near future include whatever default browser has been baked in. Especially since those phones don’t have the power or the size, and aren’t as cheap to sell as the big smart phones.
emouse
March 12th, 2010 11:11 amGood article but ugh onscreen keyboard.
The world is more than iphones. Palm’s webOS for the Pre and Pixi is a great mobile OS.
Aleksander
March 15th, 2010 12:13 amCool article, you just forgot one thing:
http://gs.statcounter.com/#mobile_browser-ww-monthly-200902-201003
Why not include Opera Mini? The most used browser world-wide! With it’s introduction on Android and perhaps iPhone soon it’s just stupid to skip them..
RNunes
March 15th, 2010 1:46 amI’m all for modern. But this clearly accounts for western high-end experiences on top devices.
Get to the real everyday people all over the world: they don’t have these phones.
And that’s the real market for which we need creative design and usability solutions .
Marty
March 16th, 2010 7:01 amIt’s interesting to see some of these standards, and I realize why you focused on iPhone and Android – because they have the best UI/adherence to standards. But how well do these things work on Blackberry phones (both 2G models like Curve & Pearl, and 3G models like Bold & Storm)?
Pixil.info
March 17th, 2010 12:06 amGood points, I’ll forget to go back to register if I can’t easy sign up on the go!
Jon Peterson
March 17th, 2010 7:43 pmI love the article overall, but I would like to point out that the Password Masking solution provided by ZURB is (while visually appealing) inelegant and buggy. It is far simpler, and likely more effective, to merely toggle the input element’s Type between “password” and “text”. I have added a comment on the ZURB site with an example using a checkbox as a toggle, but it would be easy to adapt it to a button or radio switch.
Matt Vogt
March 21st, 2010 9:18 pmAwww man this stuff is soo cool! Thanks for the input type tips and such, bringing control to the minute, mobiles is a lovely step deeper in the details!
Thanks.
mmmMatt
Ritika
March 24th, 2010 12:42 amvery interesting tips .. I have just started to create a website for mobile.
Thank you so much. it will really help me..
Duncan
April 7th, 2010 9:31 amFor those with Windows smartphones, there is a product called ElectroForms (http://www.mobileelectronicforms.com) that provides an iPhone-style interface to Excel.
Useability is everything – worth a look!
twapt
April 30th, 2010 6:07 amThanks for sharing, Twapt is same ….
http://www.Twapt.net Mobile Form Builder helps you build forms, in just minutes, without any programming or design experience.
Your clients and visitors will be able to contact you anytime, anywhere, because your forms are accessible and can be filled from every mobile phone in the world.
Whether you want a contact form, a quick survey, an inscription form, employee reports, opinion polls, or any other input, using Twapt.net Mobile Form Builder – 5 minutes and you’re ready to go. Everywhere.
Ethan H
June 19th, 2010 7:56 amThis is great but that compound input for multiple drop-downs is hard to find. Any pointers for example codes to call up that view?
Bailey Digger
July 6th, 2010 8:13 pmHi Christian,
We just posted an article, “100 Great Graphic Designers to Follow on Twitter” (
webdesigndegree.com/100-great-graphic-designers-to-follow-on-twitter/ ) . I thought I\’d bring it to your attention in case you think your readers would find it interesting.
Either way, thanks for your time!
Cheers,
Bailey Digger
Blaze Pollard
July 20th, 2010 12:58 pmAjax’d Form with Fancy Email http://bit.ly/b6GSWE
Jayphen
August 17th, 2010 4:42 pmThis article is misleading in that it mixes up OS-native controls with browser-native controls.
For example, compound selectors such as the iPhone’s slot machine style selectors are not available within Webkit, so cannot be used in a web-based application.
Forms on mobile devices still have a long way to go – the controls available to us in mobile Webkit are not well optimised for mobile devices. HTML5 does help to some extent with URL, number & email input fields, but there is a long way to go.
Productivix
February 17th, 2011 6:21 amHi ,
you can paremeter / develop and test freely the forms for Windows CE or WM Windows Mobile/PDA with Tracerplus : http://www.saisie-mobile.eu/rubrique1.html
and share /download such applications on http://www.saisie-mobile.eu/rubrique2.html (integraption on GPS: RFID / Barcod is also embeded
Chris Beaman
February 24th, 2011 9:09 amThanks for this – I’m building registration forms for mobile and appreciate some of your factors to consider, such as top-aligned labels and expanding input boxes for horizontal/vertical viewing.
benjammin
May 23rd, 2011 9:51 amThis was a very informational topic. I learned a lot about web forms and I cannot wait to implement web forms on my portfolio! ♥
Linh Tran
September 26th, 2011 8:19 amGreat article. I just want to add that with the rise of smart phones, comes the rise of surveys that are compatible with smart phones. The power of speed and feel is very important as smart phones are small and users expects fast actions. http://www.mobosurvey.com allows you to create surveys that are not only compatible w/ smart phones but the look and feel of the surveys will be native to each device as well.