Re: [PHP] global address collection

2008-01-08 Thread Satyam

Actually, phone numbers should not be prefixed with 00.  The prefix for
international dialing depends on the local phone regulations and it is
different in different countries (for example, 011 in the USA).  The
recommendation from the telephone union (http://www.itu.int/) is to use  a
plus sign to indicate that the phone number starts with the country prefix.
Thus, it would be: +44 1623 123456 or +1 408 555 1212.  Americans also get
often confused because the first 1 is both the country code for the US,
Canada and a good chunk of the Caribbean and it is, at the same time, the
prefix they use to dial national long distance.  That's why the + is
important.

In most of the world, the leading zeros are like ../.  You can thing of 
local phone numbers as your current directory.  If you want to dial another 
area code, you first dial a zero, which is like using ../ in a file system, 
and then the area code, like the folder for that local number folder.  If 
you want to dial international, you dial 00, which is like doing ../../, 
which gets you to the world root (eventually there might be three zeros to 
dial interplanetary!) and then dial the 'folder name' of the other country. 
Which reminds me of an observation by Arthur C Clarke that once humankind 
becomes an intergalactic civilization each group will lose communication 
with the rest, can you just imagine what phone numbers might be!  (Brits 
always had a peculiar sense of humor)


There is no mandatory format to separate international dialing prefix,
country code, area code and actual number, it is better to have them
separated at least with a blank space, but there is no standard regarding
that and none should automatically impossed, the spacing provided by the
user should be respected.  Once again Americans are use to see their numbers
as 1-408-555-1212 because all their area codes are 3 digits long and all the
local numbers contain 7 digits grouped as 3 and 4, but most countries use a
variable number of digits for area codes so only the person who entered the
number can know how to split it.  Do not delete the whitespace and then
reformat the numbers assuming a fixed format because none actually exists.
Tables of international dialing codes are available just googling around
(for example, http://www.kropla.com/dialcode.htm), it is not a bad idea to
check country against the first part of the phone number but then, a warning
is all you could possibly issue since a person might have a postal address
in, say, Monaco (+377) and a French mobile (+33). I wouldn't imagine that
the Vatican has a separate mobile network from that of Rome so though they
have an international prefix different from that of Italy which they might
use for their land lines, their mobiles are probably Italian.

Also, it should be  Province/County/State, and it should be optional since
some cities are autonomous (usuall federal capital cities), just don't make
it mandatory.  And don't force anything on postal codes.  Some countries
have letters in them and the number of characters varies.  I just hate it
when they ask to enter the full 9 digit zip code.

Satyam


- Original Message - 
From: Richard Heyes [EMAIL PROTECTED]

To: tedd [EMAIL PROTECTED]
Cc: php-general@lists.php.net
Sent: Monday, January 07, 2008 11:56 PM
Subject: Re: [PHP] global address collection


In other words, in the USA we ask for name, address, city, state, zip, 
and phone number. What would be a global equivalent that could cover all 
(or most) address and phone numbers?


Full name (optionally forename/surname)
Address 1
Address 2 (optional)
Address 3 (optional)
Town/City
County/State
Postal/Zip code
Country

Full international phone number (eg. 0044 1623 123456)

--
Richard Heyes
http://www.websupportsolutions.co.uk

Knowledge Base and HelpDesk software
that can cut the cost of online support

** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS **

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



--
No virus found in this incoming message.
Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 
269.17.13/1212 - Release Date: 06/01/2008 22:55





--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread Eric Butera
On Jan 8, 2008 10:08 AM, tedd [EMAIL PROTECTED] wrote:
 I just finished a credit card portion for a site where the programmer
 before me required the customers to enter their credit card number
 without spaces -- why?  It's a simple matter to remove spaces for
 processing -- why throw that responsibility on the user?

I agree that removing spaces really isn't a huge deal, but aside from
that I don't think there should be any other modification.  I've seen
code that will regex out anything but numbers.  I think this is bad
practice because we as programmers should validate, not modify data.
Anything above and beyond that is sticking your neck out too far and
will lead to problems sooner or later.

What if the user mistyped what they intended?  If the script just
validates it will see the user accidently typed in a letter in the
field and re-display it asking for numbers only.  If it strips out the
letters, then you've just sent the potentially invalid number to the
gateway which in the end will be a charge against the client for a
failed attempt.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread tedd

At 3:10 PM +0100 1/8/08, Satyam wrote:

Also, it should be  Province/County/State, and it should be optional since
some cities are autonomous (usuall federal capital cities), just don't make
it mandatory.  And don't force anything on postal codes.  Some countries
have letters in them and the number of characters varies.  I just hate it
when they ask to enter the full 9 digit zip code.

Satyam


Satyan:

Thanks very much for your most detailed global telephone number 
information -- very informative.


I also hate it when forms force you to do something that's not 
necessary. For example:


http://support.theflip.com/generalcustomerservice

requires you to enter your phone number in the format of 
xxx-xxx-, but list their phone number as (888) 222-6689. Using 
that format, they couldn't send themselves a message. Plus they 
advertise 4 hour response yet have failed to answer any of my emails 
sent over the last two weeks.


I had one form recently that said Click the box if the billing 
address and shipping address are the same and then if you clicked 
it, then the form made you fill out both sections -- I went elsewhere 
for my purchase.


I just finished a credit card portion for a site where the programmer 
before me required the customers to enter their credit card number 
without spaces -- why?  It's a simple matter to remove spaces for 
processing -- why throw that responsibility on the user?


The best design for a form comes from using it.

Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread Richard Heyes

The best design for a form comes from using it.


To a certain extent, but I think the best design for a form stems from 
watching someone else use it.


--
Richard Heyes
http://www.websupportsolutions.co.uk

Knowledge Base and HelpDesk software
that can cut the cost of online support

** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS **

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread Lester Caine

Satyam wrote:
Telephone stuff is comprehensive


Also, it should be  Province/County/State, and it should be optional since
some cities are autonomous (usuall federal capital cities), just don't make
it mandatory.  And don't force anything on postal codes.  Some countries
have letters in them and the number of characters varies.  I just hate it
when they ask to enter the full 9 digit zip code.

Another area of difficulty is the SIZE of the 'Address' fields.
While in the UK House number + Postcode should be all that you need, if you 
have named flats in a named building in a development in an area of say 
London, then the address 1/2/3 fields can be quite full. Add commercial 
premises on an industrial state and you get similar problems. Some parts will 
need to be combined on one line, and I'm now finding even 80 character entries 
can be a problem :(

Oh for XML and the ability to add 'extra' 'Address' lines :)


Full name (optionally forename/surname)
Address 1
Address 2 (optional)
Address 3 (optional)
Town/City
County/State
Postal/Zip code
Country

Full international phone number (eg. 0044 1623 123456)


--
Lester Caine - G8HFL
-
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread tedd

At 10:18 AM -0500 1/8/08, Eric Butera wrote:

On Jan 8, 2008 10:08 AM, tedd [EMAIL PROTECTED] wrote:

 I just finished a credit card portion for a site where the programmer
 before me required the customers to enter their credit card number
 without spaces -- why?  It's a simple matter to remove spaces for
 processing -- why throw that responsibility on the user?


I agree that removing spaces really isn't a huge deal, but aside from
that I don't think there should be any other modification.  I've seen
code that will regex out anything but numbers.  I think this is bad
practice because we as programmers should validate, not modify data.
Anything above and beyond that is sticking your neck out too far and
will lead to problems sooner or later.

What if the user mistyped what they intended?  If the script just
validates it will see the user accidently typed in a letter in the
field and re-display it asking for numbers only.  If it strips out the
letters, then you've just sent the potentially invalid number to the
gateway which in the end will be a charge against the client for a
failed attempt.


Understood, and agreed. Generally, don't modify the data provided, 
but rather validate the form of the data. However, white space is a 
different critter in some data and is basically used to help 
customers accurately enter/see their credit card numbers.


It's common for us to more easily identify strings in 3 and 4 
combinations than it is to try to see the entire string at one time. 
Research for this has been around for a long time, please review:


http://symboldomains.com/sperling.html

No relation to me.

If you look at what's required by the credit card company, then you 
can make some valid assumptions. For example, credit card numbers for 
the popular credit card companies do not use anything but numbers in 
the card -- and the number of numbers is constant. As such, you can 
check for a valid credit card number prior to sending it out. There's 
lots of stuff you can do, but you also dig yourself a deeper hole if 
you're wrong.


Cheers,

tedd
--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread Nathan Nobbe
On Jan 8, 2008 10:42 AM, tedd [EMAIL PROTECTED] wrote:

 At 10:18 AM -0500 1/8/08, Eric Butera wrote:
 On Jan 8, 2008 10:08 AM, tedd [EMAIL PROTECTED] wrote:
   I just finished a credit card portion for a site where the programmer
   before me required the customers to enter their credit card number
   without spaces -- why?  It's a simple matter to remove spaces for
   processing -- why throw that responsibility on the user?
 
 I agree that removing spaces really isn't a huge deal, but aside from
 that I don't think there should be any other modification.  I've seen
 code that will regex out anything but numbers.  I think this is bad
 practice because we as programmers should validate, not modify data.
 Anything above and beyond that is sticking your neck out too far and
 will lead to problems sooner or later.
 
 What if the user mistyped what they intended?  If the script just
 validates it will see the user accidently typed in a letter in the
 field and re-display it asking for numbers only.  If it strips out the
 letters, then you've just sent the potentially invalid number to the
 gateway which in the end will be a charge against the client for a
 failed attempt.

 Understood, and agreed. Generally, don't modify the data provided,
 but rather validate the form of the data. However, white space is a
 different critter in some data and is basically used to help
 customers accurately enter/see their credit card numbers.

 It's common for us to more easily identify strings in 3 and 4
 combinations than it is to try to see the entire string at one time.
 Research for this has been around for a long time, please review:


i agree, but rather than using spaces, or allowing them in the input string,
i prefer to have several focused form fields that comprise a larger element.
for example, a credit card number is 4 units of 4 digits.  my preference for
credit card number entry is to have 4 text inputs which take 4 characters
each.
this is not only convenient from a user perspective in the user interface,
but also
on the server side.  its safe to call trim() on each sequence of characters
and
concatenate them.  if any character is not a digit then immediately the data
is known
to  be invalid (obviously additional checks are important as well [and no
more difficult
to perform than if a single form element was used to collect the data]).
ive also seen sites that will use javascript to monitor the character count
in each
of these smaller form elements and move the cursor to the subsequent form
element
once the current one is full.  i have mixed feelings, that generally boil
down to particular
implementations on this design decision; sometimes it works, sometimes it
doesnt.  but
thats up to the designer on a case by case basis.  in general i urge clients
to have
several small form fields when reasonable.  it reduces confusion for the
user, and
headaches for the (server side;)) developer.

-nathan


Re: [PHP] global address collection

2008-01-08 Thread tedd

At 12:56 PM -0500 1/8/08, Nathan Nobbe wrote:

i agree, but rather than using spaces, or allowing them in the input string,
i prefer to have several focused form fields that comprise a larger element.
for example, a credit card number is 4 units of 4 digits.  my preference for
credit card number entry is to have 4 text inputs which take 4 
characters each.
this is not only convenient from a user perspective in the user 
interface, but also
on the server side.  its safe to call trim() on each sequence of 
characters and
concatenate them.  if any character is not a digit then immediately 
the data is known
to  be invalid (obviously additional checks are important as well 
[and no more difficult

to perform than if a single form element was used to collect the data]).
ive also seen sites that will use javascript to monitor the 
character count in each
of these smaller form elements and move the cursor to the subsequent 
form element
once the current one is full.  i have mixed feelings, that generally 
boil down to particular
implementations on this design decision; sometimes it works, 
sometimes it doesnt.  but
thats up to the designer on a case by case basis.  in general i urge 
clients to have
several small form fields when reasonable.  it reduces confusion for 
the user, and

headaches for the (server side;)) developer.

-nathan


Ahh yes, an excellent idea.

Thanks,

tedd
--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread Richard Heyes

Nathan Nobbe wrote:

On Jan 8, 2008 2:04 PM, Richard Heyes [EMAIL PROTECTED] wrote:


this is not only convenient from a user perspective in the user
interface, but also
on the server side.

It's not so convenient when you consider Google (and presumably others)
toolbars auto fill.



fortunately i dont have those installed ;)


Why is that fortunate? I find the Google toolbar very useful. Besides, 
your users might be using it. Anything you can do to increase the 
usability of your site should be done IMO.


--
Richard Heyes
http://www.websupportsolutions.co.uk

Knowledge Base and HelpDesk software
that can cut the cost of online support

** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS **

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread Per Jessen
Richard Heyes wrote:

 Nathan Nobbe wrote:
 On Jan 8, 2008 2:04 PM, Richard Heyes [EMAIL PROTECTED] wrote:
 
 this is not only convenient from a user perspective in the user
 interface, but also
 on the server side.
 It's not so convenient when you consider Google (and presumably
 others) toolbars auto fill.
 
 
 fortunately i dont have those installed ;)
 
 Why is that fortunate? I find the Google toolbar very useful. Besides,
 your users might be using it. Anything you can do to increase the
 usability of your site should be done IMO.

Trying to think of (and maybe even accommodate) what non-standard and
third-party tools your potential user may or may not have installed,
goes a bit too far, IMO.  


/Per Jessen, Zürich

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread Richard Heyes
this is not only convenient from a user perspective in the user 
interface, but also

on the server side.


It's not so convenient when you consider Google (and presumably others) 
toolbars auto fill.


--
Richard Heyes
http://www.websupportsolutions.co.uk

Knowledge Base and HelpDesk software
that can cut the cost of online support

** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS **

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread Nathan Nobbe
On Jan 8, 2008 2:04 PM, Richard Heyes [EMAIL PROTECTED] wrote:

  this is not only convenient from a user perspective in the user
  interface, but also
  on the server side.

 It's not so convenient when you consider Google (and presumably others)
 toolbars auto fill.


fortunately i dont have those installed ;)

-nathan


Re: [PHP] global address collection

2008-01-08 Thread tedd

At 8:23 PM +0100 1/8/08, Per Jessen wrote:

Richard Heyes wrote:


 Nathan Nobbe wrote:

 On Jan 8, 2008 2:04 PM, Richard Heyes [EMAIL PROTECTED] wrote:


 this is not only convenient from a user perspective in the user
 interface, but also
 on the server side.

 It's not so convenient when you consider Google (and presumably

  others) toolbars auto fill.
 


 fortunately i dont have those installed ;)


 Why is that fortunate? I find the Google toolbar very useful. Besides,
 your users might be using it. Anything you can do to increase the
 usability of your site should be done IMO.


Trying to think of (and maybe even accommodate) what non-standard and
third-party tools your potential user may or may not have installed,
goes a bit too far, IMO.



In addition, I don't think that having an auto-fill for a credit card 
number is ideal.


Cheers,

tedd


--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread Richard Heyes

tedd wrote:

At 8:23 PM +0100 1/8/08, Per Jessen wrote:

Richard Heyes wrote:


 Nathan Nobbe wrote:

 On Jan 8, 2008 2:04 PM, Richard Heyes [EMAIL PROTECTED] wrote:


 this is not only convenient from a user perspective in the user
 interface, but also
 on the server side.

 It's not so convenient when you consider Google (and presumably

  others) toolbars auto fill.
 


 fortunately i dont have those installed ;)


 Why is that fortunate? I find the Google toolbar very useful. Besides,
 your users might be using it. Anything you can do to increase the
 usability of your site should be done IMO.


Trying to think of (and maybe even accommodate) what non-standard and
third-party tools your potential user may or may not have installed,
goes a bit too far, IMO.


Without usage stats, and given that it's third party and non-standard, I 
would guess that it's mighty popular (with it bearing the Google brand), 
and therefore worth accommodating.


In addition, I don't think that having an auto-fill for a credit card 
number is ideal.


So? People use it.

--
Richard Heyes
http://www.websupportsolutions.co.uk

Knowledge Base and HelpDesk software
that can cut the cost of online support

** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS **

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-08 Thread Nathan Nobbe
On Jan 8, 2008 2:23 PM, Per Jessen [EMAIL PROTECTED] wrote:

 Richard Heyes wrote:

  Nathan Nobbe wrote:
  On Jan 8, 2008 2:04 PM, Richard Heyes [EMAIL PROTECTED] wrote:
 
  this is not only convenient from a user perspective in the user
  interface, but also
  on the server side.
  It's not so convenient when you consider Google (and presumably
  others) toolbars auto fill.
 
 
  fortunately i dont have those installed ;)
 
  Why is that fortunate? I find the Google toolbar very useful. Besides,
  your users might be using it. Anything you can do to increase the
  usability of your site should be done IMO.

 Trying to think of (and maybe even accommodate) what non-standard and
 third-party tools your potential user may or may not have installed,
 goes a bit too far, IMO.


i agree w/ Per in this case, however, i will say that Richard did make me
curious
enough to do a quick google on the topic.
it seems mostly, form designers have problems w/ the yellow background
colors
google toolbars' autofill feature coats form fields w/.
heres a couple of links in case anybodys interested:
http://code.jenseng.com/google/
http://www.technologyevangelist.com/2006/03/designing_google_too.html
http://www.mediacollege.com/internet/utilities/google/toolbar-autofill.html

i would say, w/ the credit card field in particular, anybody who doesnt
double check
that info before hitting submit deserves any backlash from a mistake.  a
compromise
might be sufficient if a site has a track record of issues w/ users and an
autofill feature.
just posting some paragraph about proper usage or making something clever to
detect
the possible existence of a toolbar.  there may be better ways, but for the
google toolbar
you could set the background color of your forms to a known value, say
#00, then
when the page loads, with javascript you could check the background color of
the form
fields again.  if the color was different, you might then display a general
warning / best
practice notification to the user (and it would have the added bonus of
making your users
think youre smart, like the firebug warning that pops up in gmail now).
at any rate im sure there are scads of these toolbars out there, and even
though there are
a couple of blog articles and maybe even some simple api spec at googles
site, i would
consider it relatively futile to accommodate them into my overall design.
rather, i would
handle them on a case-by-case basis and only then when problems crop up on a
given site.

-nathan


[PHP] global address collection

2008-01-07 Thread tedd

Hi:

What would be a good form (i.e., fields) for collecting global 
addresses and phone numbers?


In other words, in the USA we ask for name, address, city, state, 
zip, and phone number. What would be a global equivalent that could 
cover all (or most) address and phone numbers?


Cheers,

tedd
--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] global address collection

2008-01-07 Thread Nathan Nobbe
On Jan 7, 2008 1:13 PM, tedd [EMAIL PROTECTED] wrote:

 Hi:

 What would be a good form (i.e., fields) for collecting global
 addresses and phone numbers?

 In other words, in the USA we ask for name, address, city, state,
 zip, and phone number. What would be a global equivalent that could
 cover all (or most) address and phone numbers?


i once had to assemble a mapping between several proprietary systems
address conventions and a domestic standard.  i far as i recall, i found the
'official' info on the usps site.
i spent a couple of minutes looking there just now; although i found nothing
on international standards or recommendations, but further searching may
yield something useful.

-nathan


Re: [PHP] global address collection

2008-01-07 Thread Richard Heyes
In other words, in the USA we ask for name, address, city, state, zip, 
and phone number. What would be a global equivalent that could cover all 
(or most) address and phone numbers?


Full name (optionally forename/surname)
Address 1
Address 2 (optional)
Address 3 (optional)
Town/City
County/State
Postal/Zip code
Country

Full international phone number (eg. 0044 1623 123456)

--
Richard Heyes
http://www.websupportsolutions.co.uk

Knowledge Base and HelpDesk software
that can cut the cost of online support

** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS **

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php