While fixing a validation highlighting issue for 4.0, we spent some time cleaning-up that control, and along the way thought about how to improve it. We thought about the following:
- Should we use two fields as is the case now, or a single field?
- What characters should the user be allowed to enter?
- How do you store and format the value?
Let's consider the number of fields. When using two fields, you have to think about what happens after the user has typed the area code. With a naive implementation, you have to tab (or click) to get to the other field. In the worst case scenario, if the user enters the value head down, she might end up typing too many characters in the first field, as shown here. You could configure the field to prevent entering more than 3 characters, but then the user might type the whole number and realize most of the typing got lost, so that's not a great solution either.
Or, you can could automatically jump from the first field to the second one. This is tricky too, and there are lots of botched implementations of that idea out there. For example, if the jump occurs after the user has typed the 3rd number and wants to edit the area code, she has to shift-tab or click. And it is probably safe to assume that some users know "tab", but fewer know "shift-tab"! You could be smarter and jump to the second field only when the user types the 4th character. That would be much better, but that still requires shift-tab or a click to navigate to the area code.
So it's hard to get the two-field solution right. This is not to say that there is no benefit to it. For example it makes it very clear that you need an area code. But you can do this using a placeholder in a single field, so for now we have decided to revise this component and to use a single field with a placeholder to indicate the format:
Now what values should the user be allowed to enter? You find countless examples online of indications along the lines of "Please enter the phone number (without dashes or spaces)". Uh, no: if the computer can do the work, the user shouldn't! So don't tell the user that some characters should not be entered, when it's likely that the user will enter them. For a phone number, you do want to allow at least spaces, dashes, parentheses, slashes, and periods. There might be more but these are the most common. Let the user go wild and format the number as she is used to!
Finally, when the user leaves the field, you could do two things: leave the value as is, or format it. We think it's better to format it: first, your form data will look consistent this way. Second, if formatting is separate, you can store into the format a canonical value. For example, we store a plain string of 10 digits. So we do this:
- remove known extra characters
- if the resulting string contains only digits, store them and reformat the value
- otherwise leave the string alone so the user can fix it
Let us know what you think: is this a phone number field that you can see yourself use? Did we miss anything? What other formats would you like to see (international phone number, other countries)?
I think it largely depends on what you do with the data. Will the number tie into a back end and receive SMS messages or be used in some critical way? If so, you better be sure it has exactly the right data. Is it being stored "just in case" someone needs to be called?ReplyDelete
If so, the easiest thing is to let people enter in whatever they want and store it away. Do they enter a + preceding the country code or skip it, or maybe they forgot the country code all together? It might not matter if you know what country they live in.
This may not help that much but I think context is key here. Personally I prefer a single field that lets my type away without moving input focus. As a programmer I prefer to enter just numbers, but the worst kind are inputs that require you to enter the data with specific formatting. These almost always fail with some international numbers and frustrate novices and experts alike.