in reply to Re: The Perl Review, with cheaper subscription options
in thread The Perl Review, with cheaper subscription options

Snail mail envelope addresses are not structured internationally. Although there is a standard format in the US, and there is one in the Netherlands, they are very different. There are small but significant differences between the different European countries. Americans often find this strange, but they usually don't realise that we don't see Europe as a whole yet. For me, France is as foreign as the US, while people from across the Atlantic sometimes "go to Europe". We don't even go to "Asia" or "Africa". Even though Belgium is at bicycle-distance from where I live, I don't often go there. It's another country. And yes, it feels funny to be able to pay with your own currency in foreign countries :).

But I was going to rant about paper envelopes. As I said, there are different formats. A web developer cannot know all formats, and if they do know all formats, that's not even enough. Not enough, because sometimes someone needs an address written in a specific way to ensure the thing reaches its destination. For example, I let packages be delivered at work. Because multiple companies share one street address, the company name has to be on the envelope. But this doesn't automatically mean I want my company to have anything to do with the purchase.

Dutch addresses have "$street $number", French have "$number $street". Belgium is bilingual and has both these languages and both these formats. But if you think you can have your database handle that, guess again. Some people want to specify it as "$street_dutch $number $street_french", e.g. "Kolonel Bourgstraat 12345 Rue du Colonel Bourg".

Possibly more than zip and state (or equivalents) is needed. Perhaps less is required. We have provinces, not states, but this information is never on the envelope. If your database is international, should it then have a column for each possible piece of information? And a bitfield column to indicate which fields need to be printed? Or something that specifies field order?

Your envelope or package will probably arrive if we fill in your form with weird information, but there's a big chance its delivery is delayed by days.

How to fix this? Well, if you want country and such in your database in separate columns, because you think you can create useful statistics from that, or calculate shipping costs, or whatever, go ahead. But if you want to actually ship something, provide an unrestricted HTML textarea for the full address. Instruct users to enter in it what they want on the envelope, including everything. Make sure they understand that they need to *repeat* the country name if you also let them pick it elsewhere. Optionally, provide a check box "Generate a standard US address from the information provided above".

Textareas aren't used often in order or subscription forms. This is not because it's the wrong solution, but because most people are unaware of the trouble strangely formatted envelopes can cause.

Oh, and names are also a good reason to not use separate columns, or to at least provide a free form input field: Some use "$firstname $lastname", others use "$lastname $firstname" (of course, the variable names firstname and lastnames themselves are flawed), others uc() their $lastname, some people don't have or don't want to let know a certain part of their name. Heck, brian d foy himself knows best how picky people can be about how their name is written :). Some names are one character in size. I once met a boy whose first name was K. Pronounced not Kay, but K, with no vowel. Regardless of what you think of this, this is someone's name, and your form should not assume every name follows a certain format.

Bottom line: provide free form input fields and think twice, no, thrice before making any field mandatory.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

  • Comment on Re^2: The Perl Review, with cheaper subscription options

Replies are listed 'Best First'.
Re^3: The Perl Review, with cheaper subscription options
by brian_d_foy (Abbot) on Dec 07, 2004 at 23:38 UTC

    That's a good idea, and that's probably what I am going to do when I get a chance to change the form. This change trickles down to other parts of the workflow too, so it's going to take a couple of days to make it happen.

    I did find a manual that explains the format for every country, but it costs 600 euros. That's a bit more than I can afford, so maybe it just needs an open source project to make that sort of thing free.

    The big, scary problem with free form text entries is credit card fraud, and that's my first concern with validating input. Although most people will just format the address that they already entered in the other parts, some people will want to enter a completely different address. The credit card companies consider my business "high risk" right now because I'm new and I deliver things on the internet. Shipping to addresses other than the mailing address of the credit card raises that risk in their eyes. Big companies can eat the fraudulent charges, but I can't.

    Not that it matters to any customers though, and it's a problem I still want to solve. It is not wholly a technical problem though.

    --
    brian d foy <bdfoy@cpan.org>

        A useful online resource: International Mailing Address Formats.

        Perhaps it'd be useful if it were correct. A Dutch address should have "$postcode  \U$city\E", indeed with double whitespace in between.

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      maybe it just needs an open source project to make that sort of thing free.

      That is definitely needed. Unfortunately, it's one of those problems like dates and encodings: a twisty maze of little exceptions all alike. That's not something that lends itself to the usual open source processes. As bad luck would have it, this is also a problem that people are less likely to come across than encodings, let alone dates. It is mostly businesses which are affected. It would be great to codify this knowledge Regexp::Common style — but it will require some very dedicated people to do a lot of thankless and mostly unnoticed work before the ball gets rolling.

      Makeshifts last the longest.

Re^3: The Perl Review, with cheaper subscription options
by hv (Prior) on Dec 08, 2004 at 11:42 UTC

    Amen to all that - my work application has a freeform address field with only postcode and country as separate fields, and even that is too much separation.

    And I've lost count of the number of times I've filled in my surname on a web form only to be told "your name cannot contain spaces". :(

    Hugo