Multiple vs single field capture for phone number form input

Question

Working on a form dealing with phone numbers, I've seen two methods to capture user input .

In past practices example 2 (image below) has proved effective in controlling phone number lengths on forms.

However with responsive in mind it would seem example 1 is considered a more popular pattern on forms. I've researched both patterns with the findings below.

Example 1

Pros

• 1 input = less taps on mobile device
• 1 input = less coding

Cons

• could be difficult to control phone number format (1-555-555-5555, +22444455555, and etc)

Example 2

Pros

• easier to control phone format
• reduced user error

Cons

• 3 inputs = more taps on mobile device
• more inputs = more coding

Both inputs have pros and cons and I'm not such which method would provide the best user experience for responsive environments. Can anyone share some insight or provide a better way to use phone number inputs?

Answer 1

When a person dials an actual phone number with their phone, do they type 1-555-555-555 or do they type 15555555555?

The only reason for forcing a fixed format is because your back-end can't determine the format it needs. Which is an implementation problem and you're forcing the lack of technical nous onto the end user. That's like saying "we aren't capable of parsing a phonenumber into a format that we want, so we're going to ask you to type in it the format we want".

Just like with credit card numbers - we are mostly no longer expected to type 1111-1111-1111-1111 in 4 separate fields and pick visa from a dropdown because there is already enough information in the credit card string itself to know the type of card, and we can easily split a single number 1111111111111111 into 4 'chunks' if that's how we need it in the back end.

You should try to set up some kind of intelligence in the logic itself. For instance if you know the country the person is from then you will know the format of the phone number, and if you know it's a mobile phone and not a landline then that's another clue for you to use. Then just give the user a single field and let them type in a number however they like.

Heck, some people will want to use a single field and type +44 (020) 444 4444 in there themselves. But you should be able to strip out all the unnecessary characters and spaces programatically and store it as a single field.

Let the programming do the grunt work, not the user.

Answer 2

A single input field is always easiest for the user — whether it's for a phone number, first and last name, social security number, or any other value that you may think of as being divided into "parts". Luke Wroblewski has written many articles about this with plenty of data to back it up.

Design your page for the user, not the database. If you absolutely need to break up a phone number into separate pieces (international prefix, area code, exchange, post code) before storing it, then make an attempt to do so but verify it with the user.

For example, if the user types in 5551234567 you could unobtrusively prompt them to confirm that (555) 123-4567 is correct. Be sure to give them a way to fix it along with a way to clarify why your guess was wrong (e.g. it may not be a U.S. phone number, so let them specify their country).

Be liberal with what you accept — allow the user to use a plus sign for an international prefix (and use that in your algorithm!) as well as any other punctuation they feel is necessary. Everyone has their own style of formatting.

Answer 3

I would suggest you keep one input field, but use a mask for the text:

-You can use Placeholder attribute from HTML5 (If you are working in a web App) for showing a example number.

Answer 4

My guiding principles for this are as follows, vis-à-vis users:

1. Show them what you expect
2. Take whatever they give you
3. Show them what you’re taking

The best way to accomplish all three with HTML5 and jQuery is to borrow this plugin.

I’ve added type="tel" mainly to give mobile users a keypad instead of a keyboard, and placeholder="(999) 999-9999" as a better way of displaying the expected format. When you leave out placeholder, or when focus is placed in this field, the user will see this:

At this point, they can type or paste in whatever numbers they want and see them nicely filled in. If they try to type or paste in any other characters, they simply get ignored. The end result is a nice looking number that should be friendly and recognizable to the user and the system.

If you want to cover international possibilities, ask for the user’s country first and then use form logic to display a field you’ve customized for that country (adjust regular expressions/definitions in jQuery).

Answer 5

From my testing, I have learned that you NEVER, EVER, use a single empty field to represent a phone number (or credit card, or any other multi-part field). I've watched users often make mistakes when typing one long number, then not being able to find the mistake they made. With a multi-part field, they pinpointed the mistake easier ("oh, the first number of the 2nd field is wrong!"). Users are also simply used to typing in multi-part numbers as... multi-part numbers. Your phone service provider doesn't tell you your number is 10982859205, they tell you your number is 1 (098) 285-9205. When a person tells their number to another person, they don't speak it all as one number; they break it up just as it is written. When you read a number off a credit card, it's not written as one giant number; it's written as chunks of 4 numbers. Users are used to it, and if you follow JonW's answer, it WILL test badly.

There are already lots of answers that discuss input masks, which is probably the best/easiest solution, but I have also seen well-coded multi-field solutions test well. By "well-coded", I mean fields which will correctly copy and paste values, automatically jump to the next field when typing (removing the need to tap on mobile devices), and automatically reverse-jump when the user hits backspace. Multi-field solutions work, but your point about "more inputs = more coding" is right on the money.

Answer 6

Go with Example 1. One field for the phone number.

Do some quick client side regex on the number the user entered, to account for any egregious errors to save an unecessary call to your server for 800 digit entries or garbled text.

Ultimately, you are validating the web form data on the server and sanitizing it before dropping it into your database.

Answer 7

Since you've specified that you will only be using this form for a US audience, I don't really see a problem with guiding the user towards using a particular format. However, using multiple text fields might not be the best way to go about that. Let's study some existing websites as examples:

Papa John's Pizza uses multiple fields for their account creation. As the user types, it automatically switches to the next field which is helpful because the user doesn't have to click or tab multiple times, but it can be confusing if the user isn't expecting it. If the user mistypes, it's not easy to go back to another section and correct it.

Jimmy John's uses a single field with validation to ensure the user types in a real phone number. This ensures that the user inputs the desired format, but the coding to make this work can be difficult. Plus, if an error occurs, it may be difficult for the user to find it.

Pizza Hut uses a single field with a text mask. This allows a user to input all the numbers at once while specifying the format. It prevents the user from typing too much or too little into the field and it's easy to figure out where errors occurred. I like it. (It's worth noting that Domino's uses the same type of input field, though they likely just copied each other.)

Answer 8

I'd opt for option 1 due to the ease of use from purely a responsive view point and like said earlier, if you plan to use the area code etc to some how collate your data and categorizes phone numbers.

The last thing you would want is that number in separate inputs stacking on mobile or device although it wouldn't be a complete disaster again the con of having too many clicks would come into play with less fluidity for the end user...

Again accounting for parentheses and plus signs should also figure, lets not discriminate :)

Answer 9

Option 1. + input mask

An input mask (this type, not a password field) allows the user to type in their number in one go (as if they were dialing for example), yet have the number formatted before it is submitted.
This reduces the physical effort (navigating to the next input) and the mental effort (splitting up the number and context switching to the task of navigating to the next input - something outside the usual pattern of dialing a phone; the general use case) See this answer

It is flexible in that the spaces in a format such as 01234 456 789 can be typed, or left out by the user.

If it is required that the international extension is also input, either:

• Make it clear on the form, so the user will input the correct number
  (e.g. +nn nnnn nnn nnn - have the + already there in the input mask
  or even +nn (n)nnnn nnn nnn)
• Have a seperate county - code field, so they can still input their 'local' number. As something that is usually not included in their number, having it as a seperate entity is not user-unfriendly.

Answer 10

One form field, such as the one presented in option one, is a better experience. You could make the input flexible by allowing the user to enter their phone number in whatever format they wish and using logic to clean it up for the database. For example, a user could enter 123-456-7890, (123) 456-7890, 123.456.7890, etc and they would all be valid.