Dr. Dobb's Journal July, 2004
"I'm the master of low expectations."Let me lower your expectations. For those of you who read this column regularly, that won't be necessary, but for others who, when you hear the word "interface," think API, a warning is in order: We'll be dealing herein with the softer stuff. Adjust your background music appropriately. Put the Jolt back in the cooler and break out the Viognier, or may I recommend the Marachal Foch? If you're over 21, that is, and we'll need to see a picture ID; if you're under 21 we've got a nice lavender lemonade.
—George W. Bush
In my office, which I'll point out is currently in the back of my partner Nancy's restaurant in case the previous paragraph didn't tip you off, I have a shelf of what I think of as "soft" programming books—software design, user interface design, programming philosophy, that sort of thing. These books are generally among the most engaging and entertaining books on my Computing and Technology shelves. Their authors feel free to spread themselves a bit, pontificating, waxing philosophical, and indulging in verdant similes and metaphors.
Turn signals are the facial expressions of automobiles, Don Norman tells us. Brenda Laurel invites us to think of computers as theater, Don Knuth urges us to think of programs as literature, and Paul Heckel won't be satisfied unless we think like film-makers when we write code. Jon Bentley seems to think of programs as haiku, although he doesn't explicitly say so.
Eric Raymond goes on about cathedrals, and others appropriate just about every other architectural term for their metaphors. Fred Brooks unflatteringly compares programming projects to the Tower of Babel as well as to dinosaurs stuck in tarpits and underdone omelets and dirt under the rug. Be warned. If you're considering a career in software project management, you could end up like Fred Brooks, a broken man writing bitterly of his failures.
"They misunderestimated me."
—George W. Bush
Okay, not a broken man and not bitter. I think Fred Brooks and most objective observers consider his work managing the development of IBM's OS/360 a success. But Brooks freely admits that the product was late, it didn't meet specs, its costs ballooned like the cost of the Iraq war, and it didn't work well until several releases after the first. Most software project management success is like this: what other industries call failure.
But back to the metaphors: Jef Raskin asks us to visualize the act of searching for information as flying above an information landscape and further asks us, nag that he is, to picture the process of narrowing the search as a change in altitude. Lovely, tricky, and dangerous, like most metaphors. Take Jef's metaphor too realistically and a successful search becomes a crash and a perfect Googlewhack becomes a collision on the runway.
Joel Spolsky reminds us that reality itself is one of our more useful metaphors, while Bruce Tognazzini shows how to stretch a metaphor beyond all semblance of reality with Sun's Starfire's file folders that sucked in relevant documents and blew away irrelevant ones, like some Maxwell's Demon doing lepton triage on the event horizon of a black hole. So maybe metaphors are insufficiently imaginative, too grounded in reality? I know I find reality constraining at times, and I'm only a Saturday-afternoon programmer. Alan Cooper says to forget about reality, or anyway realism; he pushes for designing with idioms rather than metaphors. Unless you're writing books, I guess, like Cooper's The Inmates Are Running the Asylum, which is not about actual inmates or an actual asylum.
Just to muddy the waters a little more (having already tried to stir up Brooks), there are different kinds of design, with different rules. Mitch Kapor argues that user-interface design is a different species of animal from software design; Chris Crawford argues that interaction design is another species yet. No wonder there are so many of these books. Oh, and one more thing that makes these books so engaging is that the authors often bridge the Two-Cultures gap.
"This case has had full analyzation and has been looked at a lot."
—George W. Bush
In a much-analyzed late-1950s book and lecture, novelist and scientist C.P. Snow described a communication gap between two cultures of the sciences and the humanities. This Two-Cultures gap, Snow claimed, was getting in the way of solving the world's problems. Snow had a foot firmly planted (Snowshoed?) on either side of the gap, which was at the time regarded as an unusual stance, even in ordinary shoes. Although I regard the gap as real, I don't know how unusual Snow's gap-straddling was even then. I suspect that many of you readers of this magazine have a foot in both those worlds. I know I do.
Ditto Chris Crawford, the legendary game designer, writer, and thinker who was Atari's manager of games research in 1979, who wrote The Art of Computer Game Design (out of print, but downloadable; see http://www.erasmatazz.com/) in 1982 and inspired a generation of game designers, and who probably understands play better than just about anybody. He shows that in his 2003 book The Art of Interactive Design (No Starch Press, 2003; ISBN 1-886441-84-0), about which more presently.
Reading these "soft" books is great fun, especially the metaphorical excesses, but when push comes to shove, the proof of the pudding is where the pedal hits the metal. So I thought I'd test one of these books on some projects and products I'm currently working on and/or using and/or evaluating. The book I'm using is the aforementioned The Art of Interactive Design by the aforementioned Crawford, who talks the talk with style and walks the walk with a foot in either culture.
The products and projects I looked at all involve user scripting, or user programming. Crawford thinks that a lot more people should bridge that Two-Cultures gap, at least in the form of Arts and Humanities types learning to program. I've long thought that programming was a basic literacy skill, but I'm not fool enough to think that everyone can learn C++. Someday maybe we'll have Arts and Humanities programming languages; right now the closest we come is with "easy" languages and special-purpose languages and scripting systems. Some of which I will momentarily poke with a sharp stick.
"I'm not very analytical."
—George W. Bush
The Art of Interactive Design isn't just a book of design tips; it lays out a complete philosophy of interactive design. The first part of the book lays out just what interactivity is, and why it's fundamental to software design among other things, and what the fundamental elements of interaction are. (They're Listening, Thinking, and Speaking, each of which means more in Crawford's philosophy than it might appear.) The second part does get into specific design advice, fleshing out the concept of interactivity and the principles of effective interactivity, by showing how it works in some specific fields, and how it didn't work with some specific products. The third part lays out the philosophy in greater detail, discussing process intensity, linkmeshes, play, abstraction, indirection, linguistics, metaphor, and anticipation. And the final section places it all in social and historical perspective.
Crawford is a fine writer with an engaging style that never glosses over the tough points, but never slows you down. I think you always come away from one of his books entertained and inspired. Certainly that was true for this book and this reader.
Next, a Crawford-influenced look at a product, Microsoft Excel; a book, Excel Hacks (by David and Raina Hawley, O'Reilly Media, 2004; ISBN 0-596-00625-X); and a project, the Summer Jo Dailies.
"I'm not a numbers guy."
—George W. Bush
The electronic spreadsheet is a wonderful invention. It's one of the most-cited examples of how computers can extend our abilities. But it's also proof that you can put programming tools in the hands of mere mortals and those mortals won't necessarily blow themselves up. By "programming tool" I'm referring to the functions in the sheets; laying out the numbers is trivial. It's the code hidden behind the numbers that's the essence of the spreadsheet, and writing those functions is, in a minimalist sense, programming.
But formulas also represent the dark side of spreadsheet user-interface design: functionality hidden in cells that look like data, function names inspired by the same charsimony that makes UNIX so readable. (Yes, I made that up. Charsimony = character + parsimony.)
For Crawford, the electronic spreadsheet is the essence of interaction, admirably implementing the interactive loop in which:
Using a spreadsheet is an iterative process. So is building application software. Crawford recommends improving application software either by making verbs closer to the user's creative impulses or by making the verbs more sophisticated. Excel seems to have added features by—but that already says it: Microsoft has added features rather than honing verbs. IMHO.
The result, it seems to me, is a lack of closure and predictability. Crawford's first step above only works if you limit the user's set of conceivable actions by developing a set of verbs that exhibits closure. In a clearly defined universe of functions, the options are clear, but add one new function that doesn't fit into that universe clearly, and you've punctured the closure, letting users imagine that anything is possible, leading to paralysis. The COUNTA and COUNT and N functions in Excel are all useful verbs, but what mental model would lead me to expect exactly these particular functions with these particular names, this particular packaging of functionality?
But such complaints have to be put in perspective. The electronic spreadsheet and Microsoft's implementation of it are highly useful and empowering.
Of course, a well-designed software tool can empower users to produce badly designed products, and that's where design books come in. One would think that a book titled Excel Hacks would be by nature antithetical to good design, whether software design, user interface design, or interactivity design. But surprisingly, this book contains some good design advice. It's needed; spreadsheets are two-dimensional structures, offering much scope for design errors. One example of a hack from this book that also includes design advice is Hack #67.
Hack #67 advises not to use volatile functions like TODAY that cause recalculation whenever you raise your eyebrow, but then goes on to show you how to hack volatile function references so as to reduce the recalculation mania. Design advice plus a hack for when you can't follow it. There are many such examples in the book.
I won't try to apply Crawford's principles to Excel Hacks. A book is not interactive. But I wanted to mention it here because it's a good book. It is the most hackish in the function hacks, one of which I'll talk about momentarily.
The project I'm working on is a spreadsheet for tracking restaurant and farm costs and expenses on a daily basis: costs versus sales, food versus alcohol, farm versus restaurant, market sales versus produce sales to restaurant—and providing some summary stats. The model is month-based, so I clone a new spreadsheet from last month's each month. It's all very obvious and easy except that special cases intrude. The restaurant is open Wednesday through Saturday, only sometimes there's a special event on Tuesday. There are other such quirks. Now, I have to put this in perspective: This is hacking in one of the more derogatory senses. I was tweaking this spreadsheet on-the-fly whenever it wasn't doing what we needed. As a result, it became a hard-to-maintain collection of patches, and the process of generating one month's sheet from the previous month's was messier than it should have been. If I criticize Microsoft for adding features freely, I am far worse. I have solved some of these problems and improved the code, but this has led to a new problem: The formulas needed to handle all the special cases began to get tricky—and long.
Microsoft probably thinks that when your formulas get so involved that they need comments, you should be writing VB scripts, but some of us some of the time find ourselves trying unsuccessfully to straddle the gap—the gap between Excel formulas and VB scripting, not the Two-Cultures gap. Excel Hacks showed me a hack that makes spreadsheets more usable by adding comments. That a hack is needed for this seems silly. Crawford points out that using a spreadsheet is a highly iterative process. Doesn't that imply that somewhere you're going to need comments? Seems like.
"I don't spend a lot of time thinking about...why I do things."
—George W. Bush
There are truths we leave unspoken, to protect our fragile myths. We fear that we won't enjoy "South Park" any more if we once admit to ourselves that it is full of moral lessons. We fear that play won't be play any more once we acknowledge that it is vital to our survival.
There are at least two important themes running through Chris Crawford's book: interaction design and interactive storytelling. One very powerful idea comes out of the latter: subjunctivity. Good-old what-if thinking. Crawford neither invented nor discovered this phenomenon, but he seems to have thought about it as deeply as anyone. You need to read the book yourself to get the feeling for the importance of this idea; my attempts to summarize it in an early draft of this column seemed obvious and trivial.
Yes, play can be useful. Games can develop skills or fresh perspectives, simulations can provide insight, kittens can learn to stalk and pounce and attack through play, vital survival skills. What-if analysis lets you avoid errors that would otherwise catch you unawares, and let you steer clear of blind alleys that look like inviting paths when you first embark on them. All true, and all obvious.
But reading Crawford, you come to feel that it's all a game. That this playfulness is the real power that computers offer. Writing, he tells us, gave Mankind sequential thinking: stories. And that was a big deal. Our brains don't handle sequential thinking all that well; we're pattern matchers. But the ability to write it down made mathematics and commerce possible, among other features of civilization.
Now computers take us to another level, giving Mankind threaded thinking: interactive storytelling. Just what he means by interactive storytelling would take more space than I have here to explain, but he isn't talking about what the term suggests: all those failed experiments in branching stories. He's in fact working on his own software to help in developing a new kind of interactive software. The most efficient way to inform you about that is to give you the URL: http://www.erasmatazz.com/. But Crawford is also talking about today's software because software is inherently interactive. What isn't so obvious is the extent to which all software is a kind of storytelling. Or a game: In Crawford's world, the concepts of game and story and program are all teasingly convergent.
Crawford is always entertaining, and it's easy to underestimate the importance of what he's saying, especially when he's using examples like those playful kittens. But it's when he's at his most playful that he's the most serious. That playful kitten is engaged in deadly serious activity, acquiring survival skills, learning how to kill without being blinded or maimed. And it is also playing.
Using a spreadsheet may not seem like play, but perhaps it should. Because it occupies the same role in a business as wrestling does in a cat's: Just as cats play to learn how to deal with the world, programs like spreadsheets let us explore dangerous paths without danger, and let us more wisely move through our lives. Wrestling is a kitten's spreadsheet.
DDJ