"No Dashes Or Spaces" Hall of Shame | Hacker News Reader

"No Dashes Or Spaces" Hall of Shame

unixwiz.net

72 pointsvijaydev62 comments

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.

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.

Your users actually showed great foresight, I think. There are good reasons to avoid "intelligent" or hubristic interfaces: http://unqualified-reservations.blogspot.com/2009/07/wolfram...

Summary: "intelligent" interfaces will always fail for trying to solve a problem (the Chinese room) which is un-decidable even for a human mind, and so the future will use dumb, reliable interfaces (until we can figure out telepathy). Corollary: users shouldn't be blamed for not wanting to trade reliability for "awesomeness". Read the article, it's worth it.

The author makes a good point, but how many ways are there to enter phone numbers/credit card numbers/dates? Can't these sites be a little flexible?

Why does he keep referring to himself as "your author here" or "the author"? Hiding the fact that you're referring to yourself doesn't make you not refer to yourself. It's just confusing - say "I" instead.

Hmm. Is "1-3-2010" January 3 or March 1?

Folks from different parts of the world disagree.

If a user enters that, the system could ask them which one they mean; optionally, it could even remember the user's preferences.

Since this was in the US, we went with the first one.

Yeah, I wouldn't assume all those companies' programmers are simply incompetent. For all I know it might be a business rule and the programmers are specifically asked to do that kind of validation. I'd rather ask some of those programmers before writing a web page about it.

It's the company's job to get this right, not any one programmer.

> the users were scientists with advanced degrees

They were expecting to have to retype the date, after the program rejected their first attempt. That's the way it usually goes ...

I did try to measure this. It seemed like most people were entering perfectly reasonable dates; even things like "March" and "November"

I have a feeling it's a case of not caring how to enter the date, and not caring to try a few and find out. Much easier if you're told exactly what to do, so you have to think, because apparently checking who used the NMR machines last week is not something people want to think about. (Fair enough.)

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.

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.

Two reasons:

Force people to enter their area code.

What do you do about international numbers? It's a bit more complicated, and the grouping is less obvious.

The kana part is a pet peeve of mine. It also happens for the address part. The only site I recall that does the conversion automatically is Google Adsense.

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

Let me play devil's advocate here. Users who are not tech-savvy or those who are new to using credit cards online might be afraid at each step that they do something wrong.

-Enter credit card!

-Uhm, I wonder if it means with spaces or with dashes or just the numbers, I hope the money won't go to the wrong place

If it says 'no dashes or spaces' at least it's clear and might be reassuring to the user that the designers have thought of the same thing as him/her, which sort of indicates that he/she is on the right track and hasn't screwed up yet.

I'm not saying this is good usability practice, but it would be interesting to test different versions for user reactions.

If that were the only issue, the instructions could always say "spaces are optional".

In that case there would still be different possible ways to enter it. "without dashes and spaces" makes it unambiguous. Again, I'm not claiming it's usable, but sometimes interface design can be counter-intuitive.

Did that actually bear out in which companies went on to be successful? It's an appealing notion, but I question it every time I run across a successful company that can't get it right.

I would expect that rule to be more reliable for startups than for large companies that can survive on mediocrity.

Yes, by competitors, I meant other startups building ecommerce software, not sites like Walmart. IIRC it worked well.

Do you think it is a still good test today?

Probably - it's a good indication of thoroughness, user-orientation, consistent interface design, etc. All of these are crucial to new and growing businesses.

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.

http://weblog.raganwald.com/2007/09/you-suck.html

I used to have this problem (I have a hyphenated last name) when booking airline tickets up until very recently-- but it appears that SABRE and the airlines have finally fixed it!

This probably has something to do with the new TSA regs that state that the name on the ticket has to match EXACTLY with the name on your ID.

Unfortunately, my wife's full name still doesn't fit on her NY driver's license, meaning she can only travel using her passport as ID.

I wonder how it must feel to have a reeeeeally long name (like some Indian/Thai/Indonesian 20+ character names), and how the airlines, TSA, and other ID-issuing authorities deal with this? (to say nothing of non-romanized names!) What does Seetharaman Narayanan's name (Photoshop engineer) look like on an airline ticket?

"I forgot my ID"

Now it doesn't have to match.

Now you don't get to fly.

Oh, you're not in the US? Nevermind.

(Hint: you do not need an ID in the US. It's annoying if you don't have one, but the TSA has procedures for this case. The airline may want an ID if you don't pre-print your boarding pass or want to check a bag. But they are going to be more flexible about things not matching, as they actually have a customer to lose if they fuck you over.)

Not sure how this:

http://www.tsa.gov/what_we_do/layers/secureflight/faqs.shtm

"If the name printed on my boarding pass is different than what appears on my government ID, will I still be able to fly?

Due to differences in boarding pass systems, boarding passes may not always display the exact name you provided when booking your travel. The name you provide when booking your travel is used to perform the watch list matching before a boarding pass is ever issued, so small differences between the passenger's ID and the passenger name printed on the boarding pass, such as the use of a middle initial instead of a full middle name or no middle name/initial at all, or hyphens and apostrophes should not cause a problem for the passenger."

reconciles with this:

http://www.tsa.gov/travelers/airtravel/acceptable_documents....

"Passengers who do not or cannot present an acceptable ID will have to provide information to the Transportation Security Officer performing Travel Document Checking duties in order to verify their identity. Passengers who are cleared through this process may be subject to additional screening. Passengers whose identity cannot be verified by TSA may not be allowed to enter the screening checkpoint or onto an airplane."

That sounds like fun.

FWIW the NY driver's license only had room for my wife's first and middle INITIALS and our last name. Not exactly a recipe for a happy front-line TSA experience.

They frequently don't allow apostrophes either.

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

You don't need that for pure number validation, no, but it can be a useful heuristic for short-circuiting your validation -- if someone enters a number which should be Visa but clicks "MasterCard", you know something is wrong and should kick back an immediate error message rather than proceeding.

IME, all you "know" is that they entered the number and forgot to pick the proper corresponding card type.

The requirement to select a card type always seems wrong to me. When you swipe a card at a terminal, you don't have to tell it if you're swiping an AmEx or a Visa. It can tell JUST from the number.

The chance of someone making a typo and still having entered a valid cc number is quite small.

It's more a question of whether you even continue to validate the number at that point; personally I'd choose not to since you already know something's wrong. Hence I treat it as a short-circuit validation trick.

But that already assumes that you ask the card type in the first place. There's no need for that and hence no possibility to choose to stop validation. It smells like premature optimization to ask the cc type for this reason?

In the US yes, but here in the UK that doesn't work because of Meastro/Switch/Solo cards. It may also be different in other countries. So don't always assume stupidity when you see a drop down box :)

That's true, but I think that users would probably be confused if they can't chose the card type...

I would want to know that my card type will be accepted before entering the digits.

You don't need a drop-down for that, but the list needs to be someplace, and if it's part of the form it can be a sort of a CRC for user intent if the CC number doesn't pan out. Might make it easier to prompt the user to make a correction.

Paypal shows icons of all major credit card companies below the credit card number field. When you start typing the non-matching card types gets grayed out.

That is really quite clever.

It's the sort of idea one wants to generalize and steal for other things on a site.

Makes me wonder if there are any sites that showcase or catalog non-trivial/non-obvious UI techniques.

I have seen some Javascript that adds the logo as soon as you've typed enough digits. I thought it was a nice visual cue that the card type was auto-recognized.

I think the logical improvement to this interface would be to put the credit card type after the number, and then have it be auto-selected. That way the user can select if he wants, but it will be correct by the time he goes to select it.

Showing a logo or a message is really easy, ie. http://github.com/madrobby/creditcard_js

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.

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.

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.

Thanks to arbitrary restrictions I have to remember many more passwords. Which is bad for security.

password advice: come up with a system known only to you that generates passwords based on what sort of site you're one. you can base it on the web address, the company name, general category, whatever. now feed that through your algorithm and you have a unique password for each website you visit. if you forget a password you can re-derive it, since there will only be a handful of possibilities. since you'll certainly have your algorithm memorized you never need to write anything down.

This is much better advice than the "3 categories of password" the GP mentioned. Actually, 3 categories plus derivation is good ;-)

The other day I was glad of that. I bought a game, was asked to create an account, typed in a password at the site; then received a confirmation email with the password in plain text - which probably means they are stored in plain text, not to mention left lying around in mail archives. Just a matter of time until one of those sites gets hacked and their DBs circulated.

(P.S. I did write them a polite note suggesting not doing it, and they seem to at least have stopped sending passwords in email; I don't have much hope about their storing hashes. Probably plenty of others less blatant but just as insecure ...)

Anywhere that uses the same password for their phone system as their website is limited to alphanumeric because you can't type ,./:;'"[{]}\|-_=+ on the phone.

One of the mitigations to this is to create a PIN that's unique to a telephone number you've associated with your account.

> why do people disallow characters such as ,./:;'"[{]}\|-_=+

Because there are keyboards other than the U.S. PC keyboard. The one I'm using right now, for instance, has '=' as shift-0.

With characters echoed as asterisks, if there is any sort of problem with key mapping, the user will be locked out. And giving up or calling support.

Wouldn't it be a problem only if the same user that created a password with this character that isn't on some keyboard will then use this keyboard?

I mean - users will probably use characters that are on their keyboards, or that they know how to generate. Why disallow characters when users choose them on their own?

No travelling, ever ? "Hi, I'm in this resort in Cancun, and I can't login!"

That's a moderately extreme scenario. You're inconveniencing users to prevent some possible but unlikely future inconvenience?

its not really "extreme", it might be a euro bias but I have had this happen to me a lot, hell getting @ working on some keyboard can be annoying enough.

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?

All of them.

In Cygwin, my home directory is /cygdrive/c/Documents and Settings/myusername. This breaks fucking everything. I have to re-export $HOME as /cygdrive/c/DOCUME~1/myusername.

Yes, Windows also sucks.

Why just stop at dashes and spaces?

s/\D//g

Thank you, beat me to posting it.

Never "filter out the badness", always "filter for only the goodness" then use the good value. Exhaustively enumerating the goodness is easier than exhaustively enumerating the badness.

(I'd combine this with a check for length, too.)

"No spaces or characters", I'll have to remember that next time I make a form that shouldn't be used.

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.

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.

It's a hall of shame, the point is that their presence on the list makes them want to fix it.

Reply on news.ycombinator.com