The Art of Interactive Design

Start with the Verbs
- “This is the first and foremost rule of good interactive design, and the word rule is truer than guideline in this case.”
Don’t Start with the Technology
Be on Guard against the Egotistical Tendency to Speak
- “Most designers are egotists who would rather inundate the user with their brilliant expressions than actually let the user do something.”
Keep It Fast
- “All software requires some combination of three fundamental resources: memory, execution time, and the sweat of the programmers. You can always reduce one of these three by increasing the allocation of the other two.”
Organize Verbs into Manageable Groups
- Prioritize Verbs by Frequency of Use
Be Square
- Spatially (visual arrangements) and temporarily (e.g., the division of a game into levels)
Design the Loop as a Whole
Don’t Set Up False Expectations
Say What You Mean
Speak with One Voice in Five Tones
- Primary Data Windows
- Progress Reports
- “I Screwed Up”
- “I Can’t Handle That”
- “I Need More Information”
Don’t Describe the Problem—Offer the Solution
- Offer to substitute a font for one that wasn’t found

To put a human face on software is risky, as it is too easy to break the illusion and hurt your trust with the customers. The author suggests using software agents that match their appearance and speech to their intelligence and abilities, rather than pretend to be more human than they are. (For example, by making them cartoony.)

Use First and Second Person and Active Voice
Be Just as Courteous as You Would Be in Public
Use Normal English, Not Your Own Terminology
Don’t Feign Infallibility
- “Software is always quick to tell you what you did wrong, but it never seems to admit the possibility that it did anything wrong.”
- ‘The “I Screwed Up” and “I Can’t Handle That” standard messages presented in Chapter 8 are ideal for this task.’ In the real world, a person who always blames everybody else and never accepts responsibility for his own mistakes is quickly ostracized.
- (Apply Impro’s status analysis to software messages? —D.)

The serious point for interactivity designers is that we must never underestimate the intensity of commitment that our users hold for the more established habits of their computing lives. Don’t ever—ever!—mess with the dynamics of the user–mouse interaction. It doesn’t matter if your method is superior; you’re up against instinct, not reason. Don’t push your luck.
One of the deepest and most fundamental polarities in the universe is that of entities versus operations.
- In interactivity design you can express this as process intensity versus data intensity. Process intensity is the degree to which a program emphasizes processes instead of data. All programs use a mix of process and data. Process is reflected in algorithms, equations, and (to a lesser degree) branches. Data is reflected in data tables, images, sounds, and text. A process-intensive program spends most of its time crunching numbers; a data-intensive program spends most of its time moving bits around.
- This applies to games: the higher the crunch-per-bit ratio, the more “computery” the game is and the more likely the game will be entertaining.
- The crunch-per-bit criterion also works well in the negative sense as an exposer of bad software ideas.

The general solution to the problem of trees creating a combinatorial explosion in the number of nodes is the linkmesh, a tree with links leading back and with state variables. A linkmesh lets you simulate more nodes with fewer.

Programs should recognized well-defined patterns of input (and how the current particular case is different) and interrupt the user to offer to complete the recognized task. The user should only need to supply the distinguishing data. How intrusive this agent is should be adjustable.

Homo Ludens.

Play is the original educational technology and is fundamental to interactivity. Play requires safety. The major ingredients of play are agon (competitiveness; play as rule-bound competition) and paidaia (frolic; play as a joyful activity).

Our brains treat interactivity and play as the same thing. “Play is what happens in a serious application.” The user learning and deciding whether to commit to your program is intrinsically playful.

Adult play is surely deeper and more subtle, takes more effort, and covers a wider variety of topics than child play. Consider these examples:

The owner of a small business putting nice creative touches on her company newsletter

The corporate drone dedicating long hours to the creation of a multimedia extravaganza for a meeting presentation

The market researcher fiddling about with the customer database to find odd combinations of customer types

The news reporter carrying out background research on the web, getting carried away following fascinating but marginally relevant threads

When barristers and judges wear wigs in Britain, they are playing. Costume is a sign of play. This doesn’t mean childishness but rather them isolating themselves from the real world and creating another self-contained world of justice. “[A] court of law shares much with a basketball court or a tennis court.”

Play requires safety for the players: physical, social, financial. Privacy provides safety from social dangers when trying a new skill. One of the secrets behind the success of the personal computer is that people can use it without the embarrassment of a teaching session.

Designers may not see the dangers that users imagine. Designers can motivate users by putting them in a playful and experimental mood.

People who call the Macintosh “just a toy” see its playful character and hold the playfulness against it.

A playful design philosophy will certainly indulge in occasional cuteness, although cuteness is neither a necessary nor a sufficient condition for playfulness.

It is best to render error conditions conceptually impossible rather than merely technically impossible. For example, to limit the number of names that a user can enter for something, the worst option is to display an error message when there are too many names. Dimming the control that adds a new name is better. But even better is to have space for exactly the allowed number of names.

Self-explanatory.

You must acknowledge the user’s experiments. Try to recognize every input as meaningful and issue a simple response if you can’t.

“Interaction can take place only where there is a perceived discrepancy of volition.” As a child throws a ball, the child figures, through experimentation, the laws of physics that determine the ball’s behavior. The child stops seeing the ball as an agent with free will and starts seeing it as an inanimate object subject to laws of nature. The ball is abandoned, and the child seeks out new agents to play with.

This explains the old and continuing failure to design successful cooperative games. Play thrives on the noncooperative elements, and withers where there is no discrepancy of volition.

This “blood and iron” philosophy of play may strike some as cynical, but I see no pessimism about human nature in it. The ugliness arises from two derivative phenomena.

First, the idea that greater discrepancy of volition yields greater interaction. It leads to games about kill-or-be-killed conflict. Greater discrepancy of volition yields more intense interaction, but this isn’t higher quality. Greater amplitude does not make music better.

Second, agon masquerading as paidaia. The history of civilization shows a trend towards the substitution of agonistic play for conflict.

Lawyers think that they are playing. They’re not in it for the richness of the interaction; they’re in it for the joy of victory. No lawyer has ever told me about a fascinating case that he lost.

The richness—and therefore the educational or revelatory value—of the interaction is lost in the intensity of the confrontation.

As systems grow bigger and more complex, they evolve more abstract structures to cope with the increasing complexity. Many designers attempt to improve an existing design by adding greater complexity, which yields “humongous heap” design.

A more productive alternative would be to concentrate on the level of abstraction of the design rather than the amount of complexity. Greater complexity emerges automatically from higher abstraction; therefore, abstraction should drive the design process, not complexity.

An example of abstraction is to go from the concept of a document to the concept of communication.

Indirection substitutes a convenient indirector for the real thing. That indirector can represent the referent, substitute for it, or point to it.

A scheme for getting to the referent from the indirector is critical to indirection. It is called a construct, It “carries” an indirector across some “distance” to a destination where the referent is reconstructed. For example, for dollar bills the construct used to be the gold you could exchange them for.

Factor output into combinable components.

Inverse parsers
Creole

Trash bin
Facial feature extraction

The brain does not see reality as it is but as it expects it to be. It uses pattern recognition to make sense of what it sees by matching it with stored patterns. We only see what we can recognize, not what is really there.

List the features that constitute the feature set of the thing you wish to describe with a metaphor.
List all objects whose feature sets contain many features in common with your first list.
Compare each candidate’s feature set with the metaphoree’s feature set, noting features that match and features that don’t match.
Isolate the mismatches.
Use some of the matched features and ignore or negate each of the mismatches.

A competently designed metaphor may have little room for extension.

[Another] danger arises from the temptation to extrapolate rather than extend a metaphor. A beautiful example of this problem is provided by the attempts to create three- dimensional desktops.

Personal anticipation must be figured out from interaction with the user.

We must overcome the fear of relying on heuristics to anticipate the user’s desires. (Always showing the print dialog is an example of this fear.)

A truly idiotic solution to this problem is the “startup wizard” who quizzes the user when the program is first launched, asking for all sorts of detailed information that the software uses to custom tailor the software. The problem with this approach is that, all too often, personal preferences can’t be developed until after you’ve had the opportunity to use the software. By that time, the startup wizard is gone, and there’s no way to figure out how to get him back.

None
Context
Followup questions
(etc.)

Your biggest problem in using anticipation in software design is your exposure to blame. If your software insists on pig-headedly covering its ass at every turn, nobody can ever blame you for screwing up.

The growth of mass media, therefore the fall of interactivity.

I would argue that all past efforts in interactive storytelling have not been interactive storytelling, but rather “interactivized stories” or “storyized games.” At a structural level, they are not storytelling; they are stories. The difference here is profound: it is the difference between the process of storytelling and the result of storytelling (a story). Storytelling is not the same thing as a story: storytelling is an activity, a process, while stories are collections of facts, data. You can’t interact with data—you can interact only with processes.

A number of researchers have approached interactive storytelling as a problem of simulating characters. I used this approach in 1987 with Siboot and concluded that it led nowhere. Its problem is its failure to focus on the verbs.

The heart of my technology is the storytelling engine. The engine’s basic task is to execute verbs.

Each verb can lead to another verb, and so on, generating a long sequence of events: a story. The verbs are created and specified by the author. Each verb can generate a number of options for other actors. Which options are available and the rules by which those actors choose among the options are again specified by the author. The human protagonist is given control of one actor and makes the choices for that actor.

A storybuilder (developer) first creates actors, each with a name and a number of personality traits, then the stages for the drama with rules of access, then props. Their main task is the creation of a large set of verbs. A good story requires a least a thousand. Each verb must have a set of roles, slots for actors.

For example, if Puncher punches Punchee, then one role might be Punchee’s Best Friend, who presumably would come to the Punchee’s defense. Another role might be Punchee’s Girlfriend, whom we would expect to scream, rush to console Punchee, and possibly hurl a few epithets at Puncher. There could also be Intervening Bystander, who might step if the fight goes too far. We could even have Timid Bartender, who might want to duck behind the bar or call the cops. Whenever a verb is executed, each of the witnessing actors consults each of the roles, asking whether they fit that role. If the actor does fit the role, then he executes it, deciding which of the role’s responses to choose.

Circuits for direct stimulus-response relationships are easy. Circuits that process a sequence of bits are more difficult. Similarly, evolution: from direct resonses, to sequential thinking, to subjunctive.

Your software engages your user in a conversation. Your design task is to maximize the utility of that conversation.

Think about that conversation in linguistic terms.

What are the verbs? What does the user DO?

Speak less, listen more.

Thinking is the delivered content of all software.

Your software should do whatever a reasonable person in its situation would do.

Dactylodeiktous means “all fingers pointing at.”

The page about the book on Chris Crawford’s site
“The Art Of Interactive Design”