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?
7
-
Edit: 18 November 2010 Found one more good article today formulate.com.au/research/mobile-phone-numbers -------------------------------------------------------- Keep in mind the ability of iPhone also hjacob.com/blog/2009/07/…– Jitendra VyasNov 4, 2010 at 4:27
-
1Also don't forget that some of us dont have 10 digit phone numbers. Here in little ol' New Zealand landlines only have 9 digits :)– Nathan-WNov 6, 2010 at 4:25
-
3* 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?– user16193Jul 6, 2012 at 9:30
-
1+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.– JOGJul 6, 2012 at 14:37
-
possible duplicate of Multiple vs single field capture for phone number form input– DaveAlgerFeb 23, 2015 at 19:19
|
Show 2 more comments
12 Answers
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:
Archived - http://digitalbush.com/projects/masked-input-plugin/#demo
-
1I would also recommend this more fully featured jQuery plugin, which lets the user type whatever they want, but then does comprehensive validation using Google's libphonenumber: github.com/jackocnr/intl-tel-input– jackocnrFeb 18, 2016 at 20:44
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.
-
This is a great answer for how to display the number. Might be worth adding some notes about number entry. Nov 2, 2018 at 6:58
There are simply too many rules to validate a phone number input by a user.
1. Phone numbers are ultimately just a string of numeric digits
Here is one example showing how to convert anything a user inputs as a list 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.
answered Feb 23, 2015 at 20:47
-
+1 This enforces better UX! We developers often burden users for making our job easier!– SisirApr 25, 2016 at 12:45
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.
Since you are talking about a Web site, you can do the format on the blur event using the Google libphonenumber http://code.google.com/p/libphonenumber/ project. This tool handles international phone numbers and a wide variety of formats. Here is an example in JavaScript: http://libphonenumber.googlecode.com/svn/trunk/javascript/i18n/phonenumbers/demo.html
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.– David K.Mar 5, 2013 at 12:09
-
@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. code.google.com/p/libphonenumber/issues/list– mawcscoMar 5, 2013 at 15:05
-
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...– David K.Mar 5, 2013 at 15:21
-
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. Nov 2, 2018 at 10:16
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."
https://github.com/jackocnr/intl-tel-input
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.
answered Nov 5, 2010 at 13:43
-
1+1 Recently dealt with this issue in some software of ours and people are loving it when done this way. Jul 15, 2011 at 19:18
-
1I had the argument presented to me that the person could more easily detect a typo or a missing digit if the field is formatted. As you point out, there isn't one format and making this work for everything could be quite difficult. Jun 6, 2014 at 18:55
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.
-
2"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.– JonW ♦Jul 6, 2012 at 15:30
-
-
@mawcsco: "but still allowing the system to validate if it is a real phone number"– JeroenJul 9, 2012 at 10:42
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.
Error messages
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).
The simplest UI approach is to break the number format into three limited text boxes.
Alternatively use a RegEx to parse the entered phone number into what ever format the system needs to accept a phone number.
i.e. accepting - 0-9 +()-
answered Nov 3, 2010 at 21:53
-
4Ugh, Matt, that is the absolute worst. As a user, every time I see a phone number field split up (or Social Security Number, or anything else like that), I just want to go and slap the designer of that site.– Charles BoyungNov 5, 2010 at 13:40
-
I respectivly disagree. Given that Rusty asked for a solution while implying the constraints of the current system. This solution would fix his UI/Usability problem. As he also asked for a more felxible approach to ensure the information is accepted in any format That's also why i suggest a the RegEx Fix. I didn't suggest jQuery or any other framework becayse i didn't know what platform.– Matt GoddardNov 5, 2010 at 16:25
-
1That solution would not provide for a more flexible solution, which is what his entire question was. Yes, it would prevent the error of different formats, but it would cause more problems than it solves. Like he mentioned, how would you handle phone extensions. Three text boxes absolutely does not allow for that. And it may solve the immediate usability issue of errors if you enter an invalid format, but then it just exposes the new usability issue of having a crappy interface that annoys people that have to use it.– Charles BoyungNov 5, 2010 at 17:41
-
You're right to break the phone number into multiple text boxes wouldn't provide a more flexible solution. Defensive design is always the best approach. If for some reason this isn't achievable then it is an entirely legitimate approach to break phone number, credit card number etc into multiple input controls, Although not desirable. When i've conducted users test using these different approaches i've never had a participant say "I wish there was a single field there for me to enter xyz". When the task is complete. i.e. the form flows no one gives a crap.– Matt GoddardNov 5, 2010 at 21:19
-
1Matt, I've done tests where users explicitly did say that they wished the phone number was a single field (never tried it with credit card numbers because that would be a nightmare and I don't think I've ever seen CC# split). Also, even though I haven't been the subject in any usability test, I AM still a user as well, so wouldn't the fact that I hate that be at least some evidence that it isn't desirable?– Charles BoyungNov 18, 2010 at 15:31
Another option is what I did on one of my sites:
- Free text input field to allow the user to add the phone number as he likes.
- I then take the number, reformat the number as I need it and display it back to the user in several ways to ask for confirmation.
Example:
User enters this into the field: 055 (0)555-555 55555
I display radio boxes underneath the form to ask for confirmation:
How do you call your number from another country?
+55-55555555555 (+55 is my country code)
+55-055555555555 (+55 is my country code)
+1-55-55555555555 (+1 is my country code)
+1-055-055555555555 (+1 is my country code)
etc.
That way I can confirm the user's phone number and know exactly how to deal with it, since I need to know the user's country code...
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
