Parsing phone numbers

  • Thread starter Thread starter Earl
  • Start date Start date
E

Earl

I'm curious if there are others who have a better method of
accepting/parsing phone numbers. I've used a couple of different techniques
that are functional but I can't really say that I'm totally happy with
either.

1. My first technique was to restrict the users to entries that could only
be 3 character, 3 characters, 4 character (area code, prefix, suffix,
respectively). I would null out any inputs that were non-numeric (except the
backspace). This worked reasonably well, except it was somewhat ugly to look
at.

2. My second technique was to give the user a single text entry box and
auto-format the string with hyphens as they entered the phone number. I then
parse the phone number, knowing exactly where the hypens are located.

What I'm looking for is some better ideas. Anyone?
 
What I'm looking for is some better ideas. Anyone?
Yes. Trust the user and accept more.
Why:
- numbers having extensions
- numbers with letters: 1-800-COLLECT
- numbers outside U.S.

I always get annoyed when I can't imput my data on some web sites
and quite a few of them lost me as a buyer.
Same with registration forms.
 
I'm curious if there are others who have a better method of
accepting/parsing phone numbers. I've used a couple of different techniques
that are functional but I can't really say that I'm totally happy with
either.

1. My first technique was to restrict the users to entries that could only
be 3 character, 3 characters, 4 character (area code, prefix, suffix,
respectively). I would null out any inputs that were non-numeric (except the
backspace). This worked reasonably well, except it was somewhat ugly to look
at.

2. My second technique was to give the user a single text entry box and
auto-format the string with hyphens as they entered the phone number. I then
parse the phone number, knowing exactly where the hypens are located.
Click to expand...

My personal preference is to let the user type what they want. Give
them a free entry text box. Then, in validation code (client or server
depending on your whims) you parse out what I typed and deal with it.
If I want to use dashes, thats up to me. If I want to use spaces,
thats my choice too. Now, if you want to reformat what I typed with
nice parentheses and dashes, thats your choice too - as long as what
you reformat it to is correct based on what I typed :)

Bottom line, the WORK should be on the programmers side - not the
users side.
 
I'm with Dan on this one. I'd include that the if your scheme does impose
some restriction, make sure that you have a clear example next to the text
box in a label or something that makes the requirements clear as day.
However, there are times that even with the documentation or examples, the
restrictions are ridiculous and still annoying. Having three or four
textboxes is another approach that's easier, so that the delimmiter doesn't
matter. Just make sure that the field auto tabs to the next one so that the
user doesn't have to hit tab if you use this method b/c it's really annoying
to have to tab twice or three times just to type in a number.

HTH,

Bill

--
W.G. Ryan MVP Windows - Embedded

www.devbuzz.com
www.knowdotnet.com
http://www.msmvps.com/williamryan/
 
Interesting ideas.

In some earlier apps, I have already implemented the multiple text box
scheme (with auto-focus). I've rejected that approach for this one.

International codes are irrelevant to this particular app since the
customer's phone number must, by definition, be a U.S. resident. However I
did allow for this in the database design, as well as extensions, which
might be more relevant and more problematic.

I'm not terribly inclined to allow "numbers" such as 1-800-COLLECT for the
simple reason these are advertiser conversions that are transparent and
would have to be re-parsed even though the user should already know the
number (without another parsing, searching on an exchange would create other
difficulties). This is certainly do-able but I would expect business users
to be bright enough to figure out what the real number was. It is food for
thought though, and I will put that one in my notes for a later date.

It would be great to implement Dan's idea about allowing ANYTHING to be
entered. But I'm not convinced we can make structure out of non-structure.
It seems to me that there has to be some bare-bones structure to what a user
can enter.

Otherwise, do we not hit a point of diminishing returns by anticipating and
parsing every potential scenario? Or do we end up with a Telemagic database,
where users have failed to do some semblance of formatting and the system
just blindly accepts whatever was entered? Ditto for the Act! method of
dealing with phone numbers, which once again allows the user to enter
"free-form", but indeed does not deal with every concatentation and parsing
potential and thus ends up with some pretty screwball phone numbers. In
fact, I have yet to see one commercial product that has successfully dealt
with this issue to the point where a user can enter anything they would like
and have the system turn it into a viable phone number.

While these have been great ideas to get me to thinking, I think for now I'm
going to continue to use my latest method, where I allow the user to enter
whatever they want -- in a single text box -- but null out everything but
numerals. I auto-format a dash as the number goes in, then move them out of
the entry box when they hit 12 characters. Extensions are going to have to
be dealt with separately.

Thanks all for sharing your thoughts.
 
Back
Top