June 14, 2008
In user interface design there’s something called the squint test. You should be able to squint at a dialog box or panel and get a rough idea of how the components relate to one another. You shouldn’t have to read each label and button in order to figure this out. (You can simulate this by replacing all text with “xxxx”.) You want to make use of the part of the user’s brain that infers relationships from visual patterns. If the layout doesn’t pass the squint test, then you’re forcing your users to read each label and button to understand even basic workflow.
The same principle applies to programming languages. You can replace all letters in a Java program with “x” and you’ll still be able to instantly guess the basic structure:
xxxxxx xxxxxxx xxxXxxxxx(xxx xxxXxxx) {
xx (xxxXxxxx == xxxx) {
xxxxxx xxxxx;
}
xxx (xxx x = x; x < xxxx.xxxxx; x++) {
xxx[x] = xxxXxxx(x);
}
xxxxxx xxxx;
}
You can recognize the method definition, the initial test (probably checking method parameters), the loop, the return statement. You can squint at the code and still get that. Not all languages pass this test:
(xxxxx xxx (x)
(xxxxxxx (x xx)
(xxxxxxx (x xx)
(xxxx (> (* x x) x)
(xxxxxx-xxxx x (x x x))))))
This gets even worse with macros, where a single character difference can radically change the meaning of the entire nested expression. It’s the orthogonality of Lisp, ironically, that results in programmers not benefiting from a powerful part of their brain. I claim that this squint test is important, and that languages should deliberately make different constructs look different.
Here’s an analogy. Go into your library and look for SICP. It’s probably the only purple book, it’ll jump out at you. The Algorithms book? Big and white. The novel I read five years ago about a woman who moved to Africa? I don’t remember the title, but I remember that its spine was orange, so I find it easily. The brain is good at that kind of visual search and recognition. Programming in Lisp is like having a library where all the books are identical except for the text on their spine.
Ten years ago I designed (but never implemented) a program that helped computer animators manage the many video clips they composite together. My plan was to represent clips as icons on a work surface. On import, each clip would get a new icon with random size, color, font, and shape. These attributes would not be modifiable by the user. I was certain that users would request the ability to set these attributes, but I knew that allowing this would result in animators making all icons identical. People think that’s what they want, but really they’re more productive if they can instantly find the video clip they need instead of reading through 15 pieces of text. (Favicons in bookmark menus provide a similar benefit.) I still regret not having the opportunity to do that experiment (and see if users rebelled). One day I may design a computer language and have the opportunity again.