Beautiful Code

I just finished an unusual conference called Codework at the University of West Virginia, where computer science experts and writers batted around the similarities among their disciplines and the differences between writing code and writing fiction.

I've already blogged about Ted Nelson's presentation at the beginning of the workshop, and I'll write up some of the fascinating exchanges we had later this week, but in this blog I'll lay out some ways I found that programs are like stories and essays--usually in what they do wrong.

Ruby inventor Yukihiro Matsumoto gave us a chapter for Beautiful Code in which he compares programming to essay-writing, with many positive associations. I believe that comparisons between user interfaces and stories are so widely understood that many application designers engage in storyboarding to plan their interfaces. What I'm describing here, though, are the more unfortunate associations that come up when I feel like complaining (as we all sometimes do) about the difficult interfaces I've encountered.

Simple failure: nothin' doin'

Like a character or plot line that the author drops abruptly without resolution, the most obvious user interface failure is when you press a button and nothing happens. This is common in web applications because the programmers implemented some JavaScript feature that your browser doesn't support. It's also happened to me several times when I downloaded an application that was configured to be modular, and that was built without support for some feature.

You can't control how users build the software, but you can try to let the application degrade gracefully when features are left out by the user, such as by not promising a feature and then bombing out when the user tries it.

Outright lies

Confusing messages are common in programs, as they are on street signs and other parts of everyday life, but some lies go deeper and reflect the gap between what the program promises and what it actually does. One might adopt terminology from Terry Winograd and Fernando Flores and call this a failure of speech acts.

As an example, take the blogging software used on the site where I'm posting right now. It sends me messages when a trackback is posted and allows me to flag them as spam. And after I do so, it displays a screen in my browser saying "Trackback flagged as spam."

It took me months to realize the screen was lying. The program had notflagged the trackback as spam, but was waiting for me to press a Save button that I hadn't even seen at the bottom of the window.

As I said, this is more than a poorly designed message; it's an unfulfilled promise. On a broader level, the program is rigidly and unproductively playing out an aspect of its design; a kind of "foolish consistency." Someone designed all its user options as screens that the user could change and then implement using a Save button. This model of interaction was inappropriate for the spam reporting screen, but the designers lacked either the imagination or the skill to adjust the model for this case.

Springing an element too soon

The movie Michael Clayton throws away its most dramatic plot element--an explosion that tries, but fails, to kill the lead character--within the first twenty minutes. It then engages in a series of flashbacks that convey little suspense because we already know how the character will be attacked and how he'll survive.

Other authors and playwrights front-load their stories too much by introducing characters or background detail at a pace that's too fast for the reader or viewer to absorb.

Similarly, some programs pack too much into a single interaction. A classic example is a flight reservation program that toss all kinds of options, such as seat assignment, into the screen where you select your flight.

At the moment you're selecting the flight, you're probably concerned with time, price, and just getting the transaction done fast before someone else grabs the reservation. So you're likely not to notice the seat selection, and you'll be frustrated later if the web site fails to give you another chance to make the selection.

Introducing an element too late

This is the opposite of introducing an element too soon. It's not always a mistake; it can actually be used very effectively as a plot element. For instance, Alfred Hitchcock sets up the key surprise in Frenzy by showing he lead character in two different places in quick succession. One assumes he traveled straight from one scene to the other, but in fact he did something crucially important in between and we realize it only at the end.

But unless you want your computer program to engender the same kind of anxious frenzy in your users that Hitchcock is known for, you should avoid withholding key elements.

An example of holding back an element too long is an e-commerce site that presents a list of items and a total price, asking you to continue. Suppose you have a discount coupon number you want to enter. You may search the screen from top to bottom and back again, trying in vain to find a field where you can enter the coupon number. You may actually abandon the sale rather than accept the price that's offered.

And the very next screen may contain the field to enter your coupon number. But it comes too late. The program has made you think it is forcing you to accept full price.

No doubt, there are much subtler instances of poor program design that could be compared to a narrative or an essay. Unlike modern fiction, computer applications are best advised to stick to tried-and-true plot elements. But nothing replaces the ability to think, like a good author, of what the user expects and needs at each step.