In this second part, I want to focus more on mobile-specific capabilities. HTML5, for instance, has brought us a lot of really cool features to help users fill in mobile forms and format their data. We will see in detail how HTML5 attributes can help you with that. Then, we will go beyond “classic” form elements and see how to use mobile capabilities such as the camera, geolocation and fingerprint scanners to really take your mobile form experience to the next level on websites and in native applications.

Helping The User Format Content With HTML5

In the first part of this series, we saw some general advice on how to display fields. Now it’s time to go a bit deeper and look at how a few well-crafted lines of HTML5 code can improve your mobile forms.

HTML5 Mobile-Optimized Goodness

HTML5 opens a whole world of possibilities for optimizing forms for mobile and touch devices. A lot of interesting new input types can trigger different keyboards to help users. We can also do some interesting things with capturing media directly in the browser.

Entering Numerical Data

input type= number

The HTML5 <input type=number> attribute restricts an input field to numbers. It has a built-in validation system that rejects anything that is not a number.

In some desktop browsers, this input is presented with little arrows on the right that the user can click to increment the number. On mobile, it opens a keyboard with numbers, which decreases typos and form-validation errors. The input’s look and feel depend on the operating system.

The input should allow for decimals and negative numbers (but few keyboards respect that). As explained in the W3C’s specifications, “a simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with ‘up’ and ‘down’ arrows)”. This means that the input is not supposed to be used for credit cards or area codes.

The pattern And inputmode Attributes

To add some restrictions to your number inputs, you could use the pattern attribute to specify a regular expression against which you want to control values.

This is what it looks like:

<input type="number" id="quantity" name="quantity" pattern="[0-9]*" inputmode="numeric" />

You can use this pattern to bring up the big-button numeric keyboard on the iPhone (but not the iPad). This keyboard does not have the minus sign or comma, so users lose the ability to use negative numbers and decimals. Also, they can’t switch back to another keyboard here, so be careful when using this.

Also, note that patterns can be applied to any other type of inputs.

Using only this pattern won’t work on most Android phones. You’ll still need a combination of input type=number and the attribute to make this work.

inputmode

If you only want to trigger the mobile numeric keyboard but don’t want to deal with the type=number and pattern mess, you could use a text input and apply the inputmode=numeric attribute. It would look like this:

<input type="text" id="quantity" name="quantity" inputmode="numeric" />

Unfortunately (at the time of writing), only Chrome 67 mobile supports this, but it should be arriving in Chrome desktop 66 without a flag.

To learn more about how to enter numbers in a form, read “I Wanted to Type a Number”.

input type=tel

If you want users to enter a phone number, you can use the input type=tel. As you can see in the screenshot below, it triggers the same digits on iOS’ keyboard as the pattern attribute described above. Due to the complexity of phone numbers across the world, there is no automatic validation with this input type.

Entering Dates

Even if they are technically numerical data, dates deserve their own section. There are a few HTML5 input types for entering dates. The most used is input type=date. It will trigger a date-picker in supported browsers. The appearance of the date-picker depends on the browser and OS. To learn more on how browsers render input type="date", I recommend you read “Making input type=date complicated.”

There’s also type=week to pick a week, type=time to enter a time (up to the hour and minute), and type=datetime-local to pick a date and a time (using the user’s local time). So many choices!

input type=date works well for booking interfaces, for example. You might have some needs that require you to build your own date-picker, though (as we’ve already seen in the section on sensible defaults). But input type=date is always a nice option if you need a date-picker and don’t want to bring a whole JavaScript library into the website for the job.

Yet, sometimes not using type=date for dates is better. Let’s take the example of a birth date. If I was born in 1960 (I’m not — this is just an example), it would take me many taps to pick my birth date if I was starting from 2018. On Android, I discovered recently that if I press on the year in the picker, I get a sort of dropdown wheel with all of the years. A bit better, but it still requires a fair amount of scrolling.

A user told me on Twitter:

“I’m born in 1977 and can confirm the annoyance. The more time it takes to scroll, the older you feel :-(“

So, maybe birth dates are not the best candidate for date-pickers.

URL, Email, Tel And Search

Mobile phones hide some other keyboard and input-optimization goodness that enhance the user’s experience when filling in a form. The devil is in the details, as they say.

Using the input type=url field will bring up an optimized keyboard on mobile, with / (the slash key) directly accessible. Depending on the OS, you can also give quick access to commons top-level domains, like the .fr in the screenshot below. If you long-press this button, shortcuts to other top-level domains will appear. This also comes with automatic browser validation that checks that the URL’s format is valid.

The input type=emailfield brings up an email-optimized keyboard giving quick access to the @ symbol. This input requires the presence of @ somewhere in the field in order to be valid. That’s the only verification it does.

The input type=search field brings up a search-optimized keyboard. The user can directly launch the search from a button on the keyboard. There’s also a little cross to clear the field and type a new query.

Range And Color

The last two input types we looked at are not particularly optimized for mobile, but by using them, we can avoid having to load heavy custom JavaScript libraries, which is a good idea for mobile users.

input type=range provides a visual UI slider to input a number. The UI for this control is browser-dependent.

input type=color provides an easy way for the user to enter a color value. In many browser implementations, this comes with a color-picker.

HTML Media Capture: Taking And Uploading Pictures And Recording Sound

I remember the time of the iPhone 3, when Apple would not even allow a simple input type=file to be used on a website, for security reasons. Those times are long gone. With the HTML media capture API, it’s now possible to access different sensors of a device. We can capture photos and videos, and we can even record voice directly in the browser.

The accept attribute lets you specify what kind of media to accept in the input: audio, image, video. The user can give the browser direct access to their camera, for example.

The code looks like this:

<input type="file" id="take-picture" accept="image/*">

The capture attribute lets you specify the preferred mode of capture. If you add the capture attribute on top of the accept attribute, you can make the browser open the camera or voice recorder directly.

<input type="file" accept="image/*" capture> // opens the camera> 

<input type="file" accept="video/*" capture> // opens the camera in video mode 

<input type="file" accept="audio/*" capture> // opens the voice recorder 

For more details on how to use media directly in the browser, read the section “Accessing and Handling Images, Video and Audio Directly in the Browser” in my article on the secret powers of mobile browsers.

HTML5 Autos: Autocorrect, Autocomplete, Autofill, Autocapitalize And Autofocus

HTML5 comes with a slew of automatic attributes. To enhance the mobile experience, you will want to be smart about what can be automated and what can’t. Here are some general rules of thumb:

• Disable autocorrect on things for which the dictionary is weak: email addresses, numbers, names, addresses, cities, regions, area codes, credit card numbers.
• Disable autocapitalize for email fields and other fields where appropriate (for example, website URLs). Note that type=email does the job for you in recents version of iOS and Android, but disable it anyway for older versions or if type=email is not supported.
• You can set the autocapitalize attribute to words to automatically uppercase the first letter of each word the user types. This can be useful for names, places and the like, but, again, be careful with it, and test it.

• For input type=tel, set autocomplete="tel".
• You could use autofocus to give the focus to a control element when the user loads the page. But just because the user opens the “contact” page, it does not mean they are ready to jump right to the first field of your form. So, again, use it wisely.

If you want more autocomplete options, a whole list is on the WhatWG Wiki. Just make sure you use the right ones. Implement, test, and test again.

HTML5 Form Validation

I won’t get into the technical details here, but you should know that HTML5 has a built-in form-validation API for many fields. It’s nice if you don’t want to use a JavaScript library to display inline validation messages. Here are the main things you need to know as a UX designer about HTML5 form validation:

• The validation message is a browser control. You can’t style it in CSS, and it’s different for every browser.
• You can change the text of the message in JavaScript using setCustomValidity.
• CSS3 provides :invalid, :valid and :required and other pseudo-classes for HTML form validation. These get triggered on blur, so are pretty much useless for now.

In “Native Form Validation, Part 1,” Peter-Paul Koch goes into detail on why HTML and CSS form validation doesn’t really make forms better at this time.

Offline Support To Save User Data

A lot of things can go wrong, especially on mobile. Mistakes happen. A user could mistap the back button in the browser and lose all of their data.

If the user comes back to the page, it would be nice to display their data again. The same goes for if the browser crashes or the user closes the tab. You can store the user’s data in local or session storage to ensure nothing gets lost if something goes wrong. Geoffrey Crofte has written a JavaScript library to help you with that.

If the connection is lost as the user is submitting the form, they might also lose the data. To avoid this, you could use a combination of the** HTML5 offline API** and the Service Workers API to:

• store the data in the cache,
• try to automatically send it again when the connection comes back.

To learn how to code this, check out the article on “Offline-Friendly Forms”.

Mobile Device Capabilities Can Take the Experience To The Next Level

In part 1, we stuck to the basic common HTML form elements and attributes for enhancing mobile forms. But mobile devices capabilities now go far beyond displaying HTML, CSS and JavaScript web pages. Those little devices come equipped with a lot of sensors. And we will be able to use many of those in native apps and on the web to make our users’ lives so much easier.

Detecting The User’s Location

In the previous section, I wrote about pre-filling information for places and addresses. That’s a good start. We can go one step further. Instead of asking users to type a location, we can detect it. Meet the geolocation API for the web. There are also native iOS, Android and Windows Phone geolocation APIs.

Citymapper is a website and an app that helps users plan their travels. When the user goes into the first field, they see the “Use current location” option. If they select it, they are asked to allow the browser to access their geolocation data. This is the geolocation API. The browser then autocompletes the location it found and, the user can proceed to the destination field. The native app works pretty much the same way.

Be Smart When Asking For The User’s Permission

You might have noticed in the previous video that I had to agree to give access to my position to the Citymapper website. In the browser, the user handles permissions website by website, API by API.

You also need to be careful how you ask for permission. The user might refuse access to the geolocation, notification or other API if you ask too soon. They also might refuse if they don’t understand why you need the permission. You get one chance; use it wisely. After that, it will be almost impossible to recover. I’m an Android power user, and even I have to search around for the options in my browser when I want to reset the permissions I’ve given to a website. Imagine the trouble your users will have.

Here is some general advice on asking for permissions on the web:

• Don’t be the creepy geolocation or notification stalker: Don’t ask for permission as soon as the user arrives on your website. They might not know about you or your service yet.
• Let the user discover your website and service. Then, ask for permission in context. If you want to access their location, ask them only when you need it (Citymapper is a good example).
• Explain why you need permission and what you will do with it.

If you want to go further, Luke Wroblewski (yes, him again) has created a nice video to help you with the permission-asking process.

A Better Checkout Experience

A big area of improvement for forms is the whole checkout payment experience. Here again, sensors on the device can make this an almost painless experience. The only pain will be the amount of money the user spends.

iOS Credit Card Scanner

In the previous section, I wrote about autodetection of credit cards and autocompletion features based on the user’s previous input. This still means that the user has to type their credit card data at least once.

Apple has taken this to the next level with its credit card scanner. Since iOS 8 in Safari, users can use their camera to scan and autocomplete their credit card information. To perform this magic, you will need to add the autocomplete cc-number attribute and some name to identify this as a credit card field. Apple doesn’t have much official information on it, but some people did some testing and put the results on StackOverflow.

Safari also has autofill options that users can use to add their credit card, allowing them reuse it on multiple websites.

Take Checkout One Step Further With Google Pay API

Google launched something similar: the Google Pay API. When implemented on a website, the API eliminates the need to manually enter payment information. It goes one step further: It can store billing and shipping addresses as well.

The user gets a dialog in Chrome that displays the various payment information they’ve stored. They can choose which one to use and can pay directly through the dialog.

A standardized version of the Payment Request API is currently a W3C candidate recommendation. If this gets implemented in browsers, it would allow users to check out with a single button, which would request the API. Every step thereafter would be handled by native browser dialogs.

Making Authentication Easier

Mobile phones are, in most cases, personal devices that people don’t usually share with others. This opens up some interesting opportunities for authentication.

Magic Link

I use a password manager. I don’t know 99% of my passwords. They are all randomly generated. In order to log into a new Slack workspace, I must:

1. open my password manager,
2. enter my master password,
3. search for the workspace,
4. copy and paste the password into the Slack app.

It’s a tedious process, but Slack was smart enough to provide a better option.

Many users have they mail synchronized on their phone. Slack understood that. When you add a new Slack workspace in the app, you can either log in using the password or ask for the “magic link” option. If you opt for the latter, Slack sends a magic link to your mailbox. Open the mail, click on the big green button, and — ta-da! — you’re logged in.

Behind the scenes, this magic link contains an authentication token. The Slack app catches this and authenticates you without requiring the password.

Fingerprint For Smart Identification

I do almost all of my banking on my mobile device. And when it comes to logging into my bank accounts, there’s a world of difference between my French Societe General bank app and the German N26 app.

With Société Générale, I have a login string and a passphrase. I can ask the app to remember the login string, which is 10 random digits. I’m not able to remember that one; I use a password manager for it. I must still remember and enter the six-digit passphrase on a custom-built keypad. Of course, the numbers’ positions change every time I log in. Security — yeah, I know. Also, I must change this passphrase every three months. The last time I was forced to change the passphrase, I did what most people do: choose almost the same passphrase, because I don’t want to have to remember yet another six-digit number. And of course, I was damn sure I would remember it, so I did not enter it in my password manager. Rookie mistake. Two weeks later, I tried to log in. Of course, I forgot it. I made three failed attempts, and then my account was blocked. Fortunately, I only use this account for savings. In the app, you can ask for a new passcode. It took almost one week for the bank to send me a new six-digit passphrase by paper mail to my home address in Luxembourg. Yeah.

N26, on the other hand, uses my email address as the login string. I can remember that without a password manager. When I want to log in, I put my finger on the start button of my Xperia phone, and that’s it. In the background, my phone scans my fingerprint and authenticates me. If that does not work, I can fall back to a password.

Same device, two apps, two totally different experiences.

More and more apps on both Android and iOS now offer user the possibility to authenticate with a fingerprint. No more passwords — it’s an interesting and elegant solution.

Of course, people have expressed some security concerns about this. For the National Institute of Standards and Technology (NIST), biometrics is not considered secure enough. It advises combining biometrics with a second factor of authentication.

Fingerprint sensors can also be tricked — yes, like in spy movies. Did you hear about the plane that was forced to land because a woman learned of her husband’s infidelity after using his thumb to unlock his phone while he was sleeping?

Facial Recognition And Face ID

In 2018, Apple launched the iPhone X with the brand new face ID. Users can unlock their iPhone X using their face. Of course, some other Android phones and Windows tablets and computers had proposed this feature earlier. But when Apple launches something, it tends to become “a thing”. For the moment, this technology is mostly used as authentication to unlock phones and computer.

There are some pretty big challenges with facial-recognition technology. First, some algorithms can be fooled by a picture of the person, which is easily hackable. Another bigger concern is diversity. Facial-recognition algorithms tend to have difficulty recognizing people of color. For instance, a black researcher had to wear a white mask to test her own project. The researcher is Joy Buolamwini, and she gave a TED talk about the issue.

Some facial-recognition software is also used by some customs services to speed up border processing. It is used in New Zealand and will be used in Canada.

Most of us have seen enough science fiction to see the potential problems and consequences of systems that use facial recognition at scale. This kind of technology used outside of the private space of unlocking phones can get controversial and scary.

Google: One-Tap Sign-Up

If a user has a Google account, they can benefit from Google’s one-tap sign-up. When visiting a website and prompted to create an account in an inline dialog, the user doesn’t need to enter a password. Google provides a secure token-based password-less account, linked to the user’s Google account. When the user returns, they are automatically signed in. If they store their passwords in the Smart Lock, they get automatically signed in on other devices as well.

Note: This is an interesting password-less solution. Of course, by using it, users are linked to Google, which not everyone will feel comfortable with.

Conclusion

You can do a lot of really cool things when you start using mobile capabilities to help users fill in forms. We need a mobile-first mindset when building forms; otherwise, we’ll get stuck on the desktop capabilities we are familiar with.

Again, be careful with the device’s capabilities: always have a fallback solution in case a sensor fails or the user refuses access. Avoid making those capabilities the only options for those functions (unless you are building a map app that relies on geolocation).

This is the end of a series of two really long articles in which I’ve given you some general UX and usability advice and best practices. In the end, what matter are your form and your users. Some things described here might not even work specifically for your users — who knows? So, whatever you do, don’t take my (or Luke’s) word for it. Test it, with real users, on real devices. Measure it. And test again. Do some user research and usability testing. User experience is not only about best practices and magic recipes that you copy and paste. You need to adapt the recipe to make it work for you.

So, in short: Test it. Test it on real devices. Test it with real users.

(lf, ra, al, il)

Forms are one of the most basic primary interactions users will have with your websites (and mobile apps). They link people together and let them communicate. They let them comment on articles and explain to the author how they strongly disagree with what they’ve written. They let people chat directly on a dating app to meet “the one”. Whether for forums, product orders, online communities, account creation or online payment, forms are a big part of users’ online life.

It’s 2018, and we have more mobile than desktop users around the globe. Yet, we still treat those users as second-class citizens of the web. Everybody writes and speaks about user experience all the time. So, why, why, why are so many websites and products still doing it wrong. Why is their mobile user experience damaged for half of the world? Why is it still a pain, why is it still super-hard to book a flight and register an account in a mobile form today? Users expect better!

Recommended reading: World Wide Web, Not Wealthy Western Web

This is the first part of a series of two articles. In this one, I will sum up some essential best practices to improve your mobile forms, including scannability and readability. I will guide you through label and input placement, size and optimization. We will see how to choose the right form element to reduce interaction costs. Finally, you will learn how to prevent and deal with errors on mobile forms.

In the second part, I will take a closer look at specific mobile capabilities and HTML5 form elements, and we will go beyond classic form elements to make unique and enjoyable web applications and websites.

Note: While most of the code enhancement in this article are web-related (because I don’t know Swift or Java), the usability best practices hold true for mobile applications.

Form Design 101: Prioritizing Scannability And Readability

“A form is the name, value, pairs, in a structure for storing data on a computer barfed out as labels and input fields to human being.” This is a direct quote from Luke Wroblewski at a conference. Like him, I believe that most form usability issues come from this tendency to serve the structure of the database to users.

Strong Information Architecture

To build better forms, you first need to take a few steps away from your database’s structure. Try to understand how users want to fill in forms. This is where doing some usability testing and user research on your forms becomes handy. User mental models is a UX concept that can help you with that. Nielsen Norman Group describes it as “what the user believes about the system at hand”. Ask your tester to think aloud and tell you how they would fill the form. Which steps do they expect? What come first? What comes next? This will give you a better idea of how to structure your form in a more user-friendly way.

Visually grouping fields that belong together will also help users fill a form. In the code, use the fieldset tag to group them programmatically. It will also help screen readers understand the hierarchy.

If the form is long, don’t expose everything by default. Be smart about what you display. Use branching wisely to display only the fields that people need. In a checkout form, for example, don’t display all of the detailed fields for all of the shipment options. This will overwhelm the user. Display enough information to help them choose the right shipment option. Then, display only the details and fields related to that choice.

User attention spans get shorter with time: Ask for optional things at the end of the form. For instance, if your form is a customer-satisfaction survey, ask for demographic information at the end. Better yet, auto-fill them, if possible. Ask users only for what’s necessary.

Finally, plan ahead for localization: What will happen when your form gets translated? What will happen, say, for German? Will your design still work?

Label Placement And Input Optimization

Single-Column Layout Works Best

Due to the lack of space, you don’t get endless options for placing labels and fields on mobile screens:

• Present fields in a single-column layout. There’s no room on mobile for multiple columns. Multi-columns forms are not a great idea on desktop either anyway.
• In portrait mode, it’s better to place the label on top of the field so that users can see what’s in the field when they type.

• In landscape mode, the screen’s height is reduced. You might want to put labels on the left and inputs on the right. But test it to make sure it works.

For more on label placement, see Baymard Institute’s “Mobile Form Usability: Place Labels Above the Field”.

Labels Should Be Clear And Visible And Work Without Context

Remember that as soon as a field gets focus, the keyboard opens and will take at least one third of the screen’s area. On small mobile screens, users will also have to scroll to fill the form. This means that they will lose part of the context while filling the form. Plan accordingly:

• Your labels should be clear, visible text that can be read and understood without context. User should be able to complete each label and field pair as a separate task, even if they lose context.

• Avoid jargon, abbreviations and industry-specific language whenever you can.
• Be consistent. If you use “customer” in a label once, stick with that word. Avoid using “clients” later because it might confuse users.
• The font size should be big enough. Test your form on real devices as soon as possible, and adjust the size accordingly.
• All-caps text can be hard to read for some users. You might want to avoid using all-caps text on labels.
• The label copy should be short and scannable. If a field needs clarification, don’t put it in the label. Use a field description instead.

Input Size Best Practice

If possible, the size of the input element should match the size of the expected content. This will help users quickly fill in the form and understand what’s expected.

Using Masks To Avoid Splitting Inputs On Mobile

Don’t split inputs just for the sake of formatting. It’s especially annoying on mobile, where users can’t use the keyboard to navigate between fields. It requires extra taps just to go to the next field to fill in the form. You might be thinking, “But I’ll automagically put the focus on the next field when I get the required number of characters in that field”. That could work. But you will have taken control of the UI, which becomes unpredictable for the user. Also, it would be a pain if you automagically sent them to the next field and they needed to correct something in the last field. Finally, it’s more complicated to guess what’s mandatory with split inputs. So, let’s stop playing the “But what if” game and simply not split inputs.

I get it: You still want to be able to format your user’s data in small pieces to help them fill in your fields. And you are perfectly right about that. To do so, you could use masks. Instead of splitting an input, just put a mask on top of it, to visually help the user fill it. Here is a video example of what a mask would look like to help users fill in a credit-card field:

Masks help to prevent errors by guiding users to the correct format. Avoid gradually revealing them — show the format directly. Also, avoid putting fake values in the mask. Users might think it’s already filled. That’s why I’ve replaced the numbers with a little “X” in my demo. Find what works best for your type of input.

Finally, remember that some data can vary between countries, and sometimes the format changes, too (phone numbers, for example). Plan accordingly.

Efficient Fields Descriptions

Displaying efficient field descriptions can make the difference between a seamless and a painful form experience.

What Can Descriptions Be Used For?

Descriptions can help users in so many ways. Here are a few examples.

• What Exactly Are You Asking For?

  For whatever database-related reason, some shipment companies ask for “Address 1” and “Address 2” fields. This is highly confusing for users, but you might not have a choice here. Add description fields to help users understand what they need to put in each field.

  

  The same goes for acronyms and abbreviations. I know I said that you should avoid them, but sometimes you can’t. If you work on complex forms for a particular industry, for instance, they might have their own set of abbreviations. Any new user who needs to fill in the form might not be familiar (yet) with those abbreviations. Having a description available somewhere will help them.

• Why Do You This Information?
  Users might be reluctant to give you personal information if they don’t understand why you need it and what you will do with it. But sometimes you still need to ask for such information for legal reasons (like date of birth for a website that sells alcohol). Using field descriptions here will help users understand why this kind of information is needed.

  On e-commerce websites, you might want to ask for the user’s phone number in case the delivery person needs to contact them. This is a legitimate reason. So, again, use descriptions to explain to e-commerce users why you need their phone number.

  

“Where Do I Find the Information?”
If your users need to find certain information somewhere else in order to fill a form, tell them where to find it. I worked on a mobile app that lets user track their house. Users needed to pair the app to the monitoring device using a serial number. It’s not very easy to find this serial number on the device; it requires some instruction. We added a little ? button next to the serial number field. The button opens a modal that shows a picture and some indication to help the user understand where to find the serial number on the monitoring device. E-commerce websites do the same with promo codes: They give indicators that tell users where to find the codes.



• “How Should I Format The Information?”
  Some fields need a particular format. In this case, use descriptions to let users know the formatting rules up front. Here are a few examples:
  • Phone number: do I need to put the international dialing code (+xx) in front of the field?
  • Is there a maximum length? Twitter on mobile does a good job with that one.
  • When dealing with monetary amounts, is the format with comma (like 10,000) or a space (like 10 000)?
  • What format do you expect for dates? I’ll let you check on Wikipedia what a nightmare that is. The difference between DD MM YY and MM DD YY can cause a *lot* of trouble to users when booking online.

  Note that a lot of those formatting issues can be solved by input masks. We will come to that later in the article (or you can jump right in if you are impatient).

  

How To Display Descriptions

In the examples, above, we saw a few ways to display field descriptions. Here is a summary of what to do:

• Inline descriptions should be directly visible and displayed next to the field.
• If you need more in-depth descriptions with heavy content, you can use tooltips or modals. Tooltips are generally triggered on hover on desktop and on tap on mobile. The same goes for the modals: Open it when the user taps the help icon or “see more” link, for instance.

Be Careful With Placeholders

I get it: it’s tempting to remove fields on mobile to gain space and use placeholders instead. We’ve all gone down that road. But please don’t. The HML5 specification is clear about this: “The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry”. And here is why:

• The placeholder disappears when the user starts typing. The user must then rely on short-term memory to remember what they are supposed to put in the field. If they can’t, they will need to empty the field to see the indication.
• It’s hard for users to double-check fields before submitting because the fields no longer have any label indications.
• It’s hard to recover from errors once a field has been submitted because, again, there’s no label to help the user.

Even if you use placeholders with labels, you might still have some issues. It’s hard to tell the difference between a filled field and a field with a placeholder. I’m a UX designer who writes about mobile form design and even I got tricked last week by one of those. If it happens to me, it will happen to your users — trust me on that one. Finally, most placeholders have light-gray text, so you might have some contrast issues as well.

If you want to go deeper in this topic, there’s a great article named “Placeholder Attribute Is Not A Label, and also Joshua Winn and FeedbackGuru go into detail on why this is a bad idea. Nielsen Norman Group also wrote a piece on the topic, named “Placeholders in Form Fields Are Harmful.”

Placeholders are not mandatory in HTML5. From a usability point of view, you most certainly don’t need a placeholder in every field of your form. But with the massive adoption of Bootstrap and other frameworks, it looks like a lot of people just copy and paste components. Those components have placeholders, so I guess people feel kind of obligated to add something to the placeholder in the code? If your form’s placeholders look like “Please fill your — label — here”, you’re doing it wrong.

Labels inside fields could, nevertheless, work well for short forms in which fields are predictable. Login forms are a good candidate for this. But please don’t use the HTML5 placeholder to code this. Use a real label in the code and move it around with CSS and JavaScript.

Since the success of Android’s material design, a pattern has started to emerge: the floating label. This label is inside the field when the field is not filled in, so it takes a bit less vertical space on mobile. When users start interacting with the field, the label moves above the field.

This looks like an interesting way to gain some space, without running into the “placeholders in place of labels” issues cited above. Nevertheless, it does not solve the problem of users possibly mistaking a placeholder for filled-in content.

Interaction Cost Reduction For Successful Forms

Reducing the interaction cost (i.e. the number of taps, swipes, etc.) of users achieving their task will help you build a seamless form experience. There are different techniques to achieve that. Let’s look at a few of them in detail.

A Magic Study On The Internet Told Me To Reduce The Number Of Fields

More fields mean fewer conversions, right? You might have encountered the “we reduced our subscription form from 11 to 4 fields, and it drove up conversions by 160%” study. It’s a classic. And if you look at their contact form, it kind of makes sense. Why would users want to fill in 11 fields just to contact the company? You can’t ask such a big commitment of people who barely know you, right?

Start by asking only for useful information. Why do you need a person’s gender to create an account for them? Why do you have two lines for the address if your subscription form is for an online service?

Ask only for the information you need. And then ask for the information in context. If you have an e-commerce website, users might be more inclined to give you their address in the shipping section of the checkout process than when they register. It will make your e-commerce registration form so much easier to fill on mobile!

Also, don’t blindly trust every statistic and study you find on the Internet. Remember the 11-fields-to-4 study? Well another more recent study showed that by reducing fields from 9 to 6, conversions dropped by 14%. Shocking, isn’t it? Why? Well, they removed the most engaging fields. Long story short, they then went back to 9 fields, put the most important on the top, and voilà, conversions increased by 19.21%.

The bottom line is that while these studies are interesting, those websites are not your website. Don’t blindly trust the first study you find on the Internet.

So, what can you do? Test. Test. And test!

• Do some user testing to see the time to completion of your mobile form.
• Measure drop outs.
• Measure problems with certain fields.
• Measure the frustration associated with certain fields. How willing are users to give that information? How personal is that information?

Optimizing Touch Interactions

Making Controls Touch-Friendly

If your fields are too small or hard to reach, users will make errors and will need extra interactions to achieve their goals. Remember Fitt’s law? You could apply it to mobile design as well: Make your labels, fields and form controls easy to tap by increasing the touch target size. For labels on the web, a little more padding can increase the touchable area. Sometimes you will also need to add some margins between elements to avoid missed taps.

Also, don’t forget to link labels with their components by pairing for and ID values. That way, if the user misses a tap on the label, the corresponding field will still get focus.

Steven Hoober conducted some user research on touch areas. You’ll find a summary in “Designing for Touch”. Based on what he discovered, he built a little plastic ruler tool: the mobile touch template. The tool could help you make sure your touch areas are big enough for mobile forms and more generally for mobile design.

To learn more about designing for touch you can read the following:

• “Finger-Friendly Design: Ideal Mobile Touchscreen Target Sizes”
• “The Thumb Zone: Designing for Mobile Users”

Providing Feedback

Mobile users don’t have a mouse (no kidding), so they don’t get the “click” feedback that desktop users get when hitting a button. Mobile form users need clear feedback when interacting with elements:

• Provide a focus state for the form field that the user is interacting with.
• Provide visual feedback when the user interacts with a button.

I’m not a big fan of material design’s ripple effect on buttons. But I must admit that the animations on Android provide clear feedback when the user interacts with a button.

Honor The Next And Previous Button Order

Finally, honor the next and previous buttons on mobile keyboards. Users can use them to quickly navigate fields. The tabindex order should match the visual order of fields and components.

Avoid Dropdowns On Mobile If Possible

Dropdowns (the HTML select element) on the web require a lot of tabs and interactions. Therefore, as Luke Wroblewski said, they should be the UI of last resort. Many other UI components work better than dropdowns in many situations.

Segment controls and radio buttons are good alternatives to dropdowns if you have between two and four options. Why hide the options under a dropdown when you can show them all directly on one screen? Note that, like radio buttons, segment controls are mutually exclusive.

A country list is a good candidate for a component. A dropdown of over a hundred countries is an interaction nightmare on mobile. It’s OK if you are looking for Afghanistan (at the beginning of the list) or Zimbabwe (the end of the list). If you’re looking for Luxembourg, you will end up in a game of scrolling to reach the middle of the list, going too far to the letter M, trying to come back to L, and so on.

Long dropdowns can be replaced by predictive text input fields. When the user starts typing L, the interface would propose nine countries. If they add a U — voilà! — Luxembourg it is. Four interactions instead of two, versus as many as six or seven scrolling interactions with the dropdown.

If you need users to pick a date, forget about splitting it into a day, month and year dropdown like people are used to doing on paper forms. Replace multiple date dropdowns with a date picker. The HTML5 input type=date works in most cases. But you might have some special needs and end up building your own date picker in JavaScript, especially if you are in the booking business (hotels, cars, flights).

In his article “Mobile DropDowns Revisited”, Klaus Schaefers explains how using a date-picker for arrival and departure dates made interactions 60% faster.

Let’s stick with the booking business. Suppose the user needs to add multiple travellers to their itinerary. You can **replace the dropdown *with a* stepper** to select the number of passengers. A stepper is a control that allows the user to increase and decrease values simply by tapping on + and - buttons. That tends to be faster when fewer than six persons have to be added. It’s also more intuitive. Below is an example of a stepper used in the Android-native Airbnb app to select guests, and on the mobile-optimized website of Kayak to add passengers.

A final alternative to dropdowns is the list view. The options would be listed in a specific subview, as radio buttons, for instance. This is mostly how Android settings work.

Getting Smart With Auto-Completion

If you want to decrease the interaction cost of your form, be smart. Don’t ask for information that you can auto-detect or guess based on other information users have given you. Autocomplete and prefill as much as you can.

Places and Addresses

If the user searches for a place or needs to enter an address, you can offer auto-completion to help them. As they type, an API would fill in the rest of the address for them. This also reduces errors.

You could use:

• Google Places API
• Algolia Places, which is based on OpenStreetMap

In France and many other countries, you can guess the city based on the area code. So, if a French user enters an area code, you could automatically auto-complete or at least propose the city. My country, Luxembourg, is small (don’t make fun of me). My area code is linked to my street. So, if I enter my area code, the form should even be able to suggest my street.

Credit Cards

Another area where auto-detection is easy is credit cards. You don’t need to ask the user what type of credit card they have. You can auto-detect this based on the initial numbers they enter. There’s even a library that can do the job for you.

Using HTML5 Autocompletion (Autofill)

The HTML autocomplete attribute can prefill fields based on the user’s earlier inputs. This attribute has an on and off state. Some smart people have started working on a specification to make this more powerful and to extend the autocomplete attribute for form fields. The WHATWG also has an interesting list.

Chrome and other mobile browsers already support some of the extended values for credit cards and names. This means that users can prefill forms with their name and credit card data that they use on other websites.

In short, when you must choose between different systems, count the number of interactions each is going to require.

Mistakes Happen: Handling Errors In Mobile Forms

The last step on our journey towards better mobile forms is handling errors and mistakes. We can try to reduce mistakes to ease the user’s cognitive load. We can also help them recover from errors, because no matter how great your form design is, mistakes happen.

Avoiding Errors While Filling The Forms

“Prevention is better than a cure,” my mother used to say. That’s also true of form design: Preventing errors will improve your mobile form’s experience.

Explicit Format Limitation

“Be conservative in what you do. Be liberal in what you accept from others.” This robustness principle can be applied to form fields as well. If possible, let the user enter data in any format.

If you think you need to limit what a user can enter in the field, start by asking yourself “why”. In the user experience field, we have a technique called “the three whys”. If the answer is “because blah blah database”, maybe it’s time to change things. For instance, why do you refuse special characters like é, à and ö in the user name field? I wrote an article explaining how rude forms are to me when I try to enter “Stéphanie” as a user name. I’m still trying to figure out a good reason for that (apart from database reasons).

If you have a good reason to require a specific format from users, state this up front. You can use HTML5 placeholders to give users a hint about what the data should look like, but again, be careful with those. You could also use all of the field description techniques explained at the beginning of this article. Finally, input masks can guide users towards the right format.

Marking Mandatory Fields (And Optional Ones)

Don’t wait for users to submit a half-completed form to tell them about required fields. If a field is mandatory, users should know about it. Marking mandatory fields with an asterix (*) and a legend has become a standard pattern for forms. The good part is that it does not take much space. The problem is that it has no semantic value, so it can cause accessibility issues if poorly coded and if you rely on people’s habits with form interaction.

You could instead explicitly mark both mandatory and optional fields with the words “required” (or “mandatory”) and “optional”. Both Baymard Institute and Luke Wroblewski agree on that. This avoids ambiguity with long forms on mobile, such as when using a scroller, proceeding with something else, then coming back and not remembering if mandatory fields were marked with an asterisk or something else.

Eventually, the decision on how to mark those fields will depend on the design and length of the field and on the context. The best way to know whether you’ve made the right decision is, again, to test the form.

Sensible Defaults

Be careful about default selected options in forms. When I applied for my previous job, there was an information form. The marital status was optional. They made the first element in the dropdown, “divorced”, the default field. So, I could either not answer (because it was an optional field) and let the system believe that I was divorced, or correct this and disclose my actual marital status even if I did not want to.

Also, be careful about gender. Again, have an option for people who don’t want to disclose it; make clear why you’re asking for their gender; better yet, ask for pronouns, or don’t ask if you don’t really need to. If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don’t auto-check the first choice, otherwise people won’t be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you’re in a Dr. Who episode, you’re not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can’t select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I’ve written about password-less authentication, but you can’t always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won’t get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don’t let people guess. Tell users your password criteria up front.

  A lot of websites now show you a gauge for password strength telling you in real time what is missing. This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don’t tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password’s length to 12 characters, but they never tell users how many characters are left. Sure, let’s add “counting the dots” to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven’t met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• When Logging In
  In a login form, a mask/unmask password option would tremendously improve the user experience.
  

  
  A button to show and hide the password in a form.

  Amazon has an interesting history of iterating on passwords in its login form. It used to have a version in which you could not see the password. The next iteration allowed users to reveal it. Then, the password was revealed by default, and you could hide it. This is what is looked like in 2015:

  

  Amazon tested the last version, and 60% people got suspicious. So, they replaced the “hide password” unchecked checkbox with a “show password” checked box. This would show the password in smaller characters, under the field, while the user typed. This is what it looks like at the time of writing this article:

  

  As you can see, there’s always room for improvement.

Inline Validation

If you are familiar with usability principles, you might know the Gestalt law of proximity. On mobile, avoid the summary of errors at the top of the page, with no contextual information, after the user has tapped the submit button.

Instead, error messages should be located close to the errors themselves.

Real-Time Validation

You also don’t need to wait until users hit the submit button. You can validate fields and display feedback while the user is filling them in.

A few tips:

• As mentioned earlier, password fields would benefit from real-time validation and feedback on each keystroke.
• You might also want to validate user names in real time when accounts are being created, to make sure they’re available. Twitter does a good job of that.
• Don’t validate every keystroke. Wait until the user has finished typing. (Use JavaScript blur for web forms, or just wait a few seconds to detect inactivity.)

Note: *Mihael Konjević has written a nice article on “Inline Validation in Forms: Designing the Experience.” He explains the concept of “reward early, punish late.”*

“If the user is entering the data in the field that was in a valid state, perform the validation after the data entry.”

“If the user is entering the data in the field that was in an invalid state, perform the validation during the data entry.”

Color Matters

I’m not saying that color matters just because of my current ginger, pink and purple hair color. Color really matters in form design.

There are some conventions on the web that you don’t want to break. Non-colorblind users know that red is for errors, yellow is for warnings, and green is almost always for confirmation or success. It’s best to stick with these three colors. Red can make people anxious, though. The user might think they’ve made a really serious mistake. Using orange or yellow for error messages could cause less panic. The problem with yellow and orange is that it’s hard to find colorblind-friendly hues of them.

Speaking of colorblindness: Color should not be the only way to convey an error message. This is an accessibility criterion.

In the example below on the left, the field with an error is in orange, and the field that has been corrected has turned green. I used a colorblind testing tool to take the screenshot in the middle: You can’t distinguish between the default gray border and the green one anymore. Adding some icons in the last screenshot ensures that the error messages are conveyed to colorblind people.

Recovering From Errors: Writing User-Friendly Error Messages

At this point, we’ve done everything we can to help users fill our forms and avoid errors. But sometimes, despite our best effort, mistakes happen. It’s time to figure out how to help users recover from those mistakes.

First, remember: Don’t hijack control of the system. If a problem isn’t critical, the user should be able to continue interacting with as much of the rest of the interface as possible. Avoid those JavaScript alert error message and modals that blocks users whenever possible. Also, if your form needs some permission, request it in the flow of use. If permission is not granted, do not consider this an error because it is not. Be careful about the copy you use here.

You’re Not A Robot, And Neither Are Your Users

Robots are cool, I know. But you’re not a robot, and neither are your users. Yet so many error messages are still so poorly written. Here are a few tips when it comes to human-friendly error messages:

• Never show a raw error message, like “An error of type 2393 has occurred. Server could not complete the operation.” Instead, explain what happened in human language and why it happened.
• Never show a dead-end error message, like “An error has occurred.” Instead suggest ways to recover from the error. Write actionable copy.
• Never show a vague error message, like “A server with the specified hostname could not be found”, with a “Try again” button. Instead, make error messages informative and consistent. Please don’t sound like a robot.
• Don’t assume that people know the context of a message. Your users are not tech-savvy geeks. Instead, explain to them in plain language, without technical jargon, how to recover from this error.

Beware The Language You Use In Messages

Whatever you write, avoid making people feel stupid about a mistake. If possible, leave out negative words; they tend to scare people and make them even more anxious. Use a courteous, positive, affirming tone instead.

Don’t blame users for mistakes; blame the system instead. The system won’t hold a grudge, I promise. Shift the user’s attention to how the system could not process the action, and explain to them how to find a solution.

A little trick is to read your own message out loud. It will help you hear whether it works or is too harsh or too casual, etc.

You could also get creative with error messages and incorporate imagery and humour to make them less threatening. This will really depend on your brand’s identity and tone, though.

To help you write better error message, I suggest you read the following:

• “A 6-Point Microcopy Checklist For Product Teams Without UX Writers”
• “The Art of the Error Message: Writing Clear, Helpful Copy For When Things Go Wrong”

Time To Submit The Form

The user has filled in the form, there are no more errors, and everything looks good. Finally, it’s time to submit the form!

The first rule is, don’t mask the submit button. Seriously! I wonder what twisted mind came up with this idea, but I’ve seen it in some forms. The submit button would be displayed only once all required fields were filled in without any errors. It’s disturbing for the user to wonder whether something is wrong or the form’s button has not loaded or the website is broken and so on.

If you don’t want users to be able to hit the submit button if there’s missing mandatory fields or there are validation errors, use the disabled HTML attribute on the submit input. You will need to re-enable the button using JavaScript once the form is valid and ready for submission.

If you have a primary and secondary call to action, use color, size and styling to show the hierarchy.

If are wondering whether the confirmation button should come before or after the cancellation button, so am I (and a lot of other people). If you are building a native app, stick to the OS guidelines. It’s become particularly fun since Android changed the button positions in its fourth version. On the web, it’s more complicated because there are no real guidelines. Regardless of the OS, here are some general guidelines for mobile-optimized submit buttons:

• Give the call to action descriptive, actionable verbs.
• Provide visual feedback when the user taps it.
• If you have two buttons, make the primary action stand out.
• Unless you’re working on a very specific back-office enterprise form (in which case, you’ll have a lot of challenges optimizing for mobile), avoid a reset button. Users might confuse it with the submit button and will lose all of their data by accident.

Conclusion

In this first part, I’ve discussed a lot of little techniques to take your form to the next level and help users fill it in. Some of these general guidelines and mobile best practices might not work 100% of the time — that’s the catch with best practices. So, always test your forms on real users and real devices, and adapt the guidelines to your users’ specific needs and experience.

Also, do some regression and automated functional testing — again, on real devices. Chrome’s mobile emulator won’t be enough to test touch-optimized forms. I say this because I had launched an e-commerce website with a search form that didn’t work on mobile. We only did automated testing using an emulator. Here is what happened. The search form was hidden under a search icon. You could tap on the button, which opened a box with the search field. It worked by emulating a mouse hover as a touch event. We tested tapping on the button, and it opened the box. Nobody tried to launch a search. So, nobody (not even the client) saw that the search field disappeared as soon as users tried to interact with it. What happened? When the input element got focus, the button lost the hover state, so it closed the box with the field. Automated testing was not able to catch this because the input was not losing focus. So, we launched an e-commerce website without search functionality on mobile. Not a super experience.

In the second part of this series, we will see more advanced mobile-specific techniques. We will see how to use cool HTML5 features to format fields and how to use mobile capabilities to take the mobile user experience to the next level.

(lf, ra, al, il)