OT: Why do so many forms require numbers be entered without hyphens or spaces?
Mr. Nonsense
code to remove hyphens and spaces from a number. Are the coders that
inept, or is there some other issue I am overlooking?
r0g
You are overlooking the fact that numbers do not include spaces, and
that most of the time forms do not want negative numbers to beinput anyway.
Most numeric validation routines and regular expressions are set to only
accept strings of numeric characters, with is pretty reasonable when you
want to verify something IS a number. Sure they could strip out non
numeric chars (you'll find many forms that accept phone numbers do this
as this is one case where people will commonly type spaces in) but why
should they?
This in no more the fault of the coders being inept as the users ineptly
filling in the forms. These things are best dealt with client side
anyway, have some Javascript warn the user their entry is not valid, or
prevent them typing in invalid entries in the first place.
(Pedants please note this should NOT replace server side verification,
yawn!)
Roger.
Michael Fesser
>Most numeric validation routines and regular expressions are set to only
>accept strings of numeric characters, with is pretty reasonable when you
>want to verify something IS a number. Sure they could strip out non
>numeric chars (you'll find many forms that accept phone numbers do this
>as this is one case where people will commonly type spaces in) but why
>should they?
Exactly because of that - some numbers are usually written with spaces
for readability. Phone numbers, bank account numbers and such. Allowing
at least spaces in these cases would definitely increase the usability
and avoid some errors that may arise from copy 'n pasting such a number
into a form field.
Micha
Robert Heller
>
> Mr. Nonsense wrote:
> > I have never understood this since any programmer can add one line of
> > code to remove hyphens and spaces from a number. Are the coders that
> > inept, or is there some other issue I am overlooking?
>
> You are overlooking the fact that numbers do not include spaces, and
> that most of the time forms do not want negative numbers to beinput anyway.
>
I don't believe the OP is talking about pure numerical values.
> Most numeric validation routines and regular expressions are set to only
> accept strings of numeric characters, with is pretty reasonable when you
> want to verify something IS a number. Sure they could strip out non
> numeric chars (you'll find many forms that accept phone numbers do this
> as this is one case where people will commonly type spaces in) but why
> should they?
>
> This in no more the fault of the coders being inept as the users ineptly
> filling in the forms. These things are best dealt with client side
> anyway, have some Javascript warn the user their entry is not valid, or
> prevent them typing in invalid entries in the first place.
I believe the OP is not talking about pure numerical values, but
'numbers' in the sense of account numbers, credit/debit card numbers,
phone numbers, etc. These are often long strings of digit characters
(not really 'numbers' in any mathematical or computational sense) that
are often broken up with spaces and/or dashes for readablity reasons.
The spaces and dashes are not part of the 'numbers', but are used
solely to improve readablity. Credit Card processing programs want the
spaces and dashes stripped off. Many coders *are* lazy. Since the CC
processing code wants the spaces and/or dashes stripped when the CC
number is sent to CC processing land, they also *force* the customers
to enter the CC number without spaces or dashes. Many people have
trouble entering a 16 digit code without making errors and it is hard
to make sure the code is correct. CC cards themselves display the
account number as 4 groups of 4 digits with spaces between. Customers
*should* be able to enter their account number in this format and the
back end should be able to strip off the spaces (or dashes) before
packing the account number into the packet sent to the CC processing
server.
>
> (Pedants please note this should NOT replace server side verification,
> yawn!)
>
> Roger.
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
hel...@deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
Peter H. Coffin
> Mr. Nonsense wrote:
>> I have never understood this since any programmer can add one line of
>> code to remove hyphens and spaces from a number. Are the coders that
>> inept, or is there some other issue I am overlooking?
>
> You are overlooking the fact that numbers do not include spaces, and
> that most of the time forms do not want negative numbers to beinput anyway.
>
> Most numeric validation routines and regular expressions are set to only
> accept strings of numeric characters, with is pretty reasonable when you
> want to verify something IS a number. Sure they could strip out non
> numeric chars (you'll find many forms that accept phone numbers do this
> as this is one case where people will commonly type spaces in) but why
> should they?
So, as Mr. Nonsense wrote, the forms processor should handle all the
stripping and processing of data, WITHOUT placing requirements on the
end user.
> This in no more the fault of the coders being inept as the users ineptly
> filling in the forms. These things are best dealt with client side
> anyway, have some Javascript warn the user their entry is not valid, or
> prevent them typing in invalid entries in the first place.
No, they shouldn't be dealt with on the client side because the client
side cannot be forced, only recommended.
> (Pedants please note this should NOT replace server side verification,
> yawn!)
... which would be a *really convenient* place to do the server-side
formatting and cleaning of the phone number data, wouldn't it, for
almost no extra work. But that would require ept programmers, wouldn't
it?
--
The pluses in my current job include laughing in the face of Nobel
laureates who have just lost the only copy of their data. (Hey,
I'm still a BOFH).
-- Bob Dowling
Doug Miller
>Mr. Nonsense wrote:
>> I have never understood this since any programmer can add one line of
>> code to remove hyphens and spaces from a number. Are the coders that
>> inept, or is there some other issue I am overlooking?
>
>You are overlooking the fact that numbers do not include spaces, and
>that most of the time forms do not want negative numbers to beinput anyway.
>
>Most numeric validation routines and regular expressions are set to only
>accept strings of numeric characters, with is pretty reasonable when you
>want to verify something IS a number. Sure they could strip out non
>numeric chars (you'll find many forms that accept phone numbers do this
>as this is one case where people will commonly type spaces in) but why
>should they?
Because computers are supposed to serve human beings, not the other way
around. People typically write telephone numbers as 123-4567 or (123)
456-7890, social security numbers as 123-45-6789, and so on. These are
typically stored in databases without any of the extraneous characters. Why
should the user have to guess which format you store it in? It's a simple
matter to remove the characters space, hypen, (, and ) from a phone number, or
hyphen from a social security number, and then validate what's left. Failing
to do so is simply laziness on the part of the programmer -- or perhaps a case
of forgetting who's working for whom.
>
>This in no more the fault of the coders being inept
Oh, yes it is.
> as the users ineptly
>filling in the forms.
Nonsense. Far too many web forms give no indication at all that phone numbers
must be entered without any punctuation at all, and cannot be entered in the
formats which people commonly use for phone numbers. That's not the fault of
the users -- the user's expectation is that a web form should accept a phone
number in the format(s) that are commonly used for writing phone numbers. That
is *entirely* the fault of inept coders and designers.
Michael Fesser
>[...] Credit Card processing programs want the
>spaces and dashes stripped off. Many coders *are* lazy. Since the CC
>processing code wants the spaces and/or dashes stripped when the CC
>number is sent to CC processing land, they also *force* the customers
>to enter the CC number without spaces or dashes. Many people have
>trouble entering a 16 digit code without making errors and it is hard
>to make sure the code is correct. [...]
A while ago I ran into a similar problem myself. I had to pay for some
online service and got their bank details from their website. I simply
did a copy 'n paste of the numbers directly into the form for my online
banking, quick and easy.
A few days later I got a letter from my bank, telling me that the
transaction failed, because the receiver was unknown.
After a little research and trying again I found the reason. In Germany
bank account numbers consist of at most 10 digits, but are often written
with 2 or 3 spaces for readability, which of course increases the number
of chars. The field for the account number in my online banking form was
limited to exactly 10 chars - pasting in the number from the website cut
off the last two digits because of that restriction.
Of course I could have looked twice (and since then I do), but it was
quite a surprise. So even if the pure number of digits is limited, like
in the case of account numbers for example, the form field should allow
for variants including spaces, because that's how most people see and
write those numbers.
The script has to serve and adjust to the user, not the other way round.
Micha
matt
Generally, I like to simplify things for myself AND the end user,
giving fields such as
+---+ +---+ +----+
Phone: (| |) | |-| |
+---+ +---+ +----+
+---+ +--+ +----+
SSN: | |-| |-| |
+---+ +--+ +----+
(Ya like my ASCII art form fields?)
You can even write in javascript hooks so that when they type in the
third number of an area code, for example, it runs a quick validation,
popping up a message if the field value doesn't match ^\d{3}$, then
focus and select the errant entry. If it does pass, you can go ahead
and drop the cursor focus in the next field, so people can type it
continuously without tabbing.
Of course, as r0g pointed out, client-side stuff should only be there
as a convenience to the user, and should never replace your server-
side validation. But, if you set up your users for success with easy
to use forms, you can save yourself some page loads and them some
irritation for having to keep re-entering data.
I should also point out that this is not something that only affects
the computer illiterate people! Often if I come to a form that just
has a size="40" text field for a phone number and no formatting
instructions, I hesitate for a moment wondering how the server-side
script is going to parse my input.
Now for an OT::OT diversion...does anyone have a snippet of JS that
allows something like a phone number to be cut-and-pasted across
multiple fields? I've really only seen this implemented in things
like (windowed) software registration dialogs--ie, receive the Email
from the software company with the activation code, highlight it and
"Copy", and then a "Paste Code" button on the form. It's probably not
hard to write...I just hate writing JS and prefer to "borrow" when I
can :)
Tony Mountifield
matt <matthew....@gmail.com> wrote:
> On Dec 18, 10:24�am, "Mr. Nonsense" <mynonse...@mynonsense.net> wrote:
> > I have never understood this since any programmer can add one line of
> > code to remove hyphens and spaces from a number. Are the coders that
> > inept, or is there some other issue I am overlooking?
>
> Generally, I like to simplify things for myself AND the end user,
> giving fields such as
>
> +---+ +---+ +----+
> Phone: (| |) | |-| |
> +---+ +---+ +----+
And then someone wants to enter an international phone number...
Cheers
Tony
--
Tony Mountifield
Work: to...@softins.co.uk - http://www.softins.co.uk
Play: to...@mountifield.org - http://tony.mountifield.org
Michael Fesser
>In article <6b498794-f967-4a6d...@c34g2000yqn.googlegroups.com>,
>matt <matthew....@gmail.com> wrote:
>> On Dec 18, 10:24�am, "Mr. Nonsense" <mynonse...@mynonsense.net> wrote:
>> > I have never understood this since any programmer can add one line of
>> > code to remove hyphens and spaces from a number. Are the coders that
>> > inept, or is there some other issue I am overlooking?
>>
>> Generally, I like to simplify things for myself AND the end user,
>> giving fields such as
>>
>> +---+ +---+ +----+
>> Phone: (| |) | |-| |
>> +---+ +---+ +----+
>
>And then someone wants to enter an international phone number...
I was about to ask the same ... +49 ... and then?
It's the same as with fields for dates - there should be _one_ field for
convenient user input. It's the server's task to parse it.
Micha
Jerry Stuckle
> In article <hgg7d9$1sm$1...@aioe.org>, r0g <aioe...@technicalbloke.com> wrote:
>> Mr. Nonsense wrote:
>>> I have never understood this since any programmer can add one line of
>>> code to remove hyphens and spaces from a number. Are the coders that
>>> inept, or is there some other issue I am overlooking?
>> You are overlooking the fact that numbers do not include spaces, and
>> that most of the time forms do not want negative numbers to beinput anyway.
>>
>> Most numeric validation routines and regular expressions are set to only
>> accept strings of numeric characters, with is pretty reasonable when you
>> want to verify something IS a number. Sure they could strip out non
>> numeric chars (you'll find many forms that accept phone numbers do this
>> as this is one case where people will commonly type spaces in) but why
>> should they?
>
> Because computers are supposed to serve human beings, not the other way
> around. People typically write telephone numbers as 123-4567 or (123)
> 456-7890, social security numbers as 123-45-6789, and so on. These are
> typically stored in databases without any of the extraneous characters. Why
> should the user have to guess which format you store it in? It's a simple
> matter to remove the characters space, hypen, (, and ) from a phone number, or
> hyphen from a social security number, and then validate what's left. Failing
> to do so is simply laziness on the part of the programmer -- or perhaps a case
> of forgetting who's working for whom.
I will disagree here. There is no "normal" way of storing this
information. I've seen phone numbers stored many ways in a database;
same with social security numbers. Both are especially true if you're
talking a database with international entries. How it's done is
completely dependent on the data.
Remember - not everyone in the world lives in the U.S.!
>> This in no more the fault of the coders being inept
>
> Oh, yes it is.
>
>> as the users ineptly
>> filling in the forms.
>
> Nonsense. Far too many web forms give no indication at all that phone numbers
> must be entered without any punctuation at all, and cannot be entered in the
> formats which people commonly use for phone numbers. That's not the fault of
> the users -- the user's expectation is that a web form should accept a phone
> number in the format(s) that are commonly used for writing phone numbers. That
> is *entirely* the fault of inept coders and designers.
>
No, that is *entirely* dependent on the needs of the program. Again -
you are thinking from a U.S. only perspective. The world is much bigger
than that!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Doug Miller
Massively missing the point, which is that the person visiting the page
neither knows nor cares, and should not NEED to know or care, what format the
designer has chosen for storing the data. Any system which forces its users to
know the details of its data storage formats in order to do something as
simple as filling out a contact form is incompetently designed.
>
>
>>> This in no more the fault of the coders being inept
>>
>> Oh, yes it is.
>>
>>> as the users ineptly
>>> filling in the forms.
>>
>> Nonsense. Far too many web forms give no indication at all that phone numbers
>> must be entered without any punctuation at all, and cannot be entered in the
>> formats which people commonly use for phone numbers. That's not the fault of
>> the users -- the user's expectation is that a web form should accept a phone
>> number in the format(s) that are commonly used for writing phone numbers. That
>> is *entirely* the fault of inept coders and designers.
>>
>
>No, that is *entirely* dependent on the needs of the program. Again -
>you are thinking from a U.S. only perspective. The world is much bigger
>than that!
Again, you've completely missed the point: computers are here to serve us, not
the other way around. The alleged "needs" of the program should always be
subordinate to the needs, desires, and convenience of the human beings who use
it -- and in nearly all cases those alleged "needs" are the direct result of a
programmer who either fails to understand that concept, or lacks the wit or
imagination necessary to adapt his program to the humans who will use it.
Computers should adapt to us, not we to them.
Jerry Stuckle
No, YOU are missing the point. Different countries have different
formats for phones - and typically like to see the phone numbers in
their own format, not a string of numbers or the U.S. format. Many
times for this reason I have stored phone numbers as strings.
How are you going to handle this with your U.S. centric system? Get
your blinders off!
And non-US citizens don't have SSN's.
>>
>>>> This in no more the fault of the coders being inept
>>> Oh, yes it is.
>>>
>>>> as the users ineptly
>>>> filling in the forms.
>>> Nonsense. Far too many web forms give no indication at all that phone numbers
>>> must be entered without any punctuation at all, and cannot be entered in the
>>> formats which people commonly use for phone numbers. That's not the fault of
>>> the users -- the user's expectation is that a web form should accept a phone
>>> number in the format(s) that are commonly used for writing phone numbers. That
>>> is *entirely* the fault of inept coders and designers.
>>>
>> No, that is *entirely* dependent on the needs of the program. Again -
>> you are thinking from a U.S. only perspective. The world is much bigger
>> than that!
>
> Again, you've completely missed the point: computers are here to serve us, not
> the other way around. The alleged "needs" of the program should always be
> subordinate to the needs, desires, and convenience of the human beings who use
> it -- and in nearly all cases those alleged "needs" are the direct result of a
> programmer who either fails to understand that concept, or lacks the wit or
> imagination necessary to adapt his program to the humans who will use it.
>
> Computers should adapt to us, not we to them.
No, I have NOT missed the point. However, your attitude shows a
complete ignorance of real world problems when you're non-US.
Doug Miller
You seem to be unable to distinguish between examples of a principle, and the
principle itself. The point remains: computers are our servants; we are not
theirs. If a program requires its users to input data in a form other
than the form(s) those user(s) are accustomed to using, and cannot perform
such simple adaptations as stripping out common punctuation characters, then
that program has been incompetently designed and coded.
Yes, you have totally missed the point. This has *nothing* to do with the
conventions for writing telephone numbers in any particular nation, and
*everything* to do with the principle that computers should adapt to us, not
we to them. Evidently you disagree.
Jerry Stuckle
No, I'm not. They are YOUR examples, not mine. I'm replying to YOUR
comments. If the example is faulty, then it's YOUR problem.
But the point YOU fail to understand - there are many times those
"common punctuation characters" are important - and should NOT be stripped.
And in a case like this, any program which does strip the characters is
bad, and it's programmer is blind to the ramifications, if not
completely incompetent.
No, you have your U.S.-centric blinders on and fail to see there are
many ways to do something.
Please show me how your program can adapt to every possible phone number
format in the world, accepting AND REDISPLAYING those numbers in the
common format of that locality, after you've stripped out all of the
punctuation characters. This is, after all, YOUR argument!
Another idiot who thinks the world has to revolve around the U.S.
Doug Miller
I never suggested they should be stripped in all cases.
>
>And in a case like this, any program which does strip the characters is
>bad, and it's programmer is blind to the ramifications, if not
>completely incompetent.
<snort>
Not at all. You have the blinders on, not me.
>
>Please show me how your program can adapt to every possible phone number
>format in the world, accepting AND REDISPLAYING those numbers in the
>common format of that locality, after you've stripped out all of the
>punctuation characters. This is, after all, YOUR argument!
>
>Another idiot who thinks the world has to revolve around the U.S.
>
You're continuing to miss the point, Jerry. At this point, I can only assume
that it's intentional, and so I'm done. You can have the last word if it makes
you feel better. Continue with the ad hominem attacks as usual. I won't
respond.
Jerry Stuckle
<sigh>You already forgot what you wrote, just a few hours ago. Let me
refresh your memory:
"People typically write telephone numbers as 123-4567 or (123)
456-7890, social security numbers as 123-45-6789, and so on. These are
typically stored in databases without any of the extraneous characters."
>> And in a case like this, any program which does strip the characters is
>> bad, and it's programmer is blind to the ramifications, if not
>> completely incompetent.
>
> <snort>
And those programmers seem to snort a lot, also.
You're the one talking about how phone numbers are typically entered in
U.S. format. You fail to acknowledge there is a whole rest of the world
out there. But then that's all too typical of many U.S. programmers.
>> Please show me how your program can adapt to every possible phone number
>> format in the world, accepting AND REDISPLAYING those numbers in the
>> common format of that locality, after you've stripped out all of the
>> punctuation characters. This is, after all, YOUR argument!
>>
>> Another idiot who thinks the world has to revolve around the U.S.
>>
> You're continuing to miss the point, Jerry. At this point, I can only assume
> that it's intentional, and so I'm done. You can have the last word if it makes
> you feel better. Continue with the ad hominem attacks as usual. I won't
> respond.
No, I have not missed the point. Please explain how this will be done.
After all - it's YOUR example.
But you can't - because your example and your entire argument is
fallacious - again, typical of too many U.S. programmers who think the
world revolves around them.
r0g
That's hardly simplifying things though is it? Even within one country
people disagree where the spaces in phone numbers should go. Now add
250+ countries phone number conventions for extra chaos!
Roger.
r0g
> At Fri, 18 Dec 2009 15:34:45 +0000 r0g <aioe...@technicalbloke.com> wrote:
>
>> Mr. Nonsense wrote:
>>> I have never understood this since any programmer can add one line of
>>> code to remove hyphens and spaces from a number. Are the coders that
>>> inept, or is there some other issue I am overlooking?
>> You are overlooking the fact that numbers do not include spaces, and
>> that most of the time forms do not want negative numbers to beinput anyway.
>>
>
> I don't believe the OP is talking about pure numerical values.
>
Well if he'd SAID THAT it might have spared us some quite tedious
'debate'. What he said was "numbers" and "numbers" are a quite specific
range of things: Integers, Reals, Imaginary etc.
What people refer to as phone "numbers" are actually strings, it is
incorrect to represent them internally as numbers as this will cause
misrepresentation e.g. all non-local UK telephone numbers start with a 0.
When one has to enter an ACTUAL number there is no need for the
validation routine to accept any characters other than MAYBE . and -
<snip>
> The spaces and dashes are not part of the 'numbers', but are used
> solely to improve readablity. Credit Card processing programs want the
> spaces and dashes stripped off. Many coders *are* lazy. Since the CC
> processing code wants the spaces and/or dashes stripped when the CC
> number is sent to CC processing land, they also *force* the customers
> to enter the CC number without spaces or dashes. Many people have
> trouble entering a 16 digit code without making errors and it is hard
> to make sure the code is correct.
Is it really such a hardship entering a 16 digit number? I've never
heard anyone complain about it before and my elderly parents don't seem
to have any problem with it. That said I agree if people are likely to
input it then the form should be ready to handle that however...
PHP is a server side language, any halfway decent web programmer these
days ought to be pre-validating information client side with Javascript
and issuing guidance to the user on page rather than waiting for them to
click next (does anyone still do that?). Any formatting errors that can
be checked for servers side can, and should, be checked for client side.
Credit card numbers in particular have a checksums you may calculate to
verify they have been entered correctly. The server side should be
presented the information in a canonical form otherwise you have to
duplicate every little bit of fixing and validation again in PHP. If you
pre validate your form submissions and ensure submissions can only
happen in canonical form then anything your server receives in
non-canonical form can simply be rejected and maybe even flagged as
potentially malign.
CC cards themselves display the
> account number as 4 groups of 4 digits with spaces between. Customers
> *should* be able to enter their account number in this format and the
> back end should be able to strip off the spaces (or dashes) before
> packing the account number into the packet sent to the CC processing
> server.
As I say, if you want to strip this stuff out (and I'm not saying you
shouldn't, after all these are strings not numbers) you ought to do it
client side. Seeing as everyone's so user focussed here answer me this...
Why should the user have to submit an form before finding out some
fields are invalid? that's so web 1.0, it's nearly 2010 guys: surely
your submit button should not even be clickable until the form is in a
valid state?
Roger.
Robert Heller
>
> Robert Heller wrote:
> > At Fri, 18 Dec 2009 15:34:45 +0000 r0g <aioe...@technicalbloke.com> wrote:
> >
> >> Mr. Nonsense wrote:
> >>> I have never understood this since any programmer can add one line of
> >>> code to remove hyphens and spaces from a number. Are the coders that
> >>> inept, or is there some other issue I am overlooking?
> >> You are overlooking the fact that numbers do not include spaces, and
> >> that most of the time forms do not want negative numbers to beinput anyway.
> >>
> >
> > I don't believe the OP is talking about pure numerical values.
> >
>
>
>
> Well if he'd SAID THAT it might have spared us some quite tedious
> 'debate'. What he said was "numbers" and "numbers" are a quite specific
> range of things: Integers, Reals, Imaginary etc.
>
> What people refer to as phone "numbers" are actually strings, it is
> incorrect to represent them internally as numbers as this will cause
> misrepresentation e.g. all non-local UK telephone numbers start with a 0.
>
> When one has to enter an ACTUAL number there is no need for the
> validation routine to accept any characters other than MAYBE . and -
If you had read the OP's post completely and carefully, it was pretty
clear he was NOT talking about 'numerical' values, but things like phone
numbers and [bank / credit card / etc.] account numbers, which, as you
say are not really numerical values, but digit strings. What commonly
happens, *partitularly* for credit/debit card account numbers is the the
processing systems just want the 16-digit digit string, generally packed
into some kind of fixed format, so many (dumb!) web programmers use
validation code (either with JavaScript or on the server side that
insists that the account number is entered in this format, even though
it is always trivial to strip off spaces or dashes and it is also the
case the the account numbers are in fact printed on the cards as 4
groups of 4 digits, which aids (human) readablity.
--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Tim Roberts
>
>Generally, I like to simplify things for myself AND the end user,
>giving fields such as
>
> +---+ +---+ +----+
>Phone: (| |) | |-| |
> +---+ +---+ +----+
Which, unfortunately, totally screws any potential clients outside of North
America, or anyone who is reached through an extension. I just make the
phone number a pure text field and let the user enter whatever passes for a
phone number.
>I should also point out that this is not something that only affects
>the computer illiterate people! Often if I come to a form that just
>has a size="40" text field for a phone number and no formatting
>instructions, I hesitate for a moment wondering how the server-side
>script is going to parse my input.
Why does the server have to "parse" a phone number at all? With very few
exceptions, the only puropse for a phone number field is to provide a
backup way to contact someone, and that's going to be done by a human
being.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
rf
"Tim Roberts" <ti...@probo.com> wrote in message
news:mgqti5p4bfctg30mj...@4ax.com...
> matt <matthew....@gmail.com> wrote:
>>
>>Generally, I like to simplify things for myself AND the end user,
>>giving fields such as
>>
>> +---+ +---+ +----+
>>Phone: (| |) | |-| |
>> +---+ +---+ +----+
>
> Which, unfortunately, totally screws any potential clients outside of
> North
> America, or anyone who is reached through an extension. I just make the
> phone number a pure text field and let the user enter whatever passes for
> a
> phone number.
I was in Mammoth Mountain CA in the U S of A once. To buy a ski pass I had
to enter my name and address, they were doing some demographic research.
The stupid bloody system insisted that my "zip" code be 5 digits. Well, my
*post* code is actually 4 digits, as they all are in Australia. Needless to
say all ten of us aussies had to lie to get our pass, and not just lie with
some random. string of numbers. The system was damn arrogant enough to
insist on a valid US zip code. The zip code for Mammoth was helpfully
written on the top of the monitor so people in our situation could lie
convincingly. This of course totally destroyed their demographics
Oh, and, BTW, my international phone number is something like:
+62 5555 5555 and if I am at an office somewhere
+62 5555 5555 x222 which simply does not fit into the above.
>
>>I should also point out that this is not something that only affects
>>the computer illiterate people! Often if I come to a form that just
>>has a size="40" text field for a phone number and no formatting
>>instructions, I hesitate for a moment wondering how the server-side
>>script is going to parse my input.
What's wrong with that? Why can't I have *anything* in my phone number? 555
5555 and ask for rf. I don't wonder at all. If it does not fit then it is
the form owners fault, not mine.
> Why does the server have to "parse" a phone number at all? With very few
> exceptions, the only puropse for a phone number field is to provide a
> backup way to contact someone, and that's going to be done by a human
> being.
Indeed. If any computers call me (and they have, and invariably put me on
hold to wait for "the first available receptionist") I colourfully tell them
exactly where to go, hoping it's being recorded for posterity
jeff
> .oO(Robert Heller)
>
>> [...] Credit Card processing programs want the
>> spaces and dashes stripped off. Many coders *are* lazy. Since the CC
>> processing code wants the spaces and/or dashes stripped when the CC
>> number is sent to CC processing land, they also *force* the customers
>> to enter the CC number without spaces or dashes. Many people have
>> trouble entering a 16 digit code without making errors and it is hard
>> to make sure the code is correct. [...]
>
> A while ago I ran into a similar problem myself. I had to pay for some
> online service and got their bank details from their website. I simply
> did a copy 'n paste of the numbers directly into the form for my online
> banking, quick and easy.
>
> A few days later I got a letter from my bank, telling me that the
> transaction failed, because the receiver was unknown.
If you send credit card numbers off to PayPal Payments Pro, it chokes on
spaces. I find this ridiculous that a common method of entering such
numbers is not recognized. Neither was this documented in either their
docs or sample code. How many unrecognized failures and how much money
is lost because of this? It's not trivial. And it is pointless.
Whitespaces and dashes improve readability and that is a good enough
reason to allow them.
I'm with the crowd that says that programmers should make life
easier, not obtuse.
Jeff
Peter H. Coffin
Sorry, Jerry, but I think you are missing it. You're saying "there's
lots of formats" and Doug's saying "there IS NO format", and as far as
actual dialing goes, there isn't a format. I've seen no telephone that
supported dialing a "-" or a ")". I'd go so far as to say there's
exactly one format, and it looks like
> And non-US citizens don't have SSN's.
Yeah, well, the *point* is that the "-" doesn't have to be there, and
there's no point in storing the "-", nor is there any point in squawking
and making a user reenter the number if it is or isn't in the entry. If
you're processing SSNs, strip out ALL non-numerics, and complain if it's
not nine digits, and doesn't meet a small list of requirements for
"never issued" numbers.
--
94. When arresting prisoners, my guards will not allow them to stop and
grab a useless trinket of purely sentimental value.
--Peter Anspach's list of things to do as an Evil Overlord
Jerry Stuckle
But humans aren't telephones, and the formats are meant to enhance
readability. There are standardized formats - in the U.S., for
instance, they can include hyphens, dashes and/or periods.
> +16085556458
> +4402079460548
>
But neither of those are used by U.S. and Canadian people, for instance.
And other countries have much different formats.
>> And non-US citizens don't have SSN's.
>
> Yeah, well, the *point* is that the "-" doesn't have to be there, and
> there's no point in storing the "-", nor is there any point in squawking
> and making a user reenter the number if it is or isn't in the entry. If
> you're processing SSNs, strip out ALL non-numerics, and complain if it's
> not nine digits, and doesn't meet a small list of requirements for
> "never issued" numbers.
>
The same is true of SSN's. The formatting is to make it user-friendly.
Also, please identify what is that 'small list of requirements for
"never issued" numbers'?
And, I ask you, also. Please show how you can remove the "-" and
display the number in a user-friendly format, according to the standards
of the country involved.
matt
> In article <6b498794-f967-4a6d-bba8-4748c5bd6...@c34g2000yqn.googlegroups.com>,
>
> matt <matthew.leonha...@gmail.com> wrote:
> > On Dec 18, 10:24 am, "Mr. Nonsense" <mynonse...@mynonsense.net> wrote:
> > > I have never understood this since any programmer can add one line of
> > > code to remove hyphens and spaces from a number. Are the coders that
> > > inept, or is there some other issue I am overlooking?
>
> > Generally, I like to simplify things for myself AND the end user,
> > giving fields such as
>
> > +---+ +---+ +----+
> > Phone: (| |) | |-| |
> > +---+ +---+ +----+
>
> And then someone wants to enter an international phone number...
Yeah...I guess that really depends on the application's specs, doesn't
it. Not exactly related to my point though...
matt
> matt <matthew.leonha...@gmail.com> wrote:
>
> >Generally, I like to simplify things for myself AND the end user,
> >giving fields such as
>
> > +---+ +---+ +----+
> >Phone: (| |) | |-| |
> > +---+ +---+ +----+
>
> Which, unfortunately, totally screws any potential clients outside of North
> America, or anyone who is reached through an extension. I just make the
> phone number a pure text field and let the user enter whatever passes for a
> phone number.
Okay...once again, I feel the need to defend my example. I had no
idea so many panties would get twisted here. This was an
example...ONE! Not the be all, end all phone number input field. I
guess I made the mistake of thinking that this thread was related to
usability, not internationalization.
Just because there aren't one-format-fits-all solutions to common
fields from locale to locale doesn't mean that the idea of splitting
them into common formatting divisions is invalid. Oh my gosh, you
might have to work a little harder and have different input formats
for different locales. Nah...let's just throw the baby out with the
bathwater instead. It's really too hard to make a web site that is
easy for everyone to use. Let's just make it uninviting for
everyone. (All of a sudden, I feel that we're back on-topic with the
OP's concerns).
> >I should also point out that this is not something that only affects
> >the computer illiterate people! Often if I come to a form that just
> >has a size="40" text field for a phone number and no formatting
> >instructions, I hesitate for a moment wondering how the server-side
> >script is going to parse my input.
>
> Why does the server have to "parse" a phone number at all? With very few
> exceptions, the only puropse for a phone number field is to provide a
> backup way to contact someone, and that's going to be done by a human
> being.
Maybe so. Perhaps one wishes to validate the data coming in. Perhaps
one is storing the data in a legacy format that requires a specific
character length. Perhaps this conversation isn't limited to phone
numbers.
Beauregard T. Shagnasty
> Peter H. Coffin wrote:
<huge snippage required>
>> Yeah, well, the *point* is that the "-" doesn't have to be there, and
>> there's no point in storing the "-", nor is there any point in
>> squawking and making a user reenter the number if it is or isn't in
>> the entry. If you're processing SSNs, strip out ALL non-numerics,
>> and complain if it's not nine digits, and doesn't meet a small list
>> of requirements for "never issued" numbers.
>
> The same is true of SSN's. The formatting is to make it
> user-friendly.
Therefore, a field for (US) SSN should be eleven characters, to allow
the enterers to type 123-45-6789. It does not need to be stored that
way.
> Also, please identify what is that 'small list of requirements for
> "never issued" numbers'?
It's been a long time since I've worked with SSNs in software, but there
is a small subset used for things like brochures, TV advertising, etc.
These can't be issued numbers to the citizens. Same for credit cards.
Did you know that people continually attempt to buy stuff online with a
number and name from a credit card TV commercial?
> And, I ask you, also. Please show how you can remove the "-" and
> display the number in a user-friendly format, according to the
> standards of the country involved.
"Gather", "store", and "display" are three different things. Gather
whatever user types; store only the digits, display after reinserting
the dashes. Applies to SSNs, phone numbers, and even credit cards.
--
-bts
-Four wheels carry the body; two wheels move the soul
Rob W.
>
> And, I ask you, also. Please show how you can remove the "-" and
> display the number in a user-friendly format, according to the standards
> of the country involved.
>
I think the user-friendly format very much depends on the specific number.
Since in the Netherlands all mobile phone numbers start with 06
I prefer pairs of two
either spoken or displayed in print or online.
The gov.agency I work for uses hundreds of mobile phones
whose numbers all have the same 6 digits to start with: 061920.
So we like to display them as 06 1920 xxxx
All phone numbers in The Netherlands have 10 digits
but some area codes have 3 digits and some have 4 digits.
This makes for at least four methods of display:
(099) 999 9999
(099) 99 99 999
(0999) 99 99 99
(0999) 999 999
--
Rob
Doug Miller
>Jerry Stuckle wrote:
>
>> Also, please identify what is that 'small list of requirements for
>> "never issued" numbers'?
>
>It's been a long time since I've worked with SSNs in software, but there
>is a small subset used for things like brochures, TV advertising, etc.
>These can't be issued numbers to the citizens.
It's been a long time for me, too, probably about fifteen years since I last
had to deal with that. I remember calling the Social Security Administration
and asking what the rules were for determining if a given nine-digit number
was a valid SSN (not necessarily determining if it had been issued, mind you,
just determining validity). There were only about three or four rules; the
only one I can remember any more is that it can't start with three zeros.
Beauregard T. Shagnasty
It's probably nearly the same amount of time since I dealt with them in
programming. But it was a few seconds at google to turn up:
http://en.wikipedia.org/wiki/Social_Security_number
Note sections 6 and 7. :-) Note the story on the 1938 advertising, and
the number of people who've attempted to use it as a real number.
Jerry Stuckle
No, it doesn't have to be stored that way. But why go to all the
trouble of taking out the hyphens, only to put them back in again? They
still have to be stored as a string - because they *can* start with a
zero. And comparisons will work whether you have the hyphens in there
or not, as long as you are consistent.
And then we get back to the problem of only U.S. citizens have SSN's.
Other countries have different id numbers. So are you going to rule out
all non-US citizens?
Too many U.S. programmers think the world revolves around the U.S. It
doesn't.
r0g
> At Sun, 20 Dec 2009 18:56:59 +0000 r0g <aioe...@technicalbloke.com> wrote:
>
>> Robert Heller wrote:
>>> At Fri, 18 Dec 2009 15:34:45 +0000 r0g <aioe...@technicalbloke.com> wrote:
> If you had read the OP's post completely and carefully, it was pretty
> clear he was NOT talking about 'numerical' values, but things like phone
> numbers and [bank / credit card / etc.] account numbers, which, as you
> say are not really numerical values, but digit strings.
You know I did read it carefully and I did understand what he meant but
be that as it may he SAID "numbers", twice, and I reserve the right to
be a pedant when people barge in here with statements who's tone verges
on trolling.
One ought to be precise when bandying round words like "inept".
Forcefully asserting one thing publicly then claiming you meant
something else wouldn't get you very far in a libel trial would it?
Roger.
Doug Miller
I had forgotten that the middle and last groups couldn't be all zeros either,
probably because the first-group rule was the only one that really mattered to
our company. We needed a sure and certain way of telling the difference
between a member-ID (6 significant digits with possible leading zeros) and an
SSN in health insurance claims -- and that was it.
Beauregard T. Shagnasty
Consistency?
> They still have to be stored as a string - because they *can* start
> with a zero. And comparisons will work whether you have the hyphens
> in there or not, as long as you are consistent.
What if the form filler does *not* enter the hyphens?
> And then we get back to the problem of only U.S. citizens have SSN's.
> Other countries have different id numbers. So are you going to rule
> out all non-US citizens?
>
> Too many U.S. programmers think the world revolves around the U.S.
Some, for sure. But this is currently a conversation about SSNs.
> It doesn't.
Since this current conversation is about Social Security Numbers, how
many other countries do you know that have an identity number known as
"SSN?" Especially if the programmer is writing software for a U.S.
company, which wouldn't likely be interested in ID numbers of other
countries...
Jerry Stuckle
What's inconsistent about leaving them in there in the first place?
>> They still have to be stored as a string - because they *can* start
>> with a zero. And comparisons will work whether you have the hyphens
>> in there or not, as long as you are consistent.
>
> What if the form filler does *not* enter the hyphens?
>
A good form would have three fields, or it would insert them in the
first place. Another alternative would be not to accept them in an
incorrect format - because people think of 000-00-0000 being a SSN - not
000000000 or 000 00 0000.
>> And then we get back to the problem of only U.S. citizens have SSN's.
>> Other countries have different id numbers. So are you going to rule
>> out all non-US citizens?
>>
>> Too many U.S. programmers think the world revolves around the U.S.
>
> Some, for sure. But this is currently a conversation about SSNs.
>
Which is US-centric. So you are going to lock out all non-U.S.
citizens. Typical of a programmer who thinks the world revolves around
the U.S.
>> It doesn't.
>
> Since this current conversation is about Social Security Numbers, how
> many other countries do you know that have an identity number known as
> "SSN?" Especially if the programmer is writing software for a U.S.
> company, which wouldn't likely be interested in ID numbers of other
> countries...
>
So you think the world revolves around the U.S. Other countries have
identification numbers of some type.
And I don't know of too many companies who will turn away business from
a non-US citizen (i.e. a legal alien going to school or working here).
But the whole point is moot, anyway - because nowadays, no company asks
for a SSN unless it is legally required, i.e. for employment purposes.
Go ahead with your U.S.-centric programming.
Beauregard T. Shagnasty
> Go ahead with your U.S.-centric programming.
You seem to have missed the point.
Jerry Stuckle
> Jerry Stuckle wrote:
>
>> Go ahead with your U.S.-centric programming.
>
> You seem to have missed the point.
>
Not at all. I completely understand your attitude. Unfortunately, all
too common in many U.S. programmers.
Peter H. Coffin
Right, but that's a *display* function, not a quality of the phone
number. So we go ahead and apply that when we show the number to a
human. Internally, program-wise and database-wise, we work with
>> +16085556458
>> +4402079460548
and even the + is optional if we want to be very vigorous about
remembering that what we're storing is the international dialing format.
> But neither of those are used by U.S. and Canadian people, for instance.
> And other countries have much different formats.
Well, kinda and kinda not. I mean (as above), it's not a display format,
but it's a convention that works world-wide and (nearly) everyone can
figure it out with the instrutions distributed by their local telco.
>>> And non-US citizens don't have SSN's.
>>
>> Yeah, well, the *point* is that the "-" doesn't have to be there, and
>> there's no point in storing the "-", nor is there any point in squawking
>> and making a user reenter the number if it is or isn't in the entry. If
>> you're processing SSNs, strip out ALL non-numerics, and complain if it's
>> not nine digits, and doesn't meet a small list of requirements for
>> "never issued" numbers.
>>
>
> The same is true of SSN's. The formatting is to make it user-friendly.
> Also, please identify what is that 'small list of requirements for
> "never issued" numbers'?
Lessee.... I'd have to look it up again to get a complete ruleset, but
what I remember is the first three numbers never 000 or 666, or above
(I think) 779, the 4th and 5th can't be 00, and the last four
can't be 0000. There's a short list of reserved numbers as well, but I
can't remember them either off-hand, but I'm sure it's detailed on the
Social Security Administration site someplace....
> And, I ask you, also. Please show how you can remove the "-" and
> display the number in a user-friendly format, according to the standards
> of the country involved.
If they're all stored with country codes, city codes, and all the rest
of the complete information necessary to dial it per ITU-T E.164, then
you have all the information necessary to know WHICH format to use.
You'll need the formats, of course, but many of them are detailed at
http://en.wikipedia.org/wiki/Local_conventions_for_writing_telephone_numbers
and working them up in a nice collection of sprintf() becomes an
exercise of an hour or two.
--
I hate mornings. I know they hate me back, too.
-- Joel Gluth
Jerry Stuckle
And it is much easier to just store them as strings - with the
punctuation intact.
Beauregard T. Shagnasty
> Beauregard T. Shagnasty wrote:
>> Jerry Stuckle wrote:
>>> Go ahead with your U.S.-centric programming.
>>
>> You seem to have missed the point.
>
> Not at all. I completely understand your attitude.
No you don't. Not at all.
> Unfortunately, all too common in many U.S. programmers.
Tell me how many applications (or even web pages!) that *would* be
asking for a United States Social Security Number that would also need
to respect the formatting of, say, a citizen ID number from Turkey.
An SSN request has to be for a U.S. application. If a local (NY for me)
government organization, or a bank, accountant or lawyer, commissioned
me to write an application that required SSNs, and I asked them if
Turkish ID numbers were important, what do you think they would say?
SSNs are by definition U.S.-centric.
Jerry Stuckle
Show me of web site which asks for a U.S. SSN. Specifics, please.
Yes, they are U.S. centric - as is your thinking. And yes, the bank may
very well want the Turkish ID number, if the person is a Turkish citizen
legally residing in N.Y. and opening an account there.
You keep proving - you think the world revolves around the U.S. It doesn't.
Jerry Stuckle
> Jerry Stuckle wrote:
>> And it is much easier to just store them as strings - with the
>> punctuation intact.
>
> to another system, it might be easier not to have them in.
> With phonenumbers it is much easier not to have them in. e.g. in Belgium
> a cell phonenumber can be written in several ways:
> +32479123456
> 0479/12.34.56
> 0479/123.456
> +32 (0) 479/123.457
> and any variotion of them.
>
> Furthermore we are only interested in Belgian cellphone numbers as we
> use them to send an SMS. So what we do is see that the formating is
> 479123456 We add the +32 ourselves.
>
> In the entry you can only enter numbers. We remove the +32 or the 0. We
> also check if the number is long enough and if the first three
> characters are from a cellphone prefix.
>
> This all so afterwards automated sending is much easier.
> Display afterwards is 0479/123456 as this easier for the people.
>
> So it all depends on what you need to do with the data afterwards.
>
> houghi
So what do you do when you need to display it back to the user - run
them through hoops trying to understand a completely different format
than what they are used to? For instance, they enter it as
"0479/12.34.56". Now they want to update it - you're going to redisplay
it as +320479123456? Or even 0479123456? Neither seems very user
friendly to me.
If the application requires special formatting, i.e. numeric only to
send an SMS, the application should format the data in the method
required. Data should be displayed in the format the user is familiar with.
Doug Miller
>Beauregard T. Shagnasty wrote:
>> Jerry Stuckle wrote:
>>
>>> Beauregard T. Shagnasty wrote:
>>>> Jerry Stuckle wrote:
>>>>> Go ahead with your U.S.-centric programming.
>>>> You seem to have missed the point.
>>> Not at all. I completely understand your attitude.
>>
>> No you don't. Not at all.
>>
>>> Unfortunately, all too common in many U.S. programmers.
>>
>> Tell me how many applications (or even web pages!) that *would* be
>> asking for a United States Social Security Number that would also need
>> to respect the formatting of, say, a citizen ID number from Turkey.
>>
>> An SSN request has to be for a U.S. application. If a local (NY for me)
>> government organization, or a bank, accountant or lawyer, commissioned
>> me to write an application that required SSNs, and I asked them if
>> Turkish ID numbers were important, what do you think they would say?
>>
>> SSNs are by definition U.S.-centric.
>>
>
>Show me of web site which asks for a U.S. SSN. Specifics, please.
Various subpages under usajobs.com, for one -- pretty much any page where you
apply for a job with either state or Federal government.
On-line filing for Indiana state income tax returns
https://secure.in.gov/apps/dor/ifile/2008/
and presumably similar sites for other states as well.
>
>Yes, they are U.S. centric - as is your thinking. And yes, the bank may
>very well want the Turkish ID number, if the person is a Turkish citizen
>legally residing in N.Y. and opening an account there.
No it won't. A U.S. bank doesn't care about foreign tax ID numbers. They only
care about U.S. tax ID numbers.
>
>You keep proving - you think the world revolves around the U.S. It doesn't.
>
And you keep missing the point. Either you're being deliberately
argumentative, or you're just stupid.
Doug Miller
*Do* try to pay attention, Stuckup. He already said how they redisplay it.
>
>If the application requires special formatting, i.e. numeric only to
>send an SMS, the application should format the data in the method
>required.
It's clear that he already knows that.
> Data should be displayed in the format the user is familiar with.
Glad you finally grasped that concept.
If you try just a little harder, you might grasp the further concept that data
should also be *entered* "in the format the user is familiar with" and
transformed by the software into whatever format the software wants it in --
as opposed to requiring the user to enter it in that format.
Beauregard T. Shagnasty
[about Jerry]
> And you keep missing the point. Either you're being deliberately
> argumentative, or you're just stupid.
I'd go with:
the former = 87%
the latter = 53%
--
-bts
-In a broadband world, Jerry is just a dialup
Peter H. Coffin
It warms my heart to see such faith in users *entering* the punctuation
correctly in the first place, even for their own phone numbers. (: Even
just in the US, you'll mixes of "(312) 555-4444" and "312-555-4444",
and it's expensive and a hassle to match or look up by those. They're
not even the same LENGTH. Strip out the puctuation, and store what's
left in your table, and your match rate skyrockets. Add in the country
code to ensure that you're not dealing with an 8-digit number in The
Neatherlands, and you're good for world-wide uniqueness.
--
56. My Legions of Terror will be trained in basic marksmanship. Any who
cannot learn to hit a man-sized target at 10 meters will be used
for target practice.
Peter H. Coffin
> In Europe it is always very easy to make the difference between a
> cellphone and a land line. I do not know if that is the case in the
> USofA.
Not at all. It's actually rather difficult to reliably determine which
numbers are cells and which aren't. There's the NANPA central office
assignment list, which will narrow down groups of 10,000 numbers to what
telephone company owns the block, which means one can make a guess at
whether a phone number is a cellphone or not, but it's still a guess
only. "DOBSON CELLULAR SYSTEMS, INC." is pretty clearly a mobile
provider, but "GCI COMMUNICATION CORP. DBA GENERAL COMMUNICATION" is a
little less clear. Then there's the matter that phone numbers can be
moved between providers, given some really slow paperwork.. A list of
relevant links to tables, files, and documentation can be had from
http://www.nanpa.com/reports/reports_cocodes.html
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -Justice Louis D. Brandeis
Doug Miller
>Doug Miller wrote:
>[about Jerry]
>> And you keep missing the point. Either you're being deliberately
>> argumentative, or you're just stupid.
>
>I'd go with:
> the former = 87%
> the latter = 53%
>
I think I'd agree.
The Natural Philosopher
what took you so long?
Jerry, the man who read the manual, once, consistent top poster to here,
and the mysql group, 50% of which are 'go away, this post doesn't belong
here, and 90% of the rest are telling other people how stoopid they are.
I've never seen him post a line of code, and I wonder what he does for a
living, as he seems to spend his time trolling usenet.
He's tucked up snugm in my kill file now. One of the very few its not
worth listening to or discussing anything with.
Doug Miller
It's impossible to discuss anything with Stuckup. He can't accept the
possibility that anyone else might have a legitimate opinion that differs from
his own, so he heaps vulgar abuse upon anyone who disagrees with him.
Poor sad little man. So insecure. And so very arrogant, with so little reason
to be.
Jerry Stuckle
> In article <hgqdjd$mlg$2...@news.eternal-september.org>, Jerry Stuckle <jstu...@attglobal.net> wrote:
>> Beauregard T. Shagnasty wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> Beauregard T. Shagnasty wrote:
>>>>> Jerry Stuckle wrote:
>>>>>> Go ahead with your U.S.-centric programming.
>>>>> You seem to have missed the point.
>>>> Not at all. I completely understand your attitude.
>>> No you don't. Not at all.
>>>
>>>> Unfortunately, all too common in many U.S. programmers.
>>> Tell me how many applications (or even web pages!) that *would* be
>>> asking for a United States Social Security Number that would also need
>>> to respect the formatting of, say, a citizen ID number from Turkey.
>>>
>>> An SSN request has to be for a U.S. application. If a local (NY for me)
>>> government organization, or a bank, accountant or lawyer, commissioned
>>> me to write an application that required SSNs, and I asked them if
>>> Turkish ID numbers were important, what do you think they would say?
>>>
>>> SSNs are by definition U.S.-centric.
>>>
>> Show me of web site which asks for a U.S. SSN. Specifics, please.
>
> Various subpages under usajobs.com, for one -- pretty much any page where you
> apply for a job with either state or Federal government.
>
Which require U.S. citizenship.
> On-line filing for Indiana state income tax returns
> https://secure.in.gov/apps/dor/ifile/2008/
> and presumably similar sites for other states as well.
>> Yes, they are U.S. centric - as is your thinking. And yes, the bank may
>> very well want the Turkish ID number, if the person is a Turkish citizen
>> legally residing in N.Y. and opening an account there.
>
> No it won't. A U.S. bank doesn't care about foreign tax ID numbers. They only
> care about U.S. tax ID numbers.
Then they don't request SSN's, do they?
>> You keep proving - you think the world revolves around the U.S. It doesn't.
>>
> And you keep missing the point. Either you're being deliberately
> argumentative, or you're just stupid.
No, I'm not missing the point. And I don't miss the point that you're
just trolling.
Jerry Stuckle
> Jerry Stuckle wrote:
>>> This all so afterwards automated sending is much easier.
>>> Display afterwards is 0479/123456 as this easier for the people.
>> So what do you do when you need to display it back to the user - run
>> them through hoops trying to understand a completely different format
>> than what they are used to?
>
>
I did. And you're redisplaying it in a way they aren't use to seeing it.
>> For instance, they enter it as
>> "0479/12.34.56". Now they want to update it - you're going to redisplay
>> it as +320479123456? Or even 0479123456? Neither seems very user
>> friendly to me.
>
> 0479/123456 on the display for the person to read. Not very hard to
> transform 479123456 into that. Add a 0 in front and place a / after the
> third character that comes out of the database.
>
And what if they entered it in another format they're more familiar
with, such as 0479/12.34.56? You, yourself said there are multiple
formats in common use.
> We had a discussion as to wether it would be better to use 0479/123.456,
> 0479/12.34.56 or 0479/123456
> The second is more often used, but some use the first. This can be
> confusing when you need to verify a number.
> e.g. twelve thirtyfour fiftysix is the same as
> hundredtwentythree, fourhundredfiftysix.
>
Best would be the way the user is familiar with - that is, the way they
entered it in the first place.
> It becomes even more confusing when you read one and hear the other. As
> an extra difficulty we have Dutch and French which is not evident, so
> that is the reason we decided to go for 0479/123456
>
Which is not very user friendly.
> These were meetings where many of the technical people had an issue,
> because they thought meetings are timewasters. Although they are often
> right, sometimes a meeting of one hour will save many hours in the long
> run.
>
In this case, I think they were write. They came up with a bad decision.
>> If the application requires special formatting, i.e. numeric only to
>> send an SMS, the application should format the data in the method
>> required. Data should be displayed in the format the user is familiar with.
>
> I agree and that is what we do. My post re-explains the difference
> between data entry, data verification, data storage, data display and
> automated data usage.
>
But that's not what you're doing. You're displaying the data in the way
YOU want, not what the user is familiar with.
> It also explains that we are very (extremely) one-country minded. We do
> not want to do business with other countries or people who are in other
> countries. This because of various reasons. Among them legal and
> contractual.
>
That's fine. But it still doesn't excuse reformatting the data in a way
not familiar to the user.
> In other countries we have similar systems for their individual
> countries. I can only discuss what we did in Belgium. In other countries
> they have done different things.
>
And you do it in the same unfriendly way?
> In Europe it is always very easy to make the difference between a
> cellphone and a land line. I do not know if that is the case in the
> USofA.
>
There are several formats use in the U.S. Most common are probably,
(123) 456-7890, 123-456-7890 and 123.456.7890.
> Obviously other situations will require other solutions. There is not
> one single correct solution for all situations.
>
> houghi
Sure there is. Redisplay the phone number in the way the user entered it.
Jerry Stuckle
> On Mon, 21 Dec 2009 22:50:44 -0500, Jerry Stuckle wrote:
>> Peter H. Coffin wrote:
>>> If they're all stored with country codes, city codes, and all the rest
>>> of the complete information necessary to dial it per ITU-T E.164, then
>>> you have all the information necessary to know WHICH format to use.
>>> You'll need the formats, of course, but many of them are detailed at
>>>
>>> http://en.wikipedia.org/wiki/Local_conventions_for_writing_telephone_numbers
>>>
>>> and working them up in a nice collection of sprintf() becomes an
>>> exercise of an hour or two.
>>>
>> And it is much easier to just store them as strings - with the
>> punctuation intact.
>
> It warms my heart to see such faith in users *entering* the punctuation
> correctly in the first place, even for their own phone numbers. (: Even
> just in the US, you'll mixes of "(312) 555-4444" and "312-555-4444",
> and it's expensive and a hassle to match or look up by those. They're
> not even the same LENGTH. Strip out the puctuation, and store what's
> left in your table, and your match rate skyrockets. Add in the country
> code to ensure that you're not dealing with an 8-digit number in The
> Neatherlands, and you're good for world-wide uniqueness.
>
If you need to search on a number, simply use a trigger an store the
number in an easy-to-search format. It's quite simple, really.
Doug Miller
Incorrect.
>
>> On-line filing for Indiana state income tax returns
>> https://secure.in.gov/apps/dor/ifile/2008/
>> and presumably similar sites for other states as well.
>>> Yes, they are U.S. centric - as is your thinking. And yes, the bank may
>>> very well want the Turkish ID number, if the person is a Turkish citizen
>>> legally residing in N.Y. and opening an account there.
>>
>> No it won't. A U.S. bank doesn't care about foreign tax ID numbers. They only
>> care about U.S. tax ID numbers.
>
>Then they don't request SSN's, do they?
Yes, actually, they do. If you don't have an SSN, then you provide your TIN as
a substitute. And if you don't have either, then you can't open an account.
All of which is beside the point: U.S. banks don't care about non-US
identifying numbers.
>
>>> You keep proving - you think the world revolves around the U.S. It doesn't.
>>>
>> And you keep missing the point. Either you're being deliberately
>> argumentative, or you're just stupid.
>
>No, I'm not missing the point. And I don't miss the point that you're
>just trolling.
>
Ah, I see: deliberately argumentative *and* stupid.
Doug Miller
>Peter H. Coffin wrote:
>> It warms my heart to see such faith in users *entering* the punctuation
>> correctly in the first place, even for their own phone numbers. (: Even
>> just in the US, you'll mixes of "(312) 555-4444" and "312-555-4444",
>> and it's expensive and a hassle to match or look up by those. They're
>> not even the same LENGTH. Strip out the puctuation, and store what's
>> left in your table, and your match rate skyrockets. Add in the country
>> code to ensure that you're not dealing with an 8-digit number in The
>> Neatherlands, and you're good for world-wide uniqueness.
>>
>
>If you need to search on a number, simply use a trigger an store the
>number in an easy-to-search format. It's quite simple, really.
>
An easy-to-search format like... like... oh, maybe 3125554444 -- in other
words, user input with the obvious punctuation characters stripped out. It's
quite simple, really. Simple enough that even you should be able to grasp it,
Stuckup.
Peter H. Coffin
> Peter H. Coffin wrote:
>> On Mon, 21 Dec 2009 22:50:44 -0500, Jerry Stuckle wrote:
>>> Peter H. Coffin wrote:
>>>> If they're all stored with country codes, city codes, and all the rest
>>>> of the complete information necessary to dial it per ITU-T E.164, then
>>>> you have all the information necessary to know WHICH format to use.
>>>> You'll need the formats, of course, but many of them are detailed at
>>>>
>>>> http://en.wikipedia.org/wiki/Local_conventions_for_writing_telephone_numbers
>>>>
>>>> and working them up in a nice collection of sprintf() becomes an
>>>> exercise of an hour or two.
>>>>
>>> And it is much easier to just store them as strings - with the
>>> punctuation intact.
>>
>> It warms my heart to see such faith in users *entering* the punctuation
>> correctly in the first place, even for their own phone numbers. (: Even
>> just in the US, you'll mixes of "(312) 555-4444" and "312-555-4444",
>> and it's expensive and a hassle to match or look up by those. They're
>> not even the same LENGTH. Strip out the puctuation, and store what's
>> left in your table, and your match rate skyrockets. Add in the country
>> code to ensure that you're not dealing with an 8-digit number in The
>> Neatherlands, and you're good for world-wide uniqueness.
>>
>
> If you need to search on a number, simply use a trigger an store the
> number in an easy-to-search format. It's quite simple, really.
Exactly. That's what I've been saying, without bothering about the
trigger part, and instead doing it in the application code.
'cause it's a PHP newsgroup, after all. (;
--
83. If I'm eating dinner with the hero, put poison in his goblet, then
have to leave the table for any reason, I will order new drinks for
both of us instead of trying to decide whether or not to switch
with him. --Peter Anspach's list of things to do as an Evil Overlord
Jerry Stuckle
And a TIN has a completely different format. So your SSN formatting
doesn't work.
> All of which is beside the point: U.S. banks don't care about non-US
> identifying numbers.
Again, U.S. centric programmer thinking. Here's a tip for you - banks
DO care about non-US identifying numbers. For instance, here in DC we
have a huge number of foreign nationals. My next door neighbor happens
to be from France. Yet they use the same bank I do.
>>>> You keep proving - you think the world revolves around the U.S. It doesn't.
>>>>
>>> And you keep missing the point. Either you're being deliberately
>>> argumentative, or you're just stupid.
>> No, I'm not missing the point. And I don't miss the point that you're
>> just trolling.
>>
> Ah, I see: deliberately argumentative *and* stupid.
The troll shows his stupidity - once again.
Jerry Stuckle
> Jerry Stuckle wrote:
>> I did. And you're redisplaying it in a way they aren't use to seeing it.
>
> "02/1234567" and for a GSM "0472"/123456" There are also fixed numbers
> "04/1234567" with or without dots is not an issue.
>
You're now contradicting yourself. Earlier you said:
"...in Belgium a cell phonenumber can be written in several ways:
+32479123456
0479/12.34.56
0479/123.456
+32 (0) 479/123.457
and any variotion of them."
So there is not just one way to write the number.
>> And what if they entered it in another format they're more familiar
>> with, such as 0479/12.34.56? You, yourself said there are multiple
>> formats in common use.
>
> So customer puts in 0479/12.34.56. PHP puts that into the database as
> 479123456. When the SMS system wants to use that, it is turned into
> +32479123456. When the website needs to display it for a user, it will
> be 0479/123456
>
Which is not in the format the user is use to. Not user friendly, at all.
>> Best would be the way the user is familiar with - that is, the way they
>> entered it in the first place.
>
> You are asuming that the user and the person doing the data entry are the
> same person. That is incorrect. All people are familiar with both the
> ones with dots and the ones witout dots and with the dots on different
> places.
>
The user IS usually the person doing the data entry. People sign up on
web sites all the time - it's not normal for them to be signed up for
something (unless it's a spammer). But if you have a group of people
entering numbers for everyone, then they should have instructions on how
to enter.
>>> It becomes even more confusing when you read one and hear the other. As
>>> an extra difficulty we have Dutch and French which is not evident, so
>>> that is the reason we decided to go for 0479/123456
>> Which is not very user friendly.
>
> It is for our users. They were the ones who did the original request to
> do it that way.
>
Again, you're contradicting yourself. Why did you have the meetings?
And I hate to tell you - the customer is NOT always right. And anyone
who uses the excuse "the customer wanted it that way" doesn't understand
that simple point.
>>> These were meetings where many of the technical people had an issue,
>>> because they thought meetings are timewasters. Although they are often
>>> right, sometimes a meeting of one hour will save many hours in the long
>>> run.
>>>
>> In this case, I think they were write. They came up with a bad decision.
>
> So what is YOUR experience in a multilingual situation in Belgium?
>
None specifically Belgium itself - but when working for IBM I had to
take a lot of things into consideration when working with European
customers.
>> But that's not what you're doing. You're displaying the data in the way
>> YOU want, not what the user is familiar with.
>
> Yes I _AM_ displaying it in a format he is familiar with. "prefix slash
> number" with or without dots.
>
Not if he enters it with dots.
>> That's fine. But it still doesn't excuse reformatting the data in a way
>> not familiar to the user.
>
> I would agree if that was the case, which it isn't
>
It's not the way the user entered it, and is most familiar with.
>> And you do it in the same unfriendly way?
>
> No, they use the standard for THEIR country. Not sure what they are. I
> could look it up, but then so could you if you were interested.
>
Or, keep the data in the way they entered it.
>>> In Europe it is always very easy to make the difference between a
>>> cellphone and a land line. I do not know if that is the case in the
>>> USofA.
>>>
>> There are several formats use in the U.S. Most common are probably,
>> (123) 456-7890, 123-456-7890 and 123.456.7890.
>
> That explains a lot. Those are NOT differences in landlines and
> cellphone numbers. They are just phone numbers.
> 04/xxxxxxx is a landline
> 0472/xxxxxx is a cellphone number
>
No, there is no difference between landline an cell phone numbers here.
>>> Obviously other situations will require other solutions. There is not
>>> one single correct solution for all situations.
>> Sure there is. Redisplay the phone number in the way the user entered it.
>
> The user did not enter the data.
>
> houghi
So who did?
Jerry Stuckle
And then you can't redisplay the number in the way the user is familiar.
Doug Miller
Only if you're stupid enough to store it with the punctuation in the field.
Sensible database designers don't do that. Of course, you wouldn't know
anything about sensible design, would you?
>
>> All of which is beside the point: U.S. banks don't care about non-US
>> identifying numbers.
>
>Again, U.S. centric programmer thinking.
No, not "U.S. centric programmer thinging", just responding to another one of
your many incorrect statements.
>Here's a tip for you - banks
>DO care about non-US identifying numbers. For instance, here in DC we
>have a huge number of foreign nationals. My next door neighbor happens
>to be from France. Yet they use the same bank I do.
Using a U.S. TIN, of course.
>
>>>>> You keep proving - you think the world revolves around the U.S. It
> doesn't.
>>>>>
>>>> And you keep missing the point. Either you're being deliberately
>>>> argumentative, or you're just stupid.
>>> No, I'm not missing the point. And I don't miss the point that you're
>>> just trolling.
>>>
>> Ah, I see: deliberately argumentative *and* stupid.
>
>The troll shows his stupidity - once again.
>
Proving my point, Stuckup: you're both deliberately argumentative *and*
stupid.
Doug Miller
>And then you can't redisplay the number in the way the user is familiar.
Just because *you* are too stoopid to figure out how to do that doesn't mean
the rest of the programming world is.
Doug Miller
>
>And a TIN has a completely different format. So your SSN formatting
>doesn't work.
Wrong *again*, dumbass. Were you born this stupid, or did something happen to
you later?
ITIN
An ITIN, or Individual Taxpayer Identification Number, is a tax processing
number only available for certain nonresident and resident aliens, their
spouses, and dependents who cannot get a Social Security Number (SSN). It is a
9-digit number, beginning with the number "9", formatted like an SSN
(NNN-NN-NNNN).
http://www.irs.gov/businesses/small/international/article/0,,id=96696,00.
html#itin
Peter H. Coffin
Sure you can! Every phone number is unique when properly stored, and the
information about where that phone number routes to (a known thing based
on that the routing is all there), and you can use that knowlege to
select an appropriate formatting based on local convention for writing
phone numbers. Do I gotta build you a demo to show you? There's a long
weekend coming up...
--
Windows gives you a nice view of clouds so you can't see any potentially
useful boot time messages.
-- Bill Hay in the Monastery
Jerry Stuckle
And you're going to try to format a TIN the same as an SSN. ROFLMAO!
>>> All of which is beside the point: U.S. banks don't care about non-US
>>> identifying numbers.
>> Again, U.S. centric programmer thinking.
>
> No, not "U.S. centric programmer thinging", just responding to another one of
> your many incorrect statements.
>
Just another case of the troll's stupidity.
>> Here's a tip for you - banks
>> DO care about non-US identifying numbers. For instance, here in DC we
>> have a huge number of foreign nationals. My next door neighbor happens
>> to be from France. Yet they use the same bank I do.
>
> Using a U.S. TIN, of course.
>>>>>> You keep proving - you think the world revolves around the U.S. It
>> doesn't.
>>>>> And you keep missing the point. Either you're being deliberately
>>>>> argumentative, or you're just stupid.
>>>> No, I'm not missing the point. And I don't miss the point that you're
>>>> just trolling.
>>>>
>>> Ah, I see: deliberately argumentative *and* stupid.
>> The troll shows his stupidity - once again.
>>
>
> Proving my point, Stuckup: you're both deliberately argumentative *and*
> stupid.
Yep, you've proven just how stupid you are, troll.
Jerry Stuckle
So, someone enters a number as (123) 456-7890. Someone else enters
their number as 987-654-3210. Please show me how to display both in the
way that user is familiar - after you've stripped all punctuation.
Come on, troll. Do it!
Jerry Stuckle
Yes, someone enters their number as (123) 456-7890. Someone else enters
their number as 987.654.3210. Please show me how you can display each
one in the way they're familiar with - after you've stripped all
punctuation.
--
The Natural Philosopher
Certainly, in the UK the days of 'Mayfair 4092' have long gone, to be
repale initially by 123 45678 and then as exhanges went STDF 01223
456789 etc etc. In fact the groupings have changed at least 5 times in
my lifetime. These days no one really knows and the tendency is to
simply throw the number in an unstructured heap.
Doug Miller
>The troll Doug Miller opened his ass and out came:
>> In article <hgr0qh$u79$2...@news.eternal-september.org>, Jerry Stuckle
> <jstu...@attglobal.net> wrote:
>>
>>> And then you can't redisplay the number in the way the user is familiar.
>>
>> Just because *you* are too stoopid to figure out how to do that doesn't mean
>> the rest of the programming world is.
>
>So, someone enters a number as (123) 456-7890. Someone else enters
>their number as 987-654-3210. Please show me how to display both in the
>way that user is familiar - after you've stripped all punctuation.
Do you ever get tired of showing the world what an idiot you are?
Doug Miller
>And you're going to try to format a TIN the same as an SSN. ROFLMAO!
You're such a fucking idiot, Stuckup. Here, read this. You might actually
learn something from it in two or three days of concentrated study.
"An ITIN, or Individual Taxpayer Identification Number, is a tax processing
number only available for certain nonresident and resident aliens, their
spouses, and dependents who cannot get a Social Security Number (SSN). It is a
9-digit number, beginning with the number "9", formatted like an SSN
(NNN-NN-NNNN)."
http://www.irs.gov/businesses/small/international/article/0,,id=96696,00.
html#itin
Pay particular attention to the last part, stupid Stuckup: "... formatted like
an SSN (NNN-NN-NNNN)."
The Natural Philosopher
That's his main aim. To appear to be the jovial all knowing guru, whilst
lesser men fume.
It would be risible, if the odd person didn't get taken in.
He's just a troll, but he disguises it carefully.
Peter H. Coffin
I'd point out that those are both formats that people familiar with one
would be adequately comfortable and familiar with the other, but WOULD
be thrown by 0123 45-67-890 (group padding with zeros IS common in some
places and people "know" to drop them) or even 1234567890. (Would you
find ANYONE over the age of about four confused by whichever other of
the examples you gave? Seriously? I can't even assert I've got a habit
or preference between the two examples you gave, honestly.) Just because
someone didn't happen to use a format doesn't mean they're not familiar
with it or are uncomforted by seeing it.
--
10. I will not interrogate my enemies in the inner sanctum -- a small
hotel well outside my borders will work just as well.
Doug Miller
>Doug Miller wrote:
>> In article <hgr4vv$d6q$2...@news.eternal-september.org>, Jerry Stuckle
> <jstu...@attglobal.net> wrote:
>>
>>> And you're going to try to format a TIN the same as an SSN. ROFLMAO!
>>
>> You're such a fucking idiot, Stuckup. Here, read this. You might actually
>> learn something from it in two or three days of concentrated study.
>>
>> "An ITIN, or Individual Taxpayer Identification Number, is a tax processing
>> number only available for certain nonresident and resident aliens, their
>> spouses, and dependents who cannot get a Social Security Number (SSN). It is
> a
>> 9-digit number, beginning with the number "9", formatted like an SSN
>> (NNN-NN-NNNN)."
>>
>> http://www.irs.gov/businesses/small/international/article/0,,id=96696,00.
>> html#itin
>>
>> Pay particular attention to the last part, stupid Stuckup: "... formatted
> like
>> an SSN (NNN-NN-NNNN)."
>>
>No good getting angry with the Stuckupple.
Oh, I'm not angry with him -- I just decided to give back some of the abuse he
dishes out so readily. Perhaps a taste of his own medicine may modifiy his
behavior somewhat.
>
>That's his main aim. To appear to be the jovial all knowing guru, whilst
>lesser men fume.
He would do a better job of appearing jovial if he didn't heap vulgar abuse on
anyone who disagrees with him.
Appearing to be an all knowing guru is quite impossible for poor Jerry, I'm
afraid.
Jerry Stuckle
You talking to yourself again, troll?
Jerry Stuckle
> On Tue, 22 Dec 2009 14:03:19 -0500, Jerry Stuckle wrote:
>> Peter H. Coffin wrote:
>>> Sure you can! Every phone number is unique when properly stored, and the
>>> information about where that phone number routes to (a known thing based
>>> on that the routing is all there), and you can use that knowlege to
>>> select an appropriate formatting based on local convention for writing
>>> phone numbers. Do I gotta build you a demo to show you? There's a long
>>> weekend coming up...
>>>
>> Yes, someone enters their number as (123) 456-7890. Someone else enters
>> their number as 987.654.3210. Please show me how you can display each
>> one in the way they're familiar with - after you've stripped all
>> punctuation.
>
> I'd point out that those are both formats that people familiar with one
> would be adequately comfortable and familiar with the other, but WOULD
> be thrown by 0123 45-67-890 (group padding with zeros IS common in some
> places and people "know" to drop them) or even 1234567890. (Would you
> find ANYONE over the age of about four confused by whichever other of
> the examples you gave? Seriously? I can't even assert I've got a habit
> or preference between the two examples you gave, honestly.) Just because
> someone didn't happen to use a format doesn't mean they're not familiar
> with it or are uncomforted by seeing it.
>
So you just force a format of YOUR choosing onto a customer, instead of
allowing the customer to select a format of HIS choosing.
Of course, you obviously think it doesn't matter. But then you just as
obviously don't understand the difference. And there is.
Doug Miller
>The fucking troll Doug Miller opened his ass and out poped:
>> In article <hgr53i$d6q$3...@news.eternal-september.org>, Jerry Stuckle
> <jstu...@attglobal.net> wrote:
>>> The troll Doug Miller opened his ass and out came:
>>>> In article <hgr0qh$u79$2...@news.eternal-september.org>, Jerry Stuckle
>>> <jstu...@attglobal.net> wrote:
>>>>> And then you can't redisplay the number in the way the user is familiar.
>>>> Just because *you* are too stoopid to figure out how to do that doesn't
> mean
>>>> the rest of the programming world is.
>>> So, someone enters a number as (123) 456-7890. Someone else enters
>>> their number as 987-654-3210. Please show me how to display both in the
>>> way that user is familiar - after you've stripped all punctuation.
>>
>> Do you ever get tired of showing the world what an idiot you are?
>
>You talking to yourself again, troll?
>
own.
Jerry Stuckle
You really are confused, aren't you, Dougie? ROFLMAO!
But that's typical of a troll. They get confused so easily. Even
simple English eludes them.
Doug Miller
>The fucking troll Doug Miller opened his ass and out popped:
>> In article <hgrqh7$p8q$2...@news.eternal-september.org>, Jerry Stuckle
> <jstu...@attglobal.net> wrote:
>>> The fucking troll Doug Miller opened his ass and out poped:
>>>> In article <hgr53i$d6q$3...@news.eternal-september.org>, Jerry Stuckle
>>> <jstu...@attglobal.net> wrote:
>>>>> The troll Doug Miller opened his ass and out came:
>>>>>> In article <hgr0qh$u79$2...@news.eternal-september.org>, Jerry Stuckle
>>>>> <jstu...@attglobal.net> wrote:
>>>>>>> And then you can't redisplay the number in the way the user is familiar.
>>>>>> Just because *you* are too stoopid to figure out how to do that doesn't
>>> mean
>>>>>> the rest of the programming world is.
>>>>> So, someone enters a number as (123) 456-7890. Someone else enters
>>>>> their number as 987-654-3210. Please show me how to display both in the
>>>>> way that user is familiar - after you've stripped all punctuation.
>>>> Do you ever get tired of showing the world what an idiot you are?
>>> You talking to yourself again, troll?
>>>
>> No, Jerry, I'm talking to *you*. But you're too stupid to realize that on
> your
>> own.
>
>You really are confused, aren't you, Dougie?
You're the confused one here, Stuckup -- you're so stupid you can't even
figure out I'm talking to you.
You figure out yet how to display a phone number in human-readable form?
The Natural Philosopher
Jerry Stuckle
Poor, poor Dougie. I really feel sorry for you. So confused. Maybe
your mommy can help.
rf
"Jerry Stuckle" <jstu...@attglobal.net> wrote in message
news:hgsr7h$ql1$1...@news.eternal-september.org...
> Poor, poor Dougie. I really feel sorry for you. So confused. Maybe your
> mommy can help.
And so, yet again, a thread degenerates to this fucking slop.
And who, once again, is in the middle of it?
Jerry Stuckle
> Jerry Stuckle wrote:
>>> The format in Belgium is "prefix slash number" so for a fixed number
>>> "02/1234567" and for a GSM "0472"/123456" There are also fixed numbers
>>> "04/1234567" with or without dots is not an issue.
>>>
>> You're now contradicting yourself. Earlier you said:
>>
>> "...in Belgium a cell phonenumber can be written in several ways:
>>
>> +32479123456
>> 0479/12.34.56
>> 0479/123.456
>> +32 (0) 479/123.457
>> and any variotion of them."
>>
>> So there is not just one way to write the number.
>
>
I'm just trying to understand your self-contradictions.
>>>> And what if they entered it in another format they're more familiar
>>>> with, such as 0479/12.34.56? You, yourself said there are multiple
>>>> formats in common use.
>>> So customer puts in 0479/12.34.56. PHP puts that into the database as
>>> 479123456. When the SMS system wants to use that, it is turned into
>>> +32479123456. When the website needs to display it for a user, it will
>>> be 0479/123456
>>>
>> Which is not in the format the user is use to. Not user friendly, at all.
>
> OK, you win, our usersw apparently have no idea what they want.
>
Sure they do. They want the way they enter the data - not a way you
force on them. Quite simple, actually.
>>>> Best would be the way the user is familiar with - that is, the way they
>>>> entered it in the first place.
>>> You are asuming that the user and the person doing the data entry are the
>>> same person. That is incorrect. All people are familiar with both the
>>> ones with dots and the ones witout dots and with the dots on different
>>> places.
>>>
>> The user IS usually the person doing the data entry. People sign up on
>> web sites all the time - it's not normal for them to be signed up for
>> something (unless it's a spammer). But if you have a group of people
>> entering numbers for everyone, then they should have instructions on how
>> to enter.
>
> OK, you win. Apparently I have no idea who is using the system in what
> way and neither do the people who use the system at data entry and data
> exit.
>
Again, self-contradictions. You say you have users - but then say the
users don't enter the data. Which is it?
>>>>> It becomes even more confusing when you read one and hear the other. As
>>>>> an extra difficulty we have Dutch and French which is not evident, so
>>>>> that is the reason we decided to go for 0479/123456
>>>> Which is not very user friendly.
>>> It is for our users. They were the ones who did the original request to
>>> do it that way.
>>>
>> Again, you're contradicting yourself. Why did you have the meetings?
>> And I hate to tell you - the customer is NOT always right. And anyone
>> who uses the excuse "the customer wanted it that way" doesn't understand
>> that simple point.
>
> OK, you win. Apparently I have no idea who or why I hold meetings.
>
Just trying to understand your self-contradictions, again.
>>>>> These were meetings where many of the technical people had an issue,
>>>>> because they thought meetings are timewasters. Although they are often
>>>>> right, sometimes a meeting of one hour will save many hours in the long
>>>>> run.
>>>>>
>>>> In this case, I think they were write. They came up with a bad decision.
>>> So what is YOUR experience in a multilingual situation in Belgium?
>>>
>> None specifically Belgium itself - but when working for IBM I had to
>> take a lot of things into consideration when working with European
>> customers.
>
> OK, you win. You worked fior IBM and that trumps everything.
>
You asked if I had experience. I told you what it was.
>>>> But that's not what you're doing. You're displaying the data in the way
>>>> YOU want, not what the user is familiar with.
>>> Yes I _AM_ displaying it in a format he is familiar with. "prefix slash
>>> number" with or without dots.
>>>
>> Not if he enters it with dots.
>
> Again, you win. Your wisdom is endless.
>
Just trying to understand more of your self-contradictions.
>>>> That's fine. But it still doesn't excuse reformatting the data in a way
>>>> not familiar to the user.
>>> I would agree if that was the case, which it isn't
>>>
>> It's not the way the user entered it, and is most familiar with.
>
> OK again I must not understand what I am doing and neither do any of the
> people who did the requests.
>
I can understand why you feel that way, considering the number of times
you've contradicted yourself. You must really be confused.
>>>> And you do it in the same unfriendly way?
>>> No, they use the standard for THEIR country. Not sure what they are. I
>>> could look it up, but then so could you if you were interested.
>>>
>> Or, keep the data in the way they entered it.
>
> As you worked for IBM you must be right.
>
You asked for my experience. I told you.
>>>>> In Europe it is always very easy to make the difference between a
>>>>> cellphone and a land line. I do not know if that is the case in the
>>>>> USofA.
>>>>>
>>>> There are several formats use in the U.S. Most common are probably,
>>>> (123) 456-7890, 123-456-7890 and 123.456.7890.
>>> That explains a lot. Those are NOT differences in landlines and
>>> cellphone numbers. They are just phone numbers.
>>> 04/xxxxxxx is a landline
>>> 0472/xxxxxx is a cellphone number
>>>
>> No, there is no difference between landline an cell phone numbers here.
>
> That's what she said.
>
And you obviously don't understand the fact there is no way to tell the
difference in the U.S.
>>>>> Obviously other situations will require other solutions. There is not
>>>>> one single correct solution for all situations.
>>>> Sure there is. Redisplay the phone number in the way the user entered it.
>>> The user did not enter the data.
>>>
>>> houghi
>> So who did?
>
> You are abnsolutely right. I had no idea how stupid I was. I hope you
> are a consultant, because I have lots of money and no brain and I would
> like to hire you and if possible take all the decissions for me. You are
> my new God!
>
> houghi
I can understand why you're so confused. Try going back and
understanding why you have contradicted yourself so many times.
Jerry Stuckle
You are.
Gordon Burditt
> Also, please identify what is that 'small list of requirements for
>"never issued" numbers'?
Among other rules, numbers of the form 000-XX-XXXX, XXX-00-XXXX,
and XXX-XX-0000 will never be issued.
I think there are a few numbers that have also been declared invalid
due to massive misuse due to advertising, such as sample cards in
wallets which people thought were their own personal number. I
suspect 123-45-6789 falls in this category.
Social Security numbers should be stored (if you must store them
at all) *encrypted*, with or without the - is a minor issue.
>And, I ask you, also. Please show how you can remove the "-" and
>display the number in a user-friendly format, according to the standards
>of the country involved.
Social Security numbers should not be displayed if it is possible to
avoid it, and in any case, not on insecure (non-SSL) web sites.
I can't think of any good reason to ask for a USA SSN, *or* a Canadian SIN,
*or* an equivalent (if there is one) in another country. And in any
case, you'd need to know which was being given, something you cannot
necessarily tell from the format by looking at it.
One guy who dealt with credit card processing from the merchant
side said a lot of the US-centric behavior of web sites for phone
numbers comes from payment processors. Apparently, some of them
can't handle non-NANP (country code 1) phone numbers. I don't know
how widespread this is. Usually, the sites asking for this info
have no intention of making phone calls to you.
The Natural Philosopher
The Natural Philosopher
> Gordon Burditt wrote:
>> One guy who dealt with credit card processing from the merchant
>> side said a lot of the US-centric behavior of web sites for phone
>> numbers comes from payment processors. Apparently, some of them
>> can't handle non-NANP (country code 1) phone numbers. I don't know
>> how widespread this is. Usually, the sites asking for this info
>> have no intention of making phone calls to you.
>
> and if you don't fill it out, you can not go on. Not all countries have
> states. And then some even only understand zipcodes in the US format.
>
Yep. I've run into that. Just above the box that says 'select country' ;-)
> I would not mind if they would only accept US adresses, but before that
> you can make a selection of countries.
>
EXACVTLY. Americans can be a bit..parochial.. sometimes.
> Most of the time I enter fake adresses in anyway and unless I need some
> verification send to me use abuse@<their domeinname> as email adress.
>
> houghi
MB
> I have never understood this since any programmer can add one line of
> code to remove hyphens and spaces from a number. Are the coders that
> inept, or is there some other issue I am overlooking?
Let the user write his phone number, SSN, zip code, etc etc the way
he/she is used to (don't force any format on the user).
Strip whatever characters that have no meaning (besides readability)
like spaces, hyphens and validate the remaning string if needed.
Store the original string, exactly the way the user entered it.
Also store the string where all meaningless characters have been
stripped out.
Now that you have stored one formatted and one unformatted version of
the phone number / SSN / zip code / whatever, you can:
Use the formatted version when your system wants to talk to external
systems or when you want to make searches or lookups etc.
Use the unformatted version when the user wants to see or edit his/her data.
Use the formatted version but re-add hyphens, spaces, punctuation in the
administration backend where you want readability AND consistency.
Everyone is happy.
Peter H. Coffin
> Mr. Nonsense skrev 2009-12-18 16:24:
>> I have never understood this since any programmer can add one line of
>> code to remove hyphens and spaces from a number. Are the coders that
>> inept, or is there some other issue I am overlooking?
>
> Let the user write his phone number, SSN, zip code, etc etc the way
> he/she is used to (don't force any format on the user).
>
> Strip whatever characters that have no meaning (besides readability)
> like spaces, hyphens and validate the remaning string if needed.
>
> Store the original string, exactly the way the user entered it.
>
> Also store the string where all meaningless characters have been
> stripped out.
Boy, are you gonna have fun when those things fall out of sync. Which
they will, eventually.
--
7. When I've captured my adversary and he says, "Look, before you kill
me, will you at least tell me what this is all about?" I'll say,
"No." and shoot him. On second thought I'll shoot him then say "No."
MB
> On Sat, 02 Jan 2010 14:42:28 GMT, MB wrote:
>> Mr. Nonsense skrev 2009-12-18 16:24:
>>> I have never understood this since any programmer can add one line of
>>> code to remove hyphens and spaces from a number. Are the coders that
>>> inept, or is there some other issue I am overlooking?
>>
>> Let the user write his phone number, SSN, zip code, etc etc the way
>> he/she is used to (don't force any format on the user).
>>
>> Strip whatever characters that have no meaning (besides readability)
>> like spaces, hyphens and validate the remaning string if needed.
>>
>> Store the original string, exactly the way the user entered it.
>>
>> Also store the string where all meaningless characters have been
>> stripped out.
>
> Boy, are you gonna have fun when those things fall out of sync. Which
> they will, eventually.
>
Why would they? Always update both fields at the same time. Never just
one of them. Have one class/method that you use for all updates of the
data. Not "similar" code spread over several files which will be a mess
to maintain. *That* would mean trouble. How hard is it really? I'm
already using this approach since years and it has not failed yet and it
never will as long as I don't do any really stupid mistakes if I ever
make updates to that code in the future.
Peter H. Coffin
Applications don't stay static. And by "application" I don't just mean
"code" but the whole process around which code is written. Not only do
they change, but stuff ends up wanting to hook up to it, make changes,
data's going to get exported to connect up to external processes, get
changed in the external process AND in your locally-managed data set at
the same time, and you're going to have to write rules by which changes
are integrated back into the core data.
--
For their next act, they'll no doubt be buying a firewall running under
NT, which makes about as much sense as building a prison out of
meringue.
-- Tanuki
Jerry Stuckle
Even easier - use triggers to keep them in sync. But if you're going to
use a class anyway, just store it in the way the user wants it, and
reformat it the way your program wants it in the get method of the class.
But there are people here who don't believe you can do either one. You
can easily - it's all in proper design and change management - not
haphazard "code and go".