4. Forms
Developers are often tempted to make the mobile
version of a website far more of a read-only experience than its desktop
equivalent. It's certainly true that entering large amounts of text
into a mobile device can be a trying experience, and a design decision
to temper, say, the account registration functionality on a mobile site
may be a wise one. Nevertheless, forms and data entry are unavoidable
parts of a modern web experience, if only so the user can enter text
into a search box on the site. Large forms can be usefully broken up
into sections — a wizard-like experience — to try to mitigate the
daunting nature of a page full of form fields for the user.
Mobile devices adequately support most types of input field, at least in their own particular way. You can certainly rely on <input type='text'/>, <input type='password'/>, <input type='radio'/>, <input type='checkbox'/> and <select> widgets — although, as you can see in Figures 9 to 12
(which show iPhone, Android, Nokia Series 40, and Windows Mobile
rendering of the same form), their appearance can vary wildly. It can
certainly be very frustrating trying to create consistent layouts for
forms across multiple devices, so leave lots of space and limit your
expectations of pixel-perfect precision.
Advanced form widgets and behaviors can wisely be avoided. <input type='file'>
elements for uploads are risky, because not all devices allow
unfettered access to all parts of their file system (and indeed the
iPhone disables such form elements altogether). Clickable image maps may
work as expected for devices with suitable pointers, but are likely to
be of dubious reliability across all devices. And, although using AJAX
for background form submission would provide lots of usability benefits
in mobile, it is asking a lot of a device's JavaScript support to be
able to post forms reliably. Regular form submission, using GET and POST
methods, is recommended.
Because the act of filling in and submitting a form
can often be a lengthy and fiddly one for the user, it is highly
advantageous to ensure that form validation is as intelligent as
possible. If the device supports the required level of JavaScript, you
should try to detect any validation errors before the form is submitted —
or even as the offending field is in focus, so that the user does not
have to scroll back up the form to reach it. As an alternative, older
devices that support XHTML-MP may honor the {-wap-input-format:} property in CSS that allows you to construct simple input masks for freeform data input fields.
On the server-side of the
form processing, you should try to be as flexible as possible with the
submitted data, being tolerant of obvious data entry errors. (A
location-based search for "londob uk" can reasonably be assumed to have
been for 'London, UK', and it's probably not necessary to present
another page asking the user to confirm her mistake — proceed as though
she got it right in the first place.)
