By Marc Rettig
My comments in the January 1992 column about Brenda Laurel's book, Computers as Theater[4], generated some very interesting mail. I aske people who were trying to design from a dramatic perspective to tell me what they were doing. At the time, I was having a difficult time translating Laurel's ideas into the terms of our own application. These discussions have helped me enough that I thought some of the ideas were workth passing on to readers Since this is the "Practical Programmer" column, I try to limit my discussion to things that have been proven in practice. Not much as been written about design from a dramatic perspective, so I make an exception in this case to pass along work in progress that relates to what may turn out to be an important point of view.
Scott McGregor, Manager of Applications Development at Atherton Technology in Sunnyvale, Calif., uses storyboarding techniques to model the flow of an itnerface, and tries to pace the interaction to make the experience satisfying for the person using the tool. Here are some quotes from our correspondence.
"The key to developing systems from a dramatic perspective to me, is to start with a story line that I believe would feel enjoyable to a prospective user. What is the problem they are trying to solve, and how do they go about it? From this screenplay, I develop a storyboard (usually online) and from that a set of screens and functionality that supports the story. This becomes the prototype product. It can be tested by giving a volunteer the problem from the story line and letting them do a usability test using the prototype software. If you are successful, the test user will follow the script of the sotry, without even having seen it. If you are unsuccessful, the user will deviate from the script and never get back on track.
"A successful product … must have a story line that has psychological rewards built into it. Early after users have started the test, the users must feel drawn in, must find something enjoyable going on, and want to continue. And when they are done, they must feel good about having solved the problem, and how they solved it. This is not unlike a play. A play must have an understandable structure. But that is not enough. It should have 'a hook' that captures your interest early and holds it, and an ending that satisfies you when the play is over."
McGregor goes on: "… I just got back from Nashville. While I was there, I visited the Cumberland Science museum which was having an exhibit on the evolution of video games. It was interesting to note just how simple the written instructions were and how complex the actual behaviors that needed to be learned. Pong, the second video game (the first, SpaceWare, was too complex!) had only the following written instructions: 1. Insert quarter to play; 2: Use knobs to move paddles; 3. Avoid missing for high Score.
"Ted Nelson says that video games follow the two-quarter rule. If you haven't had a rewarding experience after two quarters, you won't play it again. Screenplay writing has a similar rule. If you don't hook the audience within the first five minutes you lose them. For both, once you have caught the audience, the audience is more than interested in learning more a bit at a time as it is relevant to continued participation. Nelson claims, and I agree, that the same thing is true for software people like to use, versus tolerate using. A good tour/computere people like to use, versus tolerate using. A good tour/computer-based training/help system along the lines you discuss can help achieve this immensely."