Simon says, don’t play Simon says with your users
September 28th, 2007 12:13:29 pm pst by Sterling CamdenDid 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.
Posted in Geek Meditations, Wildly popular | 26 Comments » RSS 2.0
Subscribe by Email
Perl’s sigils are valuable to humans too, not just the parser. Not only do they aid interpolation, but they help disambiguate assignment contexts to variables used as lvalues.
(Ruby does have sigils, though it uses them to mark variable scopes. The language still allows the possibility of symbol naming conflicts as non-class, non-instance, non-global variables lack sigils.)
The use of sigils in Ruby is one of the only features of that language that I find bothersome. I understand how they help to disambiguate, but for me they mostly serve to create an opportunity for accidental variable auto-creation, when I forget the prefix on an instance variable.
I LIKE the sigils!
You’re certainly welcome to your preferences, but the very fact that “sigil” comes from a name for a magical symbol indicates that it may be somewhat counter-intuitive, no?
I LIKE significant whitespace …
… late the flames begin!
OH GOD. Ever since Fortran, I’ve hated significant white space. That’s about as counterintuitive as it gets: The amount of “nothing” means something.
Fortran taught me to hate auto-declaration as well.
> That’s about as counterintuitive as it gets: The amount of “nothing” means something.
But it’s not nothing, though … it really is something. Just take an md5sum of your document w/ spaces and w/o, you’ll see … they’re as different as it gets
Somethings along the same lines:
* 0 is just a valid a number as any.
* Somehow this quote was the first thing I thought of after reading your comment:
“If you choose not to decide, you still have made a choice”
– Neil Peart
Anyway … I just posted my original comment in jest, I’m not trying to convert anybody or anything ..
This whole post is mostly in fun — that’s why it’s on “Chip’s Quips”.
Obviously there are pros and cons to various language design decisions, or we wouldn’t still be arguing about them. It seems that we can’t always make things both intuitive and precise. But I’d like to see a little less gratuitious counterintuitiveness (whew!).
[...] Simon says: don’t. Here’s one Simon says you should learn to play well: don’t make your users play Simon says. [...]
All blanket statements are false.
But seriously, there are plenty of cases where forcing you to annotate more is a good thing. For example, a common C++ coding standard is to name member variables m_Foo, and global variables g_Foo.
The language doesn’t require it, but it’s useful because it makes programs more readable – you can see at a glance what impact a given assignment statement has. Ruby’s ‘member’ and ‘global’ sigils serve much the same purpose.
…and then it dawns on you that `m_` could also stand for method.
That’s my problem with sigils in languages that require them. It might be good practice to annotate, but is it good language design to force annotation?
Sometimes explicit is better than implicit. Didn’t Fortran teach you to hate auto-declaration?
Yes, you’re right — and auto-declaration is one reason why sigils are required in Ruby. The interpreter has to determine scope before it decides whether the name maps to an existing variable or a new one. Languages that don’t auto-declare can use a hierarchy of name precedence for unqualified names. Thus, instead of having to specify scope on every use of a variable, you can specify it in one place: where it’s declared.
There are pros and cons to both sides of the sigil debate, though, I’ll admit. They’re certainly a lot more useful to Perl and Ruby than they are in PHP.
Yes. So what? The objective isn’t to distinguish methods from members: in usage that’s obvious anyway.
The point is to distinguish local variables from persistent variables.
[...] Thanks for the reddit, Reg! Thanks also to you and to Assaf for link-loving that post. [...]
[...] and don’t forget to say “Simon says“. Tags: avx, composite, dvd, hitachi, remotecontrol, satellite, simonsays, tv, [...]
sigils is the best.Heheheh
[...] Simon says, don’t play Simon says with your users [...]
Simon says, sigils is the best!
And I truly missed my childhood. Missed playing “Simon says” =)
Too bad — we used to play it in school, perhaps because the teachers didn’t have enough material to teach…
[...] been using the C programming language for more than 24 years now. Despite its occasional Simon Says rules (I’m looking at you, prototypes), it has become a very comfortable language for me. But [...]
[...] reader can usually tell by context where the end of a statement should be. So it becomes a Simon Says rule – one that punishes the programmer more than it [...]
[...] especially the indentation rules. Oh, it’s consistent all right, but it just strikes me as a Simon Says Rule. I mean, c’mon – you can’t even use tabs instead of spaces? Between that and always [...]
[...] because earlier languages like Fortran abused whitespace as a sort of Simon Says for each statement doesn’t mean that all programming languages should make these potentially [...]
[...] Windows 8 Enterprise or (b) they’ve purchased side-loading keys from Microsoft. Talk about Simon Says [...]