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.
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.
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.
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.
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.)
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.
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.
Probably - it's a good indication of thoroughness, user-orientation, consistent interface design, etc. All of these are crucial to new and growing businesses.
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.
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.
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.
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?
(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.)
"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."
"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.
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.
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 :)
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.
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.
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.
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?
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.
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.
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.
"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?
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.