Dear American Website Owner
2010-03-31
You live in the United States of America. You design all your forms to have a mandatory "State" field. And then you decide it might just be a good idea to sell to the other 95.4% of the world. But you know, most of the world does not use the concept of a "State" all that much.
The moment you put a "country" field in your form, two things should happen:
- you should remove the State field if the country isn't set to U.S.A. or at least make it optional
- you should stop insisting on NANPA-formatted phone numbers (NNN-NNNNNNN)
I write this after wrestling with a number of unbelievably stupid web forms, all of which required me to provide a "State" name (I don't have one), choose from a list of states, or provide a fake phone number just to satisfy a stupid validator routine.
They also need to remove the formatting insisted upon for zip codes!
It's amazing how many times 12345 has to be used.
Just wait until you live in a Swiss canton that has an Umlaut in its name. A whole new fight with credit-card processing forms...
It's amazing how many forms ask for information they don't really need (like my ify american iTunes account) who now think I live in 90210
I am afraid they are not stupid nor careless ... in many cases they're just ignorant.
Usually boils down to a lazy or time constrained programming deck. Sad but true.. I too always wish there was a few more hours in a day.
This will strip uneeded characters and check if the required amount of numerals where entered ie.. 011-222-444-3333=>0112224443333. You can add a 19-22 char limit with CodeIgnitor, repopulate the original entry " 011-222-444-3333 ", and save it as entered.
CodeIgniter_1.7.2/system/libraries/Form_validation.php
// --------------------------------------------------------------------
/**
@@ -1089,6 +1094,12 @@
return (bool)preg_match( '/^[\-+]?[0-9]*\.?[0-9]+$/', $str);
}
+ function numeric_tel($str)
+ {
+ $n = preg_replace('/\D+/', '', $str);
+ return is_numeric($n);
+
+ }
// --------------------------------------------------------------------
Try living in Puerto Rico, which works just like a state in the US postal system, without being one of the states in drop-down lists. Try being in Puerto Rico, watching US shows on your television, because you're *part of the United States*, but not being allowed to watch "US content" on most Websites because Americans are freaking ignorant morons who don't even know their own history.
Oh, and ordering from Amazon and not being permitted to be either domestic *or* foreign, or order electronics, because even though the Post Office charges the same for Puerto Rico or Podunk, Kansas, Amazon (who has people paid to know better) treats you as foreign.
I could go on. I'm pretty sure my point is made, though.
And please allow slashes in addresses, e.g. "2/129 Studley Rd." means "Flat 2, 129 Studley Rd." in Australia.
Well said!
The one that gets me the most is the use of purely numeric dates. For example 04/01/10 to express the first of April, however for many of us that's the forth of January.
It's really annoying when the day is for something like the expiry of a domain name (yes I'm looking at you GoDaddy!) and can easily cause the expiry to be overlooked thinking that it's months away i.e. 02/07/10 is it seventh of Feb, or being British I might think 2nd of July, somewhat of a difference!
All these complaints but i still can't figure out why 99.9% of programming languages are based on the English language.... I can understand the complaints about regex on postal codes and phone numbers. However most of the time there are additional lines for extra address info such as apartment/flat numbers and a way to provide a state/province. I'm sure in other Countries they consider all the tiny details we have in the USA for addresses...
Jesus! I'd never complain about things like this when I do business with people in other Countries.
I wrote a blog post akin to this a while ago: http://www.endswithsaurus.com/2009/07/lesson-in-address-storage.html
Sadly, I think that globalization is an afterthought in most cases, and never really properly considered. After all, the information is out there to make these forms more international so it's not a huge trauma to make that happen. I agree totally with your observations though.
Good luck!
Perhaps a few examples in your article would better illustrate the"proper forms", unless you just like to complain for the sake of complaining...
Of course, being able to handle non ascii chars is one of these things that are somehow not quite common and quite high on my personal issues.
Best ? Display a message about my name, or my phone number "not being a valid one". Please, for the sake of the argument, let us assume I know better what my phone number is. Or name, for that matter, shall we ?
Dear Commenters,
The point of my article was that there are no "proper forms" — the moment you go global you have to accept the fact that you will not be able to validate phone numbers and addresses.
Those of you who criticize me for not suggesting solutions — here's one, which has already been mentioned by others: just make the address a multiline field and let people enter addresses as they see fit. The whole idea of splitting the address into parts dates back to mainframe databases and tabularized data entry forms.
Same goes for telephones — there is only one worldwide format, and that is +countrycode lots-of-numbers. You can kind-of validate those, but you have to do it right — have regularly updated global call routing tables. Is it worth the effort?
As a side note, please note that I never called anyone "stupid". I only called some web forms stupid, which I maintain they are.
How is this an American problem?
@Jan Rychter - Well explained and amen to you.
Urlicht: most e-commerce websites are based in the US and designed by Americans. Hence "Dear American Website Owner". Had we lived in a German-based internet world, I would have written about the lack of a State field in a rigid German address form.
This is a targeting problem. You were not targeted being outside the US. I think things like this will be bad for US sites in the long run. I recently used a fantastic script to find out the user's origin and display a POSTAL code for UK users and so on. Tinker with it below.
<?php
$ip = $_SERVER['REMOTE_ADDR'];
// US IP
//$ip = "66.167.100.59";
// CANADA IP
//$ip = "216.48.80.14";
// UK IP
//$ip = "86.142.205.41";
$url = "http://api.hostip.info/get_html.php?ip=$ip";
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION ,1);
curl_setopt($ch, CURLOPT_HEADER ,0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER ,1);
$result = curl_exec($ch);
curl_close ($ch);
$countryPrefix = substr($result,stripos($result,"(")+1,2);
if((substr_count($result, 'Unknown Country')) || (trim($result) == "") )
{
$d = file_get_contents("http://www.ipinfodb.com/ip_query.php?ip=$ip&output=xml&timezone=false");
//Use backup server if cannot make a connection
if (!$d)
{
$backup = file_get_contents("http://backup.ipinfodb.com/ip_query.php?ip=$ip&output=xml&timezone=false");
$answer = new SimpleXMLElement($backup);
if (!$backup)
return false; // Failed to open connection
}
else
$answer = new SimpleXMLElement($d);
$countryPrefix = $answer->CountryCode;
}
if($countryPrefix == "GB")
$countryPrefix = "UK";
$content = "";
switch($countryPrefix)
{
case 'UK':
$redirectUrl = "http://example1.com";
break;
case 'CA':
$redirectUrl = "http://example.com";
break;
default:
$redirectUrl = "";
break;
}
?>
Here's why: we Europeans are used to filling out foreign forms. If I see a State field:
1. Is it mandatory?
2. If yes, is the first option "Other/Non US"?
3. If no, is the last option "Other/Non US"?
4. If no, choose Alabama.
On the other hand if an American is confronted with a Province field, you loose a conversion.
It would be nice if more sites were able to present distinct options for every single country, minimizing user confusion and making the overall site easier to use. But I guess there's an issue involved with resources. Most sites don't have the manpower to internationalize. I see stupid things like major business sites that force you to put in false data in various form fields because they didn't see a non-American using the site. Another bad example is how DirtyPhoneBook forces you to use American phone number formats. These things really can detract from my enjoyment of a website.
C'est la vie.
90210 is classic. Being brazilian, that's the only zip code I actually know.
Very good post.
Consider the possibility that a US-centric form may be purposely used to exclude foreign addresses. It's usually due to shipping and/or banking fees. But there are other reasons such as the existing customer database will not handle international accounts and the low incidence of foreign sales wouldn't cover the costs of a rewrite. I know of several organizations that screen by forcing the zip code format.
I'm a UK expat living in the Netherlands. This was a problem when I lived in the UK but, alas, not a huge issue. Now even I hate my new address.
I just discovered a seemingly-comprehensive Wikipedia article that lists address formats by country.
Should come in handy.
rcjordan: yes, I have considered that possibility — but I don't think that's the case. It would be much easier to just let people know their business isn't welcome than have them go through the hassle of fighting validators on address forms. I think it's just a lack of imagination, which is why I wrote the article. I hope now at least a few more people will understand the issue.
Re: Dates. There is an international standard for time and date formatting, ISO 8601 -- use it! It is as unambigous as possible and by far the easiest to understand and parse. (In short: Most significant date first, just like with the decimal system in maths.)
This is my great pleasure to visit your website and to enjoy your excellent post here. Thank you for sharing with us.
Parsing and formatting of telephone numbers for more than 200 countries:
Google's library for dealing with telephone numbers.
Initial code for Java, with a direct port to JavaScript.
A port to C++ is planned for 2011/Q1.
Other people are working on ports to PHP, Ruby and Python.