Some Problems Shouldn't Be Solved

So, it's long been my belief that, from a UX perspective, it's better to stop a user from doing the wrong thing than checking input after the fact to make sure it's valid.

So the case of disabling a button because it shouldn't be pressed given the state of the application/form/whatever is, to me, a good thing.

But, you have to provide clear indications so the user knows how to resolve the situation. Anything else is actively user hostile.

So:

Do prevent the user from entering bad data instead of allowing them to input it and then telling them it's wrong after the fact.

But don't make it impossible for the user to resolve the situation by providing unclear indications or unreasonable hoops that need to be jumped through.

Random aside: notifying the user they've selected a bad password is, to me, a good thing. Actively preventing the user from enter a bad password, though, is a PITA... sometimes I really just don't care about password security (one-time login, low consequence if hacked, etc).

That conversation is supposed to seem ridiculous but I'm not kidding when I say, you can have exactly that kind of discussion by calling any number of customer support lines for various corporations. You don't need computers for this kind of idiocy. You simply need a flow chart and a pedant.

Me: My tire is going flat on my rental car.

Avis: OK, we'll send someone out to put on a spare.

Me: That's OK. I can change the spare.

Avis: OK, then after that take it to a nearby location and exchange the car.

Me: I've called all the locations within 45 miles and none have an available car.

Avis: OK, we can bring you a new car.

Me: Great.

Avis: I have to warn you however, that you may be charged for the price of the tow.

Me: What tow?

Avis: We have to tow the car too you.

Me: Why?

Avis: That's how we bring you a car.

Me: Can't someone just drive a new car out and take this one back?

Avis: No both cars must hauled.

Me: Why?

Avis: That's just how it's done.

Me: OK, why would I have to pay for it anyway. The tire has been leaking since I got the car.

Avis: Because the car has a good spare. Can we send someone out to change it?

Me: That's not necessary I can change it.

Avis: OK, then after that you can take it to the nearest Avis and exchange it.

Me: I already told you, all the nearby locations are out of cars.

Avis: OK, then we can tow you out a new car and exchange it.

Me: OK.

Avis: But I have to warn you sir that you may be charged for the tow.

Me: Why?

Me and Avis: Because the car has a good spare.

Me: Are you a robot?

Avis: ....

Me: I ask because I really can't tell if I'm speaking to a human.

Avis: Yes sir, I am a human.

Myst was an example of this, which is why I hated that game. You wondered around this (admittedly beautiful) world with very limited degrees-of-freedom. A button here, a lever there. And when you actuated that DoF anything in the whole fucking world might have changed. Then it was up to you to wander around seeing what changed, and which new DoF's opened up. Wash, rinse, repeat. That was the game of Myst.

If you think about it, the greyed out sharing button (and indeed most infuriating software stories) essentially follow the Myst pattern, but in reverse. An unwanted change has occurred to the state of the world, and you don't know what DoF triggered it.

The password thing is actually a slightly different class of user abuse, embodied by all forms, which is making the user turn messy thoughts into coherent data, which is the essence of work. This data must satisfy a long list of predicates, an invisible gauntlet of tests. (It's even better when the form resets part of itself on error - like when your password is cleared if you don't enter the captcha correctly.)

These are crimes against the user, and truly need to stop. (Although Myst was a big hit so clearly some people really love the abuse.)

Seems like these aren't "problems that shouldn't be solved", but rather "UX problems that SHOULD be solved".

When I implement not-quite-trivial business rules, I usually spend at least two thirds of the time to give good, verbose error messages about which rules are violated, and what to do instead.

Often it would be rather easy to make the check itself a few lines of conditional code or a single SQL query, but then the only response I could give to the user is "you can't do that", plus a link to the requirements document. Instead effort is spent to follow the steps in which a human might check the constraints.

I don't like it when computers are used to program people. Your password must have exactly 10 characters etc. is a salient example. Compare that to a better UI like git--really, tell me users don't interact with it--and you'll notice that git lets you make terrible mistakes if you want to, but provides a way to recover. It's interesting that this better approach to passwords[0] resembles the "I forgot my password" feature.

[0] http://www.cs.bham.ac.uk/~tpc/cwi/Teaching/MASPPapers/EmailA...

> Ridiculous password requirements are a subset of a larger problem: computers make it possible to enforce ridiculous rules, and so those ridiculous rules made. If you I to wait in line at the post office to see a clerk who would register me, how would they possibly enforce this?

Why are there words missing in a way that's not typical of the usual non-native speaker drop-outs? I'm finding this article very difficult to read.

Author here, glad people found it interesting. If you're curious about anything, or want to tell me I'm wrong, I'd like to hear it.

My own personal story of rage on this front: a site which, at the time I signed up, permitted arbitrary characters for its "security questions". I had the cheek to include characters other than pure alphanumerics.

Later, I return to this site and need to offer up the answers to the security questions. No problem... right up until I discover that some @$!#^%!!?! software developer put format guards on the security question answer fields at challenge time (vs. creation time). Yes, it was possible to create an answer to the (stupid) security questions which could not be answered by the website.

So now, my access to this site is literally sitting behind a several-months old developer ticket.

(I'm kind of getting the feeling I completely failed to understand the point of this article, or am at least misunderstanding the point of the examples...so the following may be WAY off)

He's got a point about it not being clear if "Passwords need 10 characters" means they must be exactly 10 characters long or at least 10 characters long. It is the latter. If you put a password of less than 10 characters in the first password field, when you move on to re-enter the password it will immediately flag the error with the message "Your Password must be at least 10 characters long".

I'm a bit confused, though, by the imaginary dialog between him and two clerks showing how these requirements would work if this were done in person. To reflect the actual form, the dialog should be more like this:

HIM: Here is the password I want. (Hands paper to clerk).

CLERK: Passwords have to have at least one special character from this list. (Gives list to him). Your does not have one of these.

CLERK: Also, passwords can only contain letters, numbers, and characters from the special character list. (Point to the list he just handed over). You have a special character that is not on the list.

HIM: (Replaces the disallowed character with one from the allowed special character list) (Hands new password request to the clerk). OK, try this one!

CLERK: That meets our requirements.

I'm not sure at all where that part of his dialog about question mark being a special character but not a character comes from. The password "Ab345?7890" is accepted by the password checking JavaScript, even though it is exactly 10 characters long and so the ? must be counting as both a special character and as a character.

Don't get me wrong here...I'm not saying these requirements are OK. I find requirements like this annoying, because I use a password manager to generate my passwords. I can easily tell the password manager to include or exclude special characters, but I don't get to pick which special characters it picks from. At a site like the Post Office, which limits the set of special characters, I might have to generate several passwords before I hit one that is acceptable.

As a password manager user, what I really want out of sites is for them to allow long passwords, and place no restrictions on the characters in those long passwords. I will then use 25 character random passwords consisting of digits and lower case letters. That gives me 128 bits of entropy, but if it needs to be manually typed for some reason it is not too bad. I'm OK if they place some character requirements on shorter passwords...but if the password is long enough, let me do what I want.

So yeah, the requirements are annoying. I am just having a hard time believing that the red explanations that appear when the first password field loses focus were not sufficient to enable someone who programs at Google to manage to come up with a password acceptable to the Post Office.

I'd say the Post Office actually did a pretty good job of implementing the form. Most sites just tell you that your password violates the rules, and it is up to you to re-read the full list of rules trying to figure out which ones tripped you. The Post Office form tells you exactly which rules were violated.

That _was_ a reference to the Voigt-Kampff test, right?

Bad example. Stupid password requirements are great because it makes it more difficult for users to use the same password on every site.