alt Hacker NewsI love this. Thank you for introducing me to "Norman Doors". I hadn't realized someone else had described this in such detail. I have been complaining about this years.
Ok this will be a tangent, but I also take this one step farther and also talk about "documentation". Just for the record, I don't think documentation is all good or all bad, but it definitely can be used incorrectly and in excess. And Norman Doors and a great way to get this point across.
When someone creates or installs a Norman Door by accident or out of ignorance and then realizes there is a problem, they often think "I know, I will document it!" and they add little placards to the door that says "Push/Pull" or some such. They see that this helps with a small subset of users and thinks "there, I fixed the problem, people just need to read the documentation and now it is their problem if they don't". But if you watch users of the door, a large portion will still use the door incorrectly because... people don't read documentation. If they don't read documentation, is it the users fault the door was designed incorrectly or was it the designers problem?
I use this as an example for my developers on thinking before documenting troublesome code or a confusing interface to first ask "can I design this so it is less confusing?" and if so, that would usually be preferable to adding documentation "to solve the problem". Well designed code (or doors) with no documentation always beats poor designs with documentation.
Replies
There's a funny example of even the "documentation" going wrong. At a local mall, there is a set of doors and they have put the word "PULL" (vertically like:
P
U
L
L
) on the window of the door, so from the wrong/opposite side, you still see the word "PULL" when you should PUSH (even if most of the letters are backward) so you still are tempted to take the wrong action when you see it. (I tried to explain the ridiculousness of it to the person I was with, but I don't think they cared.)
Which reminds me of another "there, problem solved!" pet peeve of mine. I call it the Default Trap.
In many cases (Norman Doors are an example), there are two or more equally valid ways to do something. By "equally valid", I mean there is no clear standard for whether it should operate one way or the other, and if you ask 100 people which way it should work (which no one ever does), you get something approaching 50%.
So the product manager or perhaps developer simply says "make it a setting", and everyone agrees and declares the problem solved.
But the problem is, you have to choose a default. And 90% of the time, no one is going to change that default, or even discover how to. So you have to be very correct about assuming which value is the best default - and at that point, it probably doesn't matter that you make it an option.