"No Dashes Or Spaces" Hall of Shame

I am not sure that this is a hall of shame for implementors, it is more of a hall of shame for users. The first web app I ever wrote did reporting on NMR machine usage; the users were scientists with advanced degrees and years of teaching (and computing) experience. The way you specified the date range for reports was via two text fields; the start date and the end date. Originally, I used a date parser that would accept pretty much any input. You could say "yesterday" to "today" or "4-2000" to "9-2005", etc. I listed examples in the description text, but I had several users ask me exactly what the date format could be. When I showed them "anything", they were amazed, but claimed it was confusing.<p>I changed the text to read "specify all dates in YYYYMMDD format, no spaces or slashes" and everyone loved it afterwards. I kept the intelligent parsing as an easter egg.

Relatedly: telephone numbers. (555) 555-5555 is understood by every American above the age of like six. Why can't your website figure it out? phone_number.gsub!(/[^0-9]/, "") prior to processing, pretty_print_phone_number(phone_number) in the view, and you're freaking done.<p>Relatedly but of less obvious salience to most Americans: if you tell me to write my name in hankaku kana and I write it in zenkaku kana then rather than telling me to rewrite it, call your zenkakuToHankaku function on my input, see if it contains anything other than kana, and if not just coerce the input over. I have been on a crusade to do this at my day job.

Back in our Viaweb days this was my quick test for whether a competitor was worth taking seriously.

My beef is with credit card fields that won't allow dashes IN THE NAME FIELD (and yes, I am shouting). The irony of a web application that refuses to allow Tim Berners-Lee to use his credit card to make a purchase is mind-boggling.<p><a href="http://weblog.raganwald.com/2007/09/you-suck.html" rel="nofollow">http://weblog.raganwald.com/2007/09/you-suck.html</a>

You also don't need to ask for the card type (Visa, MasterCard, etc); it can be automatically determined based on the number.

Also - why do people disallow characters such as ,./:;'"[{]}\|-_=+ in passwords on theirs sites. I can't understand this. I would understand banning non-ascii, but normal ascii characters should be allowed everywhere.<p>Now every site allows different subset ot such characters, so every site forces user to have different password to it, if user wants non-alphanumerics in password.<p>I would like to have 3 passwords - trash password for social sites, etc; better password for e-mail; and good password for important things. It would be managable.<p>Thanks to arbitrary restrictions I have to remember many more passwords. Which is bad for security.

Who else thought this would be a hall of shame for Unix apps that don't work with files that have spaces in their names?

Why just stop at dashes and spaces?<p>s/\D//g

"No spaces or characters", I'll have to remember that next time I make a form that shouldn't be used.<p>I used to have a fifteen-digit number on a visa or mastercard (not amex), which was a little weird, but I was amazed how many vendors couldn't handle it. Aren't there standards for this stuff?

And the truth of it is that it's like a 1 or 2 line data sanitization fix in most languages nowadays to normalize the data value to the expected one.<p>1) strip whitespace off the front and backend. 2) eliminate unexpected characters in the middle of the string like - or spaces.

Great page - many of criticized resource are very useful.

I'm so glad there was like 100 examples, I wasn't quite certain what the guy was on about till the last few.