Why input validation could cost you a lot
medium.com
medium.com
I've seen something similar (well, now I know it's simmilar, it didn't occur to me until I saw your example) - though I assumed it would be unhandy. It was a way to show your webshop cart as a text saying something like: You have bought X, We will send it to (Addres here). It should arrive @ (date). Will cost (some)$. (it didn't look as awkward as my example though).
A few things that seem missing from this critique is the idea that shipping and payment aren't just human mediated processes.
With most ordering systems payments and shipping are directly integrated using external APIs, and if you pass garbage data out to those then you will fall into the trap that professionals call "really fucking everything up", which is undesirable. Processing payments typically requires a name and an address, as does shipping. That's not much of an excuse for not doing proper input validation or accepting non-ascii input but it does help to explain why the problem isn't a trivial one. If users are just sending you cash (or, say, some sort of gift-card code which might as well be digital cash) and you're just hand labeling packages and taking them to the local post office that's one thing, but that's not the way even very tiny businesses work today.
The expiry month is this month, but it expires at the end of the month, not the start. Obviously an OBOE, right? So I wrote to them and explained.
They wrote back that the problem was that my card would have expired by the end of the campaign (I'm still waiting for a new one because of the postal service).
Form validation is normally syntactic rather than semantic, but KickStarter mixed their validation types to something I didn't expect and then didn't tell me why when it went wrong.
It's either surprisingly easy to get wrong or surprising that KickStarter got it wrong. I'll be generous and let you choose which.
Customers and users do have an interest in getting their shipping details correct. Help them get it right rather than telling them they're wrong.
That should be the behaviour of all such forms, even when some seemingly important information is missing.
I can't count the amount of forms in which I had to come up with some validation-passing-yet-not-really-valid postcode so I could get my order shipped to my place with no postcode, while not giving a postcode that would get the postal service to ship to the wrong place (say, 00000 or 99999 don't work, but 10000 would indicate that I want the package shipped to Troyes, when I really want it to some overseas territory - so sometimes 11111 validates and is clearly enough not a real postcode, etc).
Also... I routinely receive packages from the US with the address printed with missing or mangled accents, sometimes just for my name, sometimes just for my city, sometimes both... come on, Unicode isn't some newfangled technology anymore, you should be able to get accents right! And these accents aren't even outside the latin1 charset.
We rented a newly constructed house. The old houses in that area were demolished, but the same street names were kept. It was very annoying to have web forms doing such validation telling me that the address was invalid (you cannot have that house number in that street).
Another pet-peeve: I have an ë in my name. When I purchase some software through a web form that accepts that character, please don't just remove it or replace it with garbage in my license key ;).
One of the most common errors was a bad combination of zip/city (ie. zip code for a different country area) which required a live person on the phone asking customer about proper data - it costed money.
The most unusual one was when a person managed to type gibberish in every field avaliable and than add to it a proper adress, name, zip etc... all in a three or four letter wide house-number box.
VALIDATE ALL THE THINGS!
That sounds problematic to begin with. I grew up in a house with a 5-digit street number.
I had to call and talk to someone put in a work-around. That meant I lost the discount for doing it over the web. It also meant that it took months and several phone calls for the bill to start coming to the right place.
Perhaps the message should be- "please double-check, we can't find a record of that <> in our database." But accept it if the customer insists.
Not being in the phone book or having a "private" number has nothing to do with your address and phone number not being in various lookup databases.
Tons of places do address verification and you don't need to be in any phone book for it to work. Even the USPS does address verification both paid (for businesses) and free (for non-profits).
It's pretty funny to get downvoted to zero on a true post just because someone really wishes it were true that their phone number and address can't be verified.
http://www.ups.com/content/br/en/shipping/cost/additional.ht...
It's great the author brought this problem to everyone's attention.
I agree with you that this is ludicrous, but sadly there's not much you can do. (I keep my french bank account on only to keep my ps games.)
Even following a spec for email validation could be trouble: https://github.com/swiftmailer/swiftmailer/issues/71
Instead of just rejecting the form submission outright, why not just ask the user for explicit confirmation that their input is not mistaken?
If you have received a large sample from, say, 1,000,000 users a certain % of those entries will be invalid. The number of users is too large to manually fix or attempt to contact the user to fix the entry. If the contact information is invalid, you can not contact the user. If the contact information is invalid but you think you may be able to correct it, e.g., add a .com to the end of "user@gmail", you may not even legally have permission to contact that person.
The goal is to reduce the invalid % to as low as possible. There is no 100% perfect rate. You are going to sacrifice 1 user for 10.