[thelist] international friendly form

Mike Hardaker mike at angloinfo.com
Tue Feb 6 19:27:32 CST 2001


> But, there's really no way to have an effective form that's
> generic enough.

The answer is not to use a single form, unfortunately.

As someone who has lived in a lot of countries, I get really fed up when a
form insists on a format that seems generic to its developer, but is not to
me. Like it or not, the Web is a universe where it's essential to do what
the *user* wants, and then (somehow) format that into a way that the client
finds acceptable.

For example: I now live in France. In France, we have *départements*, which
map roughly on to States. However, we don't use them, as our postal code
(*not* zipcode) tells anyone who cares what our *département* is. So my
postal code is 06140, which makes it vey clear that I live in département
06, r the Alpes-Maritimes.

(The xx140 merely directs you to my postal sorting centre, incidentally, one
which covers several "communes").

Nevertheless, I often have to fill in online forms which require me to enter
my State/Region/County or some other such construct. If I do so (and much
form validation insists on it) I will get letters sent to:

	Mr. M Hardaker
	nnnn Rte de la ssssss [street address]
	ccc ccccc cccccc [my commune]
	dddd-dddddd [my département]
	pppppp [my postal code]

Such a letter is almost certain to arrive about two weeks later than with a
properly-formatted envelope to:


	Mr. M Hardaker
	nnnn Rte de la ssssss
	pppppp ccc ccccc cccccc
	FRANCE

Send me an invoice or a product this late, and I will be vexed.

Therefore, I think a form should be in two parts.

Firstly, get the user's country - mayby this is already stored in a cookie
to speed things up. If not, simply say: Where do you live? [Next].

Secondly, ask for information that is *meaningful to the user*, which may
mean a separate form for each user (and let's not forget language groups - I
am, after all, an anglophone in France, and not unique as such).

Then comes the hard bit - all this stuff has to be in a flexible enough
database that it can be formatted appropriately. It's not that tricky. In
very crappy pseudo-ASP, for example, you might have reporting code that
looks like this:

<% Select Case CountryCode
	Case "33" '(France)
		response.write streedaddr & "<br>"
		response.write zipcode & " " & city & "<br>"
		response.write GetCountry(33)
	Case "44" '(UK)
		response.write streedaddr & "<br>"
		response.write city & "<br>"
		response.write zipcode & "<br>"
		response.write GetCountry(33)
	Case etc...
End Select %>

Equally, if you want to know where people live, you write back-end code that
goes something like:

<% If CountryCode = "33" and left(recordset(zipcode, 2) = "06" Then Dept =
"Alpes-Maritimes" %>

As I say, it's not hard, even though it's hard work (and that, I'm afraid,
comes with the territory). But if you're from the US - as much of this list
is - it's the one way of making the majority of the world's market feel
comfortable.

> You could have a blank box for State/Province which covers everybody, but
> then when culling through the data, it's almost impossible to sort easily:
> some people will enter in "Texas", others will enter in "TX".
> Others won't
> read directions and might enter "Dallas, TX 75201" or whatever.
> How do you
> sort that data?  The drop-down simplifies things.

True - drop-downs do simplify, as long as they don't go too far. I, for
example, do not appreciate having to list my "State" as "other".

> By doing it this way, you're accomodating everybody and making it
> easy (for
> yourself or your client) to sort through the data for where
> you're from (at
> least for an American/Canadian site, I would presume an Australian site
> would do the reverse, a drop-down for New South Wales, etc. and a box for
> other).

Nope - non-American sites (good ones, anyway) tend not to assume that
address structures follow a certain global pattern, or that telephone
numbers are [xxx-xxx-xxxx]. The best of them provide consumer-friendly forms
that can be processed at the server end to provide the information that the
site owner wants, rather than imposing the site-owners requirements on the
consumer.

> And, just so you know, I'm not trying to be an ugly American, I'm
> trying to
> be as practical as possible.  This is about the best solution I can find.
> If bandwidth ever got to a wonderful point (and I had all sorts of time),
> I'd love to have a form where when you chose, say, Spain, it had
> a province
> box containing Catalonia, Sevilla, etc.

Bandwidth has bugger-all to do with it, unless you're doing all of this at
the client (in the sense of "browser" rather and "the person who pays you")
end. The sheer size of the problem forces it into the server-side area.
Write good server code and you will have a lot of lines of ASP, PHP or
whatever, but your bandwidth issues are irrellevant. In fact, they may even
be improved - why, for example, should I download a list of 50-odd US States
and postal options just to select "other"?

It's not about bandwidth - it's about getting the back-end together in a
professional way.

As a non-septic (from the Cockney rhyming-slang "Septic Tank = Yank") I can
get very steamed up about this stuff, so I'm sorry if I've over-written.
However, US coders should remember that, while they are part of the world's
biggest market, that market is still a minority. And If you can't be
bothered to code for the rest of us, well, we might choose to deal with the
people who can.

-------------------
Mike Hardaker
Founder & Publisher
AngloINFO
www.angloinfo.com






More information about the thelist mailing list