For some inexplicable reason, my wife often gets confused by the controls for our TVs. I can’t understand the problem — it’s all pretty simple, really.

The simplest case is the TV in the exercise room. We have one remote for the TV, and one for the satellite receiver. You control volume and power from the TV remote, and you change channels on the receiver’s remote. But of course the TV remote has a channel control as well, so my wife sometimes accidentally changes that one and loses the picture entirely. I don’t know why she can’t remember that all you have to do when that happens is press the “AVX” button to get back to the incoming line. That’s intuitive, isn’t it? Why can’t she remember that AVX stands for, um, let’s see… ahem… yes — it’s right there on Wikipedia: Catalina Airport. No that’s not it — let’s try Google: AVanti eXperimental, Avid Visual Extensions, AntiVirus Expert, Available XML… oh I don’t know, just remember it already!

Then we have a Hitachi big screen in the den. We have three remotes for that setup, because we also have a DVD/VHS combo attached. All three of these remotes have a channel selector, so the chance of screwing that up doubles compared to the exercise room TV. Also, each of the sources has its own input channel to the TV. To enable the satellite TV signal, you press “VID 1″ on the TV remote. For DVD, use “VID 2″ and for VHS use “VID 3″. Often someone sets something on top of the remotes, pressing who knows what buttons, and the picture disappears. All you have to do in this situation is first check the input source (VID 1/2/3) and then check the channel selection on the satellite remote. Oh, and undo PiP and freeze frame. But my wife can never remember this simple sequence, so she always calls me in to fix it.

In our bedroom we have a wall-mounted Hitachi plasma, but we bought it a couple of years after the big screen so of course the TV remote is completely different. For one thing, the volume controls are the smallest buttons on the remote — you always have to hunt for them, and you often end up pressing something else instead, like the channel selector (which again, you’re supposed to control from the satellite remote). To keep things simple, we got a DVD/VHS combo for this room that’s identical to the one in the den. Of course, I did wire things together differently here, because I wanted to be able to record the incoming signal — so the satellite receiver feeds the DHD/VHS, which in turn feeds the TV. That means that you have to set the combo on VHS to see TV, and if you accidentally change the channel on the VHS you lose the signal (it’s supposed to be on channel 3… I think). At least you only have one TV input to worry about — but we keep rolling over some button on the remote that changes that. I haven’t figured out which one it is yet, so I just get up and press the “INPUT” button on the TV until it gets back to “Composite”. Simple, right? Unless the power goes out (which only happens every few weeks around here) — then the satellite receiver usually loses its channel database and has to be recycled and you have to reselect VHS and set the channel on the combo and select “Composite” for the input signal on the TV all over again.

Oh, and don’t forget to say “Simon says“.

Did you ever play the game “Simon Says” when you were a child?  One designated person tells the rest of the players to perform some act, but they are only supposed to comply if the command was prefaced by the words “Simon says”.  It can be entertaining, in a laughing-at-your-neighbor’s-frustration kind of way.  The game plays on the distinction between what sounds like a valid command versus what has been agreed to comprise the requirements for a valid command within the context of the game.

A computer would be very good at playing Simon says.  They’re notorious for following instructions to the letter, within the context of the current instruction set.  They always “do what you said, not what you meant.”  Humans, on the other hand, almost always try to bring knowledge from other contexts into the interpretation of any request — so context-specific requirements for success can be elusive.  I often wonder whether the development of human-like artificial intelligence could compromise a computer’s abilities in the same way.

When designing human interfaces, it’s good to keep this difference in mind.  When the user has to remember to do things in a specific, non-intuitive sequence or combination in order to achieve a desired result, I call that a Simon Says Rule.  Simon says, don’t put Simon Says Rules into your products.  This applies to a wide variety of human interface domains — all of them, in fact.

A good example of a Simon Says Rule in programming language design is PHP’s test for failure on strpos.  You have to remember that you can’t say in effect, “is the result true?”  You have to use the “Simon says, is it really, really equal to true?” operation (=== true) to avoid converting a zero result to false.  In my opinion, any language in which you can say the equivalent of ”if (strpos(…))” and get a false result when the string was found has created a Simon Says Rule on that statement.  No matter how consistent it is with the rest of the language, no matter how well-documented it may be, it will trip up programmers because it runs against their wider language experience.

But I won’t just pick on PHP.  C and C++ have the “strcmp” (and related) functions that return 0 for equality – and zero equates to FALSE when used in a condition.  Thus, ”if (strcmp(…))” has an exactly opposite meaning of its intuitive reading.  It was designed this way because a non-zero return value for inequality allows more information to be returned: -1 if the first string is “less than” the second, and 1 for the opposite case.  But in my experience, 99% of the time I use strcmp I don’t care which is lesser or greater, I’m only checking whether they match.  Perhaps this should have been made into two functions: one that returns TRUE for a match, and another that returns an indicator of the collational relationship between the two strings.

Some languages just add unnecessary syntactic elements so their compilers will have something to complain about if you forget to use them.  Synergy/DE used to require the command “xcall” or the prefix “%” when invoking a function.  That’s a Simon Says Rule, as evidenced by their ability to remove that requirement (in most cases) with their version 9 compiler.  The “$” prefixed on variable names in Perl and PHP (oops, I did it again) is another example — one which Ruby demonstrates to be dispensable in a scripting language.  That “$” benefits only the parser:  ”Simon says, this is a variable name.”

In end-user software, if the user can’t install and use your product out of the box, then you’ve imposed some Simon Says Rules on their experience.  The default configuration should be usable in all but a small minority of cases.  If the user does want or need to tweak the settings, it should be obvious how that is done — and the order of those operations should be unimportant (i.e., no Simon Says Rules there, either).

You could argue that usernames and passwords represent cases of Simon Says Rules.  We’re willing to put up with those for security’s sake.  But wouldn’t it be nice if our identity could be secured without resort to a technique as primitive as ancient warfare?  When we humans see someone we know, we instantly recall the degree to which we believe they can be trusted.  Perhaps one day computers will become capable of that level of recognition.  Maybe then they too will become impatient with Simon Says Rules.