Bringing Design
to Software
© Addison-Wesley, 1996
Profile Author: Terry Winograd
When Donald Schön (Chapter 9) speaks of an artist, such as a sculptor, who is engaged in a conversation with the medium, we can imagine the picture clearly. The sculptor molds clay or chips stone, and then she looks at and feels the sculpture to see what it has become. Creative designing lies in the interplay between intention and the surprise at what emerges. Everyone who has written interactive software has experienced the same interplay. The programmer writes some code, runs it, and sees how it behaves and feels. The results are partially expected, partially surprising, and they feed into the next cycle of design. The ability to shape and reshape software requires a capacity for rapid prototyping-for turning an unarticulated idea into a working prototype quickly enough to be able to change it, to listen to it, even to throw it out and to go on to another. In this activity, the nature of the programming language and environment can make a large difference-perhaps as large as the difference between modeling in clay and sculpting in stone.
The goals and possibilities are varied, and they are reflected in prototyping tools that are suitable for different prototyping cultures, as described by Michael Schrage (Chapter 10). In the organizational process of design, it matters whether the prototypes are done as a program or as cardboard or video mockups. Some prototyping purposes are effectively achieved with highly refined pixel graphics; others are better served by scanned-in pencil sketches. Sometimes, functionality is a key issue in the prototype; at other times, the prototype needs only to be a facade that demonstrates a look and feel.
Current software design-practice relies heavily on software systems that were created to enable rapid prototyping. Hundreds of such systems are available on dozens of platforms, each with its own features and problems. Some are called authoring tools, others prototyping languages, and others development platforms. What they share in common is a focus on making it easy for designers to build, and then to experience, interfaces and the programs that lie behind them. Three of these systems are profiled here, to illustrate Schrage's points about how prototyping tools affect both the activity and results of prototyping.
HyperCard
Bill Atkinson and his team developed HyperCard at Apple Computer
in 1987, as the next step in the path that Apple had proclaimed
in the slogan for the Macintosh: the computer for the rest of
us. HyperCard ushered in a new capacity of programming for the
rest of us, promising to enable every Macintosh user to become
an application designer. Since HyperCard was given away free
with every Macintosh system, it quickly became a widespread standard
(an example followed by later products, such as Mosaic, as described
in Profile 5). HyperCard's card-stack metaphor was appropriate
for many new applications, and led to a proliferation creative
programs that exploited its novel interface techniques. HyperCard's
primary place in software design, however, is due to its utility
as a general scriptable interface builder, providing direct-manipulation
creation of interfaces that are based on standard graphical user-interface
elements, such as icons, buttons, text fields, and scrolling
windows.
The writers of HyperCard applications range from sophisticated
interaction designers to schoolchildren. In fact, HyperCard is
now one of the most popular and widespread programming environments
for students from elementary school through college. HyperCard's
programming language, HyperTalk, differs from conventional programming
languages in using Englishlike constructions, such as "put
the number of this card into card field XYZ." This format
makes HyperTalk more approachable for novices, but is awkward
for experienced programmers.
The stacks (as programs are called) that have been built in HyperCard
range from juvenile exercises to sophisticated exploration games,
such as Spelunx (Cyan, 1991) and Earthquest (Earthquest, 1991).
It is impossible to show a typical HyperCard screen, since HyperCard's
facilities to draw artwork onto cards have been used to produce
every look imaginable. Figure 10.4 shows a demonstration stack
that comes with the HyperCard application, and is typical of
one widespread style of HyperCard use.
The HyperCard culture emphasizes ease of use, and encourages simple, playful designs. Although some HyperCard prototypes have a high degree of sophistication and polish, many are immediately recognizable as HyperCard by their use of common icons, buttons, clip art, and other standard visual elements. HyperCard's limitations, such as slow execution and limited support for use of color, have been ameliorated in later versions and successors, such as SuperCard, but the overall niche remains the same. For applications requiring complex computation, portability to different environments, and efficient performance, the HyperCard prototype is discarded after testing, and the final code is written in another programming environment.
Director
Macromedia's Director represents a point at the opposite end of the user spectrum from HyperCard. Director was designed for use by sophisticated multimedia developers, and rather than being bundled free, it costs several hundred dollars. Its appeal lies not in its ease of use, but rather in the sophisticated results that can be produced by users who are willing to learn complex mechanisms. In particular, it can be used for animations that are well beyond the capabilities of most other software-development languages.
The metaphor of Director (as its name suggests) is that of the stage or of an animated film. A Director application is built around a score, which represents a carefully coordinated and timed sequence of activities by a cast of characters. The basic programming structures offers frame-by-frame animation of the kind used in producing movie cartoons. By using Director's scripting language, Lingo, the designer can synchronize sound and motion in sophisticated ways. In contrast to HyperCard's aim to be usable on even the smallest Macintosh, Director emphasizes high-quality graphics, animation, sound, and video, and hence requires relatively high-end hardware. Although Director does provide support for standard Macintosh interface elements, such as buttons and text fields, it encourages designers to produce more open-ended and graphically original interfaces, making use of high resolution graphics, video, and animation (Figure 10.5).
Figure 10.5 Director Prototype This interface for exploring a music collection was designed by students in the program in Interaction Design at the Utrecht School of the Arts. It includes many active elements, such as the icons and menu items, and also the 3-dimensional data display, which can be rotated and modified by direct manipulation. (Source: Courtesy of the Utrecht School of the Arts.)
For specialized applications, such as a multimedia information kiosk, Director is suitable for a final product. In many other cases designers use it to give a polished demonstration of what an application might look like, concentrating on the interface without trying to implement all of the functionality. Since Lingo was developed as a supporting language for animation, rather than as a regular programming language, it is not well suited to performing sophisticated computation behind the interface.
Visual Basic
Visual Basic was developed for Microsoft's Windows operating system, which positioned it for a market different from the HyperCard users on the Macintosh. Instead of aiming for every schoolchild and home-recipe-book creator, Visual Basic was designed for professional system developers, who are competent programmers but are not user-interface wizards. Visual Basic is designed to enable a programmer to create interfaces using the facilities of the Windows environment with relative ease. Visual Basic is built around a simple, conventional programming language (a variant of Basic), in conjunction with a direct-manipulation interface builder. The designer can create and place standard interface elements, set and modify their properties, and associate them with programs that operate when they are invoked by a user of the interface.
A typical Visual Basic application does not have the flash and originality of many HyperCard stacks or Director prototypes, but instead operates within the normal interface conventions for Windows applications (Figure 10.6). The programming environment makes it easy for the designer to convert a Visual Basic project into an executable file that can be distributed and run by users who do not have the Visual Basic system, on any computer that runs Windows.
Figure 10.6 Application Built in Visual Basic This prototype for a workflow system makes use of standard Windows visual elements, such as a toolbar, buttons, tables, and checklists. (Source: Courtesy of Action Technologies.)
The Visual Basic culture emphasizes software engineering and programming values: efficiency of execution, straightforward logical design, and minimal use of machine resources, such as memory. The focus is not on making it beautiful, but rather on making it work. The integration of Visual Basic into the Windows system makes it possible to deliver end-applications that use Visual Basic interfaces and perform sophisticated computation, without incurring high computational costs. In this sense, we might think of Visual Basic as less of a prototyping language and more of a development language-many of the interfaces built with it are intended directly as products, rather than as footholds in the software design process (see Chapter 11).
Suggested Readings
Robert Arnson, Daniel Rosen, Mitchell Waite, and Jonathan Zuck. Waite Group's Microsoft Visual Basic How-To. Publishers Group West, 1990 (Second edition in press).
Danny Goodman. The Complete HyperCard 2.2 Handbook (Fourth edition). New York: Random House, 1993.
Jason Roberts. Drector Demystified. Berkeley, CA: Peach Pit Press, 1995.
Terry Winograd. Environments for software design. Communications
of the ACM, 38:6 (June 1995), 65-74.