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.
"William Ryan eMVP" <do********@comcast.nospam.net> wrote in message
news:ug**************@TK2MSFTNGP11.phx.gbl...
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/
"Earl comcast net>" <brikshoe<at.> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... 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?
