Written by Ramón Saquete
Table of contents
Better usability in forms is synonymous with better conversion, because by decreasing the difficulty in terms of making a purchase or sending contact information, the number of users who can complete these tasks increases. This is much harder in mobile devices, so we need to take into account some additional considerations.
The subject of usability is a vast field and many books have been written on it. Helping our users to use our website in an intuitive and easy manner is complicated, more so when they have to fill in their data on a small screen by tapping it with their fingers. As a general recommendation, we must strive to make the users carry out the minimum amount of actions and make them think as little as possible, otherwise they’ll end up frustrated and throw in the towel.
In the paragraphs below I am going to focus on technologies and patterns, which I consider to be indispensable when trying to improve the usability on mobile phones and tablets, although most of them are equally applicable to desktop web apps.
Types of HTML5 fields
Before HTML5 came, if we wanted to enter a phone number, a postal code, a date or an e-mail, we used text input fields for everything, in the following way:
<input type="text" id="cp" name="cp" />
Now we can use the following special fields:
- Telephone: type=”tel”
- Number: type=”number”
- URL: type=”url”
- Email: type=”email”
- Date: type=”date”
If the browser doesn’t recognise any of these field types, it will assume it’s a text. You can find the full list here.
The advantage these types of data introduce is that, on mobile devices, a different keyboard will appear for each of them. I.e. a numeric keyboard for the telephone number, a keyboard with the “@” symbol for the e-mail, or the .com button for the URL type. This way, the user will be able to fill in their data more easily.
When using these fields, we must be careful with their behaviour on desktop. For example, if we include a postal code as a “number” type, in desktop we will have a spinner with buttons to increase and decrease the value by one, which in this case doesn’t really make sense.
So, we can detect the type of device in use, and if it’s a desktop computer, make it a text field, and if it’s a mobile device, use the type “number”. For example:
Another thing we have to keep an eye on is whether we get the desired behaviour for the date type. To implement an input field like this one we’ve always relied on calendars generated using user interface libraries for desktop written in JavaScript, which always display the same calendar adapted to the application’s design, but these calendars aren’t suitable for mobile devices, because they’re very small.
If we use a date input type for mobile, we will have different calendar interfaces based on the device, but much more usable:
Similarly, on desktop, depending on the browser we will have a different calendar, without our corporate colours. So, if we want or if the browser doesn’t support the date input field, on desktop we can discard this data type and continue using the JavaScript library.
Another option is to use user interface libraries in JavaScript for mobile, so that our calendars look similar to the ones displayed by the device. In the case of mobiles devices, it is always best to use the HTML5 data types instead of libraries, even if we can’t use corporate colours, because this way we don’t have to resort to additional code that will slower the download and consume more battery. It also has the additional advantage of the user seeing a controller for date input they had previously seen on other websites, which they are more used to.
Autofill
Autofill is a new HTML5 feature, which allows to fill in automatically all the input fields of a form in the browser, by using other forms we’ve previously filled. If we want, we also have the option of entering our data manually in the browser. This feature is active by default in the latest Google Chrome and Firefox versions, both for mobile and desktop. In Internet Explorer and Safari they can be enabled, too.
When autofill is active, the browser shows a drop-down list when we start to write inside the first input field, and when we select one of the options, it will fill the remaining fields with the appropriate data.
Autofill tries to guess which data matches each field by the name they are given in code, but we can indicate in the HTML exactly which field it is by adding the autocomplete=”field-name” attribute. For example, if we want to autocomplete the credit card number, we would have the following input field, where we will indicate that it must be autocompleted with the value stored for “organization”.
<input type=»text» id=»company» name=»business» autocomplete=»organization» />
The full list of values the autocomplete property can take is available in the WHATHWG specification.
Labels with associated fields
Form labels should always be associated to the field they are referencing using the “for” attribute of the “label” tag. This way, the user can always click on the label to go to the field. With regard to checkboxes, this becomes especially important on mobile devices, because it will be much easier to tap on the label than the checkbox itself.
Passwords without asterisks
For password we’ve always used “password” type input fields, which display asterisks instead of the password itself, to shield ourselves from prying eyes. However, on mobile this no longer makes as much sense as it used to, because these devices are more personal and it’s easier to make a mistake when typing something. For that reason, there’s usually a checkbox, which changes the input field to text type, which allows us to see what we’re typing. It’s also a good idea to unhide the password after one failed attempt to log in.
Autogrowing fields for comments
Multiline text fields used for comments display scroll bars when we exceed the preset size. These bars are rather awkward to use on a small screen, but there are many JavaScript libraries to make these text areas “autogrow”, so that the size of the field grows as more lines are needed.
Autocomplete
When the list of values a user can type in is very long, we usually display a list of possible values for the first few letters, through AJAX. In these cases, when the user selects an input field, we must position the scroll in a way that this field is placed at the top of the page. If it isn’t we might not have enough space to see the full drop-down list, due to the space the keyboard takes up.
Some additional advice
- Erase button: free text field could use a button with a small cross at the end of the field, to allow the user to easily erase what they’ve typed.
- Hint: using the HTML5 “placeholder” attribute we can place a text inside an input field to indicate what has to be entered in it. For example:
- Focus: using CSS we can change the style of the input field with current focus using the “:focus” pseudo element, this way we help the user to see where they are.
- Change the focus to the first input field: using the autofocus attribute or the JavaScript “focus()” method we can select the first field of the form when the page loads. Keep in mind that this is only useful if it’s the only form on the entire page, and when it’s loaded, the first field is visible without scrolling.
There is an infinite amount of usability considerations, besides the ones includes in this post. For example, it’s important to explain at the beginning what the form is for, to use the forms in just one column, to group mandatory fields, to recover information from social media, or to infer information such as the region from the postal code, etc. Don’t stop trying things, reading and researching.
