5 ms·

Stupid American Website Owners

41 points by johns 17y ago

David 17y ago
The distinction is the expected ratio of US customers to international ones. A significant inconvenience for a select few customers is nowhere near as bad as a small inconvenience for every customer. Also, shipping is _important_. Definitely agree with that point - if you spend all your time making the checkout form internationally friendly, you've already run out of time for your product. You're either irrelevant, hopelessly behind the competition, or completely out of money. Might be viable at a large company, though, where you've got people who are already doing nothing useful.
- joshd 17y ago
  But he doesn't know even what conversion rates he could achieve because he chose to totally ignore non-US billing addresses. He's just assumed that it's not worth his effort. He's talking about a web-based product. There is no reason to require a properly formatted address. When people are trying to give you money you should make things as simple as you can.
  - tghw 17y ago
    Not to be rude, but I think you're having a bit of a reading comprehension problem. Nowhere did I say to block non-US users, as you've repeatedly asserted I did. What I am saying is don't worry too much about getting it right, especially if you plan on targeting US-based users first. If people have to pick a random state because the validation library you used always validates states, but only 5% of your users hit that problem, big deal. You should have a decent analytics package installed, and if you do you'll know what the bounce rates are for your international users, so you can decide if and when there is a business case for doing full i18n and l10n.
mynameishere 17y ago
Very hard to read that website.
- micaelwidell 17y ago
  Yeah, you know, readability is not a feature. Gotta focus on features ;)
- ash 17y ago
  I've recently started using Readability. Works great! http://lab.arc90.com/experiments/readability/ http://lab.arc90.com/experiments/readability/
- tghw 17y ago
  Yeah, it's long overdue for a redesign. Made a couple changes that should make it a bit more readable. Sorry about that.
po 17y ago
I understand the point of this article but... > a credit card form is not a feature It absolutely is. It's a feature that every paying customer will use at least once. I would say if you can't properly support international CC orders/addresses, then make that your policy and don't ask for the country. There's nothing wrong with saying "Sorry, US addresses only" if you don't have the resources to support international. But if you're asking your users what country they live in, you should have all of the machinery in place to properly process it.
- fakelvis 17y ago
  Exactly. If a user is being led to believe that their location is supported, support it. Otherwise make it explicit that it isn't. You are supporting international orders? Spend a few hours making a comprehensive address verification system and reuse it everywhere. Over time the effort expended on this task will hopefully become negligible. Maybe that'll happen after you get your first international order. It's not as if the data aren't freely available. This is the internet, after all (http://en.wikipedia.org/wiki/Address_(geography)#Mailing_address_format_by_country http://en.wikipedia.org/wiki/Address_(geography)#Mailing_add...).
  - sern 17y ago
    "A comprehensive address verification system" does not take a few hours to make. In another comment on this thread I posted a link to an amazingly detailed address format database and I'm quite sure it took longer than that to make. I think this would be an awesome open source project!
    - fakelvis 17y ago
      To clarify: I'm not suggesting that this AVS be made from scratch. That definitely would take, as you say, more than a few hours -- not to mention that it's unnecessary. Finding the rules and data is but a trivial, slightly time-consuming task. I saw your link before posting my previous comment and took this into consideration: someone reading this immediately has a comprehensive DB of address formats. "A few hours" may have been a bit ambitious, but over a weekend, and with the required data already available, creating a back-end solution to this is surely not out of the realms of possibility for a reasonably competent programmer? Have to agree with this being a great idea for an open source project. I had a little look around and the Google Geocoding Web Service (http://code.google.com/apis/maps/documentation/geocoding/ http://code.google.com/apis/maps/documentation/geocoding/) looks like a nice place to start, although most likely outside their ToS. For everyone else, it's determining what's good enough from what's perfect (a good starting point: http://www.endswithsaurus.com/2009/07/lesson-in-address-storage.html http://www.endswithsaurus.com/2009/07/lesson-in-address-stor...). Edited: And the resources on a previous HN posting for this article are helpful, too: http://news.ycombinator.com/item?id=1232042 http://news.ycombinator.com/item?id=1232042
tjmc 17y ago
Hmm what takes more time? An 800 word blog post or adding an "Outside US" option to the select control for "State"?
- deleted 17y ago
  [deleted]
- wooster 17y ago
  There are countries outside the US where the province may be required for proper routing of mail. I'm still working on my address support. It's hard, considering there are more de facto countries than are legally recognized by any international body, and most of them are one-offs in terms of address formatting.
  - tjmc 17y ago
    I live in one of those countries and I think people are over-analysing the problem. I think you're perfectly safe with: Addr 1 (req) Addr 2 (optional) State (req but including "Outside US") Country (req) Post/Zip Code (optional outside US) When I order stuff from the US I just put my city and state in the Addr 2 line. In the end this is a classic example of the "perfect being the enemy of the good". Look at where your sales are going and allocate validation efforts accordingly. A lot of sites include Canadian provinces in the "state" field for example.
    - deleted 17y ago
      [deleted]
    - smikhanov 17y ago
      This piece of advice is so obvious that it makes me wonder why we need to have this discussion in the first place.
    - deleted 17y ago
      [deleted]
- tghw 17y ago
  I didn't have any credit card forms to write, so it's OK, I had the time.
_ivan 17y ago
bla bla
sern 17y ago
Was looking through my history and found this: http://i18napis.appspot.com/address http://i18napis.appspot.com/address It's not clear who owns it, though, so don't just go and use it. My point is that it's worth spending the time (and maybe money) to find one of these databases to make your international customers happy.
jwr 17y ago
I'm the poster of the original article that this responds to. First, please note that I never called anyone stupid or moronic. You did, and I do not know why. I said "stupid forms" and I stand by my opinion. I see why you'd want to validate US addresses properly now, thanks for the explanation. However, I still don't quite understand why you'd want to use the same rules for the rest of the world. Your credit card company cannot possibly validate my address (with zip code) and telephone in a rigid US-based form, because I won't be able to enter my zip code or my telephone into that form. They simply won't fit and validators won't let them through. Also, many systems won't process non-ASCII characters in my street name. Of course, I have been entering crap data into those forms for the last few years when buying online and have yet to see a credit card transaction rejected. Which means you don't have to worry about rejected transactions on out-of-country purchases, which means you might as well give us a reasonable form and not expect us to fight our way through your validators. So why not make two forms -- one for US customers, and one for everyone who chooses a different country? Given your estimates I expect you might even get that done in 2010 :-)
- joshd 17y ago
  "So why not make two forms". Exactly. Have a US form. If the customer selects a non-US country then switch out the state for a freeform "state/territory" field and skip the US-centric validation. All up you might need 10 lines of HTML and server side code. This applies to US-only services too. When trying to book accomodation and flights for a US trip I have heaps of websites refuse my money because I couldn't provide a US billing address. For example it didn't occur to the brain-dead developers of the Disneyland website that tourists be from outsite the US. The problem is developers who seem to think they know what the customer wants. I know because I've done the same thing. If you're relying on your intuition then you are almost certainly wrong.
- tghw 17y ago
  The post is as much a reply to you as it is a reply to your commentors. "Stupid" was used a little more liberally in the comments, and my post just exaggerates that for humor's sake. My main point is that it depends on your audience. For most things I would develop, my primary audience is probably going to be from the US, so I should take that into consideration. If my analytics show a higher percentage of international users than I'd expected, then I can go back and spend more time developing another form for outside the US. It's all a matter of priorities.
henrikschroder 17y ago
This whole post is a false dichotomy, there are more options than "US only" and "Correct for the whole world + validation". If I had mostly US customers, then I would make an address form that had the forms and the validation for US addresses, add a country dropdown, pre-select US in it, and if the user changed it just disable all validation and pass whatever the user enters on to the third parties. That way the international users won't have to try to guess how I want the addresses to validate, but they might run into errors from the third parties, and that validation might be slower, but at least we're down to a bare minimum of requirements. You know how those credit card processors are picky with US addresses? Here's another hint: They can't do international validation either! Just pass in a different country and whatever garble the user entered and you're usually good to go, as long as the credit card number and cvc matches. You know that CC billing address concept? That doesn't exist where I am. My credit cards don't have that. So when I'm asked to provide it, I enter complete garble, and it usually works every time. So don't worry about only giving well-formed data to the CC processors.
- tghw 17y ago
  That's actually kind of what I was trying to say. Having people put in fake data to satisfy a validator isn't the worst problem in the world. There are probably much better things to be spending your time on. And, yeah, in general, CC validation is a complete farce. Depending on how a vendor has set up their payment gateway, sometimes you don't even need a correct CVV or expiration date, much less a correct address...
  - jasonlotito 17y ago
    It actually has less to do with the vendor, and more to do with the acquiring banks. I hate banks with a passion. One time had a customer on the line with us asking why he no longer had access. We explained because he had chargedback the transaction. No, no he did not, he assured us. We called the bank, and found out that he had asked for a chargeback, but it was for another transaction he had problems with, and wanted it corrected. So here we are, my customer service rep, the customer, and the bank on a 3-way call, and the customer is telling the bank to undo the chargeback and give us the money back, and to chargeback the other transaction. And they wouldn't do it. Oh, they applied the chargeback to the other transaction, but the penalty was still applied to us. The customer apologized to us later, and wanted to pay again, and was even willing to pay the chargeback fee. He simply paid again the normal price, and we swallowed the cost. I hate banks.
ErrantX 17y ago
Yeh this is.... something of a foolish rant (it sounds like he's taken personal affront to the original post). He's getting hung up on validating everything when, really, the sensible thing to do is minimum viable validation and leave it at that. Contrary to popular belief credit card companies will handle all sorts of not-quite-right data :)
joshd 17y ago
So lets weigh up the options: A) Let non-US customers enter whatever billing information they want. Accept that a small percentage will fail when we try and charge the credit card. Everyone else is happy and we make more money. B) Explicitly block non-US citzens who are trying to give us money. Oh! Let's choose B.
- tghw 17y ago
  Where exactly in the article did I mention blocking non-US "citizens"? (I think you mean users; most websites don't require citizenship verification.)
kristiandupont 17y ago
I don't understand why you are offended by the original article. It didn't seem offensive to me - he was describing a general frustration which may or may not be valuable feedback to you.
- tghw 17y ago
  No offense was taken in the reading and writing of these two articles. Just trying (and apparently failing) to humorously point out that if most of my users are based in the US, then I probably have bigger problems to solve than a Polish guy having to pick a state at random.
  - jasonlotito 17y ago
    The way to think of it is like so: Most of your users are based in the US because those not in the US can't get in to use your service. =)
    - tghw 17y ago
      It's not that they can't, it's that there's a little more friction for them to. (Speaking of my websites, we've actually done the i18n necessary to make it usable from anywhere, but only after we knew we had that international demand.)
      - jasonlotito 17y ago
        Oh, I'm not talking about your websites. =) I'm just referring to the problem in general. The first moment the craziness of i18n that I experienced was almost 10 years ago, building software for Koreans (I think, not sure, was a long time ago) and after the UI team demoed the product, one of the partners who was pushing this for the Asian market remarked they had to remove the red. Apparently, red is a taboo color or something over in that region.
nosse 17y ago
"Contrary to popular belief credit card companies will handle all sorts of not-quite-right data :)" Actually I thought they would not handle any data if it's not exactly right. I think of myself more web savvy than most dudes out there, running linux and surfing with opera. Still I thought that if I put wrong zip code to the form, I would lose money. Stupid me. I'm from Finland, guess how much I have bought stuff from websites that require me to put zipcode in the billing form. "probably have bigger problems to solve than a Polish guy having to pick a state at random" That polish guy might be the polish guy that markets your product to ten french, one british and two australian guys, and then chain reaction! And the one thing keeping him from doing this is the billing form of your otherwise brilliant product. What I'm telling you is that if you want money, at-least tell people: "pretend you're from Virginia if you're not from U.S." in the billing form. Writing that takes considerably less time than two hours.

41 points by johns 17y ago

David 17y ago

The distinction is the expected ratio of US customers to international ones. A significant inconvenience for a select few customers is nowhere near as bad as a small inconvenience for every customer. Also, shipping is _important_. Definitely agree with that point - if you spend all your time making the checkout form internationally friendly, you've already run out of time for your product. You're either irrelevant, hopelessly behind the competition, or completely out of money. Might be viable at a large company, though, where you've got people who are already doing nothing useful.

joshd 17y ago
But he doesn't know even what conversion rates he could achieve because he chose to totally ignore non-US billing addresses. He's just assumed that it's not worth his effort. He's talking about a web-based product. There is no reason to require a properly formatted address. When people are trying to give you money you should make things as simple as you can.
- tghw 17y ago
  Not to be rude, but I think you're having a bit of a reading comprehension problem. Nowhere did I say to block non-US users, as you've repeatedly asserted I did. What I am saying is don't worry too much about getting it right, especially if you plan on targeting US-based users first. If people have to pick a random state because the validation library you used always validates states, but only 5% of your users hit that problem, big deal. You should have a decent analytics package installed, and if you do you'll know what the bounce rates are for your international users, so you can decide if and when there is a business case for doing full i18n and l10n.

mynameishere 17y ago

Very hard to read that website.

micaelwidell 17y ago
Yeah, you know, readability is not a feature. Gotta focus on features ;)
ash 17y ago
I've recently started using Readability. Works great! http://lab.arc90.com/experiments/readability/ http://lab.arc90.com/experiments/readability/
tghw 17y ago
Yeah, it's long overdue for a redesign. Made a couple changes that should make it a bit more readable. Sorry about that.

po 17y ago

I understand the point of this article but... > a credit card form is not a feature It absolutely is. It's a feature that every paying customer will use at least once. I would say if you can't properly support international CC orders/addresses, then make that your policy and don't ask for the country. There's nothing wrong with saying "Sorry, US addresses only" if you don't have the resources to support international. But if you're asking your users what country they live in, you should have all of the machinery in place to properly process it.

fakelvis 17y ago
Exactly. If a user is being led to believe that their location is supported, support it. Otherwise make it explicit that it isn't. You are supporting international orders? Spend a few hours making a comprehensive address verification system and reuse it everywhere. Over time the effort expended on this task will hopefully become negligible. Maybe that'll happen after you get your first international order. It's not as if the data aren't freely available. This is the internet, after all (http://en.wikipedia.org/wiki/Address_(geography)#Mailing_address_format_by_country http://en.wikipedia.org/wiki/Address_(geography)#Mailing_add...).
- sern 17y ago
  "A comprehensive address verification system" does not take a few hours to make. In another comment on this thread I posted a link to an amazingly detailed address format database and I'm quite sure it took longer than that to make. I think this would be an awesome open source project!
  - fakelvis 17y ago
    To clarify: I'm not suggesting that this AVS be made from scratch. That definitely would take, as you say, more than a few hours -- not to mention that it's unnecessary. Finding the rules and data is but a trivial, slightly time-consuming task. I saw your link before posting my previous comment and took this into consideration: someone reading this immediately has a comprehensive DB of address formats. "A few hours" may have been a bit ambitious, but over a weekend, and with the required data already available, creating a back-end solution to this is surely not out of the realms of possibility for a reasonably competent programmer? Have to agree with this being a great idea for an open source project. I had a little look around and the Google Geocoding Web Service (http://code.google.com/apis/maps/documentation/geocoding/ http://code.google.com/apis/maps/documentation/geocoding/) looks like a nice place to start, although most likely outside their ToS. For everyone else, it's determining what's good enough from what's perfect (a good starting point: http://www.endswithsaurus.com/2009/07/lesson-in-address-storage.html http://www.endswithsaurus.com/2009/07/lesson-in-address-stor...). Edited: And the resources on a previous HN posting for this article are helpful, too: http://news.ycombinator.com/item?id=1232042 http://news.ycombinator.com/item?id=1232042

tjmc 17y ago

Hmm what takes more time? An 800 word blog post or adding an "Outside US" option to the select control for "State"?

deleted 17y ago
[deleted]
wooster 17y ago
There are countries outside the US where the province may be required for proper routing of mail. I'm still working on my address support. It's hard, considering there are more de facto countries than are legally recognized by any international body, and most of them are one-offs in terms of address formatting.
- tjmc 17y ago
  I live in one of those countries and I think people are over-analysing the problem. I think you're perfectly safe with: Addr 1 (req) Addr 2 (optional) State (req but including "Outside US") Country (req) Post/Zip Code (optional outside US) When I order stuff from the US I just put my city and state in the Addr 2 line. In the end this is a classic example of the "perfect being the enemy of the good". Look at where your sales are going and allocate validation efforts accordingly. A lot of sites include Canadian provinces in the "state" field for example.
  - deleted 17y ago
    [deleted]
  - smikhanov 17y ago
    This piece of advice is so obvious that it makes me wonder why we need to have this discussion in the first place.
  - deleted 17y ago
    [deleted]
tghw 17y ago
I didn't have any credit card forms to write, so it's OK, I had the time.

_ivan 17y ago

bla bla

sern 17y ago

Was looking through my history and found this: http://i18napis.appspot.com/address http://i18napis.appspot.com/address It's not clear who owns it, though, so don't just go and use it. My point is that it's worth spending the time (and maybe money) to find one of these databases to make your international customers happy.

jwr 17y ago

I'm the poster of the original article that this responds to. First, please note that I never called anyone stupid or moronic. You did, and I do not know why. I said "stupid forms" and I stand by my opinion. I see why you'd want to validate US addresses properly now, thanks for the explanation. However, I still don't quite understand why you'd want to use the same rules for the rest of the world. Your credit card company cannot possibly validate my address (with zip code) and telephone in a rigid US-based form, because I won't be able to enter my zip code or my telephone into that form. They simply won't fit and validators won't let them through. Also, many systems won't process non-ASCII characters in my street name. Of course, I have been entering crap data into those forms for the last few years when buying online and have yet to see a credit card transaction rejected. Which means you don't have to worry about rejected transactions on out-of-country purchases, which means you might as well give us a reasonable form and not expect us to fight our way through your validators. So why not make two forms -- one for US customers, and one for everyone who chooses a different country? Given your estimates I expect you might even get that done in 2010 :-)

joshd 17y ago
"So why not make two forms". Exactly. Have a US form. If the customer selects a non-US country then switch out the state for a freeform "state/territory" field and skip the US-centric validation. All up you might need 10 lines of HTML and server side code. This applies to US-only services too. When trying to book accomodation and flights for a US trip I have heaps of websites refuse my money because I couldn't provide a US billing address. For example it didn't occur to the brain-dead developers of the Disneyland website that tourists be from outsite the US. The problem is developers who seem to think they know what the customer wants. I know because I've done the same thing. If you're relying on your intuition then you are almost certainly wrong.
tghw 17y ago
The post is as much a reply to you as it is a reply to your commentors. "Stupid" was used a little more liberally in the comments, and my post just exaggerates that for humor's sake. My main point is that it depends on your audience. For most things I would develop, my primary audience is probably going to be from the US, so I should take that into consideration. If my analytics show a higher percentage of international users than I'd expected, then I can go back and spend more time developing another form for outside the US. It's all a matter of priorities.

henrikschroder 17y ago

This whole post is a false dichotomy, there are more options than "US only" and "Correct for the whole world + validation". If I had mostly US customers, then I would make an address form that had the forms and the validation for US addresses, add a country dropdown, pre-select US in it, and if the user changed it just disable all validation and pass whatever the user enters on to the third parties. That way the international users won't have to try to guess how I want the addresses to validate, but they might run into errors from the third parties, and that validation might be slower, but at least we're down to a bare minimum of requirements. You know how those credit card processors are picky with US addresses? Here's another hint: They can't do international validation either! Just pass in a different country and whatever garble the user entered and you're usually good to go, as long as the credit card number and cvc matches. You know that CC billing address concept? That doesn't exist where I am. My credit cards don't have that. So when I'm asked to provide it, I enter complete garble, and it usually works every time. So don't worry about only giving well-formed data to the CC processors.

tghw 17y ago
That's actually kind of what I was trying to say. Having people put in fake data to satisfy a validator isn't the worst problem in the world. There are probably much better things to be spending your time on. And, yeah, in general, CC validation is a complete farce. Depending on how a vendor has set up their payment gateway, sometimes you don't even need a correct CVV or expiration date, much less a correct address...
- jasonlotito 17y ago
  It actually has less to do with the vendor, and more to do with the acquiring banks. I hate banks with a passion. One time had a customer on the line with us asking why he no longer had access. We explained because he had chargedback the transaction. No, no he did not, he assured us. We called the bank, and found out that he had asked for a chargeback, but it was for another transaction he had problems with, and wanted it corrected. So here we are, my customer service rep, the customer, and the bank on a 3-way call, and the customer is telling the bank to undo the chargeback and give us the money back, and to chargeback the other transaction. And they wouldn't do it. Oh, they applied the chargeback to the other transaction, but the penalty was still applied to us. The customer apologized to us later, and wanted to pay again, and was even willing to pay the chargeback fee. He simply paid again the normal price, and we swallowed the cost. I hate banks.

ErrantX 17y ago

Yeh this is.... something of a foolish rant (it sounds like he's taken personal affront to the original post). He's getting hung up on validating everything when, really, the sensible thing to do is minimum viable validation and leave it at that. Contrary to popular belief credit card companies will handle all sorts of not-quite-right data :)

joshd 17y ago

So lets weigh up the options: A) Let non-US customers enter whatever billing information they want. Accept that a small percentage will fail when we try and charge the credit card. Everyone else is happy and we make more money. B) Explicitly block non-US citzens who are trying to give us money. Oh! Let's choose B.

tghw 17y ago
Where exactly in the article did I mention blocking non-US "citizens"? (I think you mean users; most websites don't require citizenship verification.)

kristiandupont 17y ago

I don't understand why you are offended by the original article. It didn't seem offensive to me - he was describing a general frustration which may or may not be valuable feedback to you.

tghw 17y ago
No offense was taken in the reading and writing of these two articles. Just trying (and apparently failing) to humorously point out that if most of my users are based in the US, then I probably have bigger problems to solve than a Polish guy having to pick a state at random.
- jasonlotito 17y ago
  The way to think of it is like so: Most of your users are based in the US because those not in the US can't get in to use your service. =)
  - tghw 17y ago
    It's not that they can't, it's that there's a little more friction for them to. (Speaking of my websites, we've actually done the i18n necessary to make it usable from anywhere, but only after we knew we had that international demand.)
    - jasonlotito 17y ago
      Oh, I'm not talking about your websites. =) I'm just referring to the problem in general. The first moment the craziness of i18n that I experienced was almost 10 years ago, building software for Koreans (I think, not sure, was a long time ago) and after the UI team demoed the product, one of the partners who was pushing this for the Asian market remarked they had to remove the red. Apparently, red is a taboo color or something over in that region.

nosse 17y ago

"Contrary to popular belief credit card companies will handle all sorts of not-quite-right data :)" Actually I thought they would not handle any data if it's not exactly right. I think of myself more web savvy than most dudes out there, running linux and surfing with opera. Still I thought that if I put wrong zip code to the form, I would lose money. Stupid me. I'm from Finland, guess how much I have bought stuff from websites that require me to put zipcode in the billing form. "probably have bigger problems to solve than a Polish guy having to pick a state at random" That polish guy might be the polish guy that markets your product to ten french, one british and two australian guys, and then chain reaction! And the one thing keeping him from doing this is the billing form of your otherwise brilliant product. What I'm telling you is that if you want money, at-least tell people: "pretend you're from Virginia if you're not from U.S." in the billing form. Writing that takes considerably less time than two hours.