Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear American Website Owner

jan.rychter.com

Post reply on HN
Print view View original

101–110 of 149 posts

Re: Dear American Website Owner

#101

Post by Semiapies »

mattm wrote: post #85
Semiapies wrote: post #33

Earlier quoted context omitted.

To be blunt, inputs you don't validate are inputs that will be entered wrong a significant portion of the time. Other concerns may override this for many fields, but unusable phone numbers are generally considered a problem.

If you force people to enter a phone number in a format they don't have, you will just end up with a bunch of 555-555-5555 numbers. Either way, you are going to get incorrect information. It's much better to realise that your information will not always be 100% accurate no matter what you do.

The idea is to minimize incorrect information. A 555 number at least tells you something that a number in an unfamiliar format doesn't - whether this was intentional or mistyped.

I'm very much for allowing people to enter any format, but seeing how badly people mis-enter NANPA phone numbers, it is simply wrong to not acknowledge that you will see far more mistakes from an open input box.

Re: Dear American Website Owner

#102

Post by timthorn »

ismarc wrote: post #74
awolf wrote: post #3

I wish author was a little more constructive here. What phone number pattern would he recommend we use?

E.164 format. Every valid number in the world can be represented. The downside is that most people don't even know that this exists, so when doing an international based system, you have a filter based on the country they user is based in and automatically apply any codes needed. Just strip everything out of the field that isn't a number and prepend the country code if the region doesn't normally include it. That mea…

The transform isn't that simple. For example, UK numbers start with a 0 to indicate STD (long distance) - but that 0 must be stripped for calls from another country. Ie, 01234 567890 is dialed from abroad as +44 1234 567890.

Re: Dear American Website Owner

#103

Post by eagleal »

handelaar wrote: post #4

Dear everybody else: Some of us don't even have postal codes. Those profane-looking ones we enter aren't real. Love, Ireland.

At least you don't even have them. We (Albanians) have them, but neither the govt neither the professionals know about them!

Re: Dear American Website Owner

#104

Post by lkjhgvbnm »

Deestan wrote: post #50
njharman wrote: post #45

I've argued many times for making address one big text field. Let people who live in the country, who own the address, format it how they know it should be formatted.

Me too! I've been arguing this for years, and I have yet for someone to reply with a good reason why it shouldn't be handled this way. Bad reasons given: - Safeguard against users who can't be relied on to format their own address properly. Fix 1: Don't worry about that. Fix 2: If you really want this, leave the rest of us an option to use a freeform address instead. - "Out webshop database has these fields." Fix: Ch…

Because chapter one in the databases for dummies book used address as an example, with fields for address, town, state etc.

Then you stick them altogether and print them on the envelope, thus covering chapter2 = report generating.

Re: Dear American Website Owner

#105

Post by lkjhgvbnm »

pyre wrote: post #98
Retric wrote: post #63

Earlier quoted context omitted.

While accepting generic address is nice, if you actually use the address for anything actually knowing the Country and Zip+4 for the US gives you a lot of power for things like advertizing campaigns. Also, the chances of a user entering bad data when given an unformatted field increased dramatically. My suggestion is to give the option to enter generic information but don't let that become the default.

Or: * allow the user to enter a free-form address, normalize it and then prompt the user for confirmation that the normalization was correct. * Allow the user to edit fields on the confirmation page. * Log any differences between the normalization and what the user changes for further refinement of the normalization process. * Don't require fields that may not be relevant to all addresses that you plan to capture. *…

Why are you normalizing it?

Is there some huge performance advantage in having the state field be an Id into a states table? Perhaps it would make updates easier if they ever rename Washington?

Why not normalize the name? There must be lots of Johns in your DB

Re: Dear American Website Owner

#106

Post by jasonlotito »

tghw wrote: post #97
jasonlotito wrote: post #93

Earlier quoted context omitted.

I wrote about Credit Card forms a while back as well. http://www.jasonlotito.com/programming/what-i-know-about-des... Anyways, you mention in your post: "Making something a simple form that is fully internationalized and has useful validation is no where near as easy as they would like us to believe." It's not easy, but it's not as time consuming and as difficult as you think it is. Getting the phone numbers right do…

Of course I exaggerate in the post, you're right that it'll probably take just a week to get coded up. (Which means three weeks, the way development often goes.) The question is whether or not that time is well spent, or if I would be better off using that time to improve whatever product/service the form is attached to. Especially when you're on a lean (i.e. startup) budget, the decision becomes pretty clear.

You are throwing a lot of ifs.

If you are providing a service that needs to be programmed. If you are short on funds. If you are only focusing on the US.

The problem isn't that. The problem is this:

When you are providing a service that relies on processing international orders... When you are no longer a startup and earning money... When you want to accept orders from the international community...

If you don't want to support the international market, don't. But if you do, do it right. I've seen it happen: "Launching in Canada!" and they still have a restriction of 5 characters for their Zip Code, or require all numbers.

It's silly. That's what the article is referring to. Wanting to accept international customers but doing it poorly. You'd be better off not offering the service and doing it right then offering it up poorly.

Re: Dear American Website Owner

#107

Post by lkjhgvbnm »

while we are on the topic can we lose the dropdown list of 196 countries you got from the ISO table?

Seriously, how many products have you shipped to Afghanistan or Albania but you make everyone scroll past these to get to the only country you actually deliver to (+ Canada if you're lucky)

Re: Dear American Website Owner

#108

Post by pyre »

lkjhgvbnm wrote: post #105
pyre wrote: post #98

Earlier quoted context omitted.

Or: * allow the user to enter a free-form address, normalize it and then prompt the user for confirmation that the normalization was correct. * Allow the user to edit fields on the confirmation page. * Log any differences between the normalization and what the user changes for further refinement of the normalization process. * Don't require fields that may not be relevant to all addresses that you plan to capture. *…

Why are you normalizing it? Is there some huge performance advantage in having the state field be an Id into a states table? Perhaps it would make updates easier if they ever rename Washington? Why not normalize the name? There must be lots of Johns in your DB

Others have stated the reason for normalizing it already: interacting with third party software and/or services.

It makes more sense to normalize it at the beginning in order to give the user a chance to approve that it was processed correctly. You could just do the normalization at the point when you need to interact with the 3rd-party services, but then it's hidden in the back-end so you have to be confident in your normalization processing.

You could roll out a solution where the confirmation page is just there to allow the user to approve that normalization works on their free-form address, but still store it as a chuck of text in the database. Then when you are confident enough in your normalization process, you could just remove the user confirmation part.

Re: Dear American Website Owner

#109

Post by brown9-2 »

Vivtek wrote: post #26

Dear German Website Owner (yeah, this works both ways) I do have a state in my postal address, and if I have to enter my address as 47374 Richmond instead of Richmond IN 47374, it will probably go to Virginia first, and maybe they'll get it to me eventually. Just saying. Internationalism is hard. If you want to go for the global market, it would behoove you to try to do it right.

Doesn't the author address this pretty directly?

you should remove the State field if the country isn't set to U.S.A. or at least make it optional

He doesn't say "Remove state completely".

Re: Dear American Website Owner

#110

Post by cglee »

Semiapies wrote: post #71
cglee wrote: post #61

Earlier quoted context omitted.

How does this reply add value? The blog post presents a problem that I (being an American) rarely even think about. I wanted to see how others deal with this issue. WTF is this reply doing?

This is what your downvote button is for.

I did downvote, but at the time, the parent post had over 15 points and I wanted to know why.
Post reply on HN