Friendly format for phone numbers
Currently, on my website, users are required to input their phone number in a very specific format (555-555-5555). If you forget the dashes it breaks. Does anyone have a good suggestion for how to be more flexible with allowing users to input in any way they choose, but still allowing the system to validate if it is a real phone number? How are phone extensions handled?
**Edit: 18 November 2010** Found one more good article today http://formulate.com.au/research/mobile-phone-numbers/ -------------------------------------------------------- Keep in mind the ability of iPhone also http://hjacob.com/blog/2009/07/making-a-phone-number-clickable-for-iphone-users/
Also don't forget that some of us dont have 10 digit phone numbers. Here in little ol' New Zealand landlines only have 9 digits :)
* Currently on my website users are required to input their phone number in a very specific format (555-555-5555). Your site cannot cope with UK numbers such as (020) 3000 9000, (01750) 82000 or (016977) 3000. Is this a US/Canada only site?
+1. It gets extra interesting when you have users in different countries typing numbers without the country codes. To dial any of those numbers from anywhere on the globe, I found it impossible to figure out which country code to use.
possible duplicate of Multiple vs single field capture for phone number form input
Make sure to support auto-complete on iOS and Android... its so frustrating when a mobile OS fails to recognize a phone field or recognizes it, but for some reason can’t fill it in
Here’s a web component from the Polymer team: https://www.webcomponents.org/element/@polymer/gold-phone-input. iOS doesn’t seem to auto fill it though... but they’re accepting merge requests
Ideally you'd let them type in the phone number in any format and you'd have client and server side logic that could parse it out.
Barring that--if you're just looking for a quick fix--look at using field masking. If you're using jQuery, this is a decent one:
I'd steer away from using anything propriatary and instead refer to something standardised, like E.123.
Because it's a recognised international standard, I would expect to find code examples - or even complete libraries - that you can plug into your validation process.
1. Phone numbers are ultimately just a string of numeric digits
You would want to use the raw input from the user everywhere in the UI and then also store the converted string of numbers for everything computery to use.
2. Let the user remember phone numbers any way they want
Some people use letters to help them remember their number easier. Telling a user they can't input a letter, dash, hyphen, parenthesis, is frustrating. There really is no need to require a user to enter their number a certain way.
Don't try and change what the user inputs after the fact either because you really aren't helping them. If they only type numbers and nothing else then don't add dashes. If they type parenthesis, dashes or dots then leave those in place as well and transparently ignore them.
The best approach for user experience is to let the user type in the phone number using the format they are most comfortable with. Don't break it into separate fields, don't force a mask, let it be typed freeform. Then, after the user has finished entering the field (by leaving the field for submitting the data), format the number into a standard format for your purposes.
The reason this approach is better for the user experience is that it allows the user's mental model to remain unchanged and allows them to say, "Don't Make Me Think." Masking and separate fields force a mental model of phone numbers onto users and requires more thinking.
sorry for commenting on something this old, but the above code-library breaks on German numbers.
@DKOATED In my experience, it works fine with German numbers, but a bug may have been recently introduced. You should work with the libphonenumber team to get that figured out. https://code.google.com/p/libphonenumber/issues/list
nevermind. not a big fan of code.google and have my own working libs in place ... may add these to Github whenever I get to it...
Re-formatting user input on blur event is actually an anti-pattern, because reformatting could be destructive (if input was not correctly parsed and recognized) and user could switch her attention to the next field without realizing that her previous input was broken by the incorrect reformatting. Also, the previous input field could be entirely pushed out of the current viewport, so the user won't be even able to see how the re-formatting happens.
The best solution I've found (5 years after the question was asked) is "intl-tel-input". It uses Google's libphonenumber library for validation.
"intl-tel-input" is a jQuery plugin for "for entering and validating international telephone numbers. It adds a flag dropdown to any input, automatically detects the user's country, displays a relevant placeholder and auto formats the number as they type."
You should just use a plain old text box and use your back-end code to parse it if you really need to. I personally don't see a need to require any specific format whatsoever. If a user wants to be able to just enter the 10 digits of their phone number really quickly, then let them.
You also need to remember that there isn't just one format in the world to deal with, and you may also need to deal with weird cases like extensions.
+1 Recently dealt with this issue in some software of ours and people are loving it when done this way.
The most friendly format is a format that will accept everything and doesn't do any validation.
We are talking about phone numbers here, not credit card information. How many people are mistyping their phone number? Unless this is a site for the International Dyslexic Association, probably no one.
The only thing you can validate is a format. You still don't know if the number is correct.
*"The only thing you can validate is a format. You still don't know if the number is correct."* very good point. Just like with an address - you can validate the format all you like but it isn't *truly* valid until the parcel lands on the doorstep.
GDS have some advice:
"Only collect telephone numbers from people if you genuinely need them. Not everyone has or can use a telephone, so make sure you give users a choice about how they can be contacted.
Allow different formats
Users should be allowed to enter telephone numbers in whatever format is familiar to them. You should allow for additional spaces, hyphens, brackets and dashes, and be able to accommodate country and area codes.
Validate telephone numbers
You should validate telephone numbers so you can let users know if they have entered one incorrectly. Google’s libphonenumber library can validate telephone numbers from most countries.
If the telephone number is not in the correct format and there is no example
Say ‘Enter a telephone number, like 01632 960 001, 07700 900 982 or +44 0808 157 0192’.
If the telephone number is not in the correct format and there is an example
Say ‘Enter a telephone number in the correct format’.
Make it clear what type of telephone number you need
Use the form label or hint text to tell users if you specifically need a UK, international or mobile telephone number.
If you wish to include an example telephone number (in hint text for example), Ofcom maintains a list of numbers that are reserved for use in media. These are:
UK non-geographic: 01632 960000 to 960999 UK London: 020 7946 0000 to 7946 0999 UK mobile: 07700 900000 to 900999 Explain why you need a telephone number
Tell users why you might contact them and when.
Don’t display telephone numbers as links on devices that can’t make calls
It’s possible to mark up telephone numbers as links, like this:
020 7947 6330 However, doing this will style telephone numbers as links, which is confusing on devices that don’t support telephone calls, like most desktop machines.
It’s also not necessary - most modern mobile browsers automatically detect telephone numbers and display them as links anyway.
If you do need to mark up your telephone number as links, for example, to support a device that cannot automatically detect them, make sure they don’t display as links on devices that cannot make calls.
Write telephone numbers in the GOV.UK style
Avoid input masking
Avoid input masking because it makes it harder for users to:
type a number in their preferred way transcribe a number from another place and check that they’ve got it right Avoid reformatting telephone numbers
The GOV.UK Notify team have observed some users becoming confused when presented with a reformatted version of a telephone number that they provided, for example, with the +44 country code added.
Research on this pattern
More research is needed on the best way to handle:
international numbers extensions SMS shortcodes
Let users enter numbers as well as '-' and spaces, so you can enter the number the way they prefer. As long they enter sufficient numbers, it can be a valid phone number. You can use client-side validation to count the numbers and show a message if there are too few. You will never be able to verify if the phone number is really activated, so typing errors are unavoidable.
The server can parse the other characters out and just store the numbers in the database (and parse it back to your preferred formatting for display purposes).
Beside adding dashes, you will need to deal with the position of the cursor, especially in case of deletion.
This AMD module does exactly that: https://github.com/whenyoubelieve2014/us-telephone-input