1.2.1 Software Engineering

Software engineering is founded on the ideas of structured programming (Mills 1971): Programmers first define the major structures of a software system—the database, the event handler, and the network server, and so on—and then recursively decompose (break down) each structure into substructures. The driving vision is to gain control over design activities by making the software development process explicit and systematic.

An early and influential model for software engineering was the waterfall: software development is organized into a series of modular phases, beginning with the analysis of functional requirements, and continuing through software design, implementation, testing, and maintenance. Each phase produces one or more documents that are handed off as a specification for the work of the next phase. For example, the software design phase produces a design specification that is used by the implementation phase, which in turn produces the program code used in the integration phase. The waterfall is a wonderful management tool, because projects are organized, tracked, and measured in terms of progress through the phases.

Separating software development into modular phases is a good idea. However, as we will see again and again in this textbook, software development activities are filled with tradeoffs. Multiple views of design ideas are common, and progress in part requires understanding and working with competing arguments. In this book we use tradeoffs as a general organizing technique, to identify general issues with competing lines of argument. A major concern for any software development project is the identification, discussion, and resolution of tradeoffs (see the “Tradeoffs in Design” sidebar).

One tradeoff associated with waterfall methods is that many requirements for a system cannot be anticipated and specified in advance (as in the Virtual School example; see Tradeoff 1.1). Unanticipated dependencies or entirely new requirements are often discovered only after clients interact with a running prototype of a system (Brooks 1995). This suggests that requirements analysis must come at both the beginning and the end of the development process; in the extreme this means that you cannot know what to build until you first build the wrong system. At the least, this tradeoff demands some degree of testing and iteration in software development.

1.2.2 Prototyping and Iterative Development

The waterfall model offers a framework for addressing the software crisis, but is seen by many as idealized or simplistic. A strict linear flow of design specifications is unlikely to work for systems of nontrivial scale and complexity. Indeed, studies of programming practice have documented that skilled developers deliberately undermine waterfall methods (DeGrace & Stahl 1990).

A complement to structured development is prototyping, where designers develop one or more operational models to demonstrate a design idea. A prototype implements ideas that are abstract, making them concrete, viewable, and testable. By turning a proposal into a prototype, designers can test it for usefulness, feasibility, or other project concerns. Prototypes can be built at many phases; they can be used to evaluate requirements, high-level design, detailed software design, and so on (Boehm 1988). The feedback provided by prototyping is used to guide further development, but importantly, it may also be used to transform or reject aspects of the design.

However, prototyping and iteration create their own problems (Tradeoff 1.2). Process management can be difficult if the system evolves too rapidly to document and track the changes. Constant change can also undermine the integrity of a software design. It is difficult to schedule and deploy personnel in this paradigm, because the trajectory of the process unfolds over time, rather than being planned in advance.

One way to integrate prototyping with structured design is to view prototyping as a requirements analysis method—prototypes are built as trial versions of a system that will be later discarded (Brooks 1995). Another approach is to assume that prototyping will be used to revise design documents. In iterative development, design documents are produced as an output of each phase, but they are continually modified through prototyping and testing. The final version of the design specification describes the system that was built (Carroll & Rosson 1985).

1.3.1 The Emergence of Usability

As end users became more diverse and less technical, interactive systems came to be compared and evaluated with respect to usability—the quality of a system with respect to ease of learning, ease of use, and user satisfaction. The factors that make a system more or less usable are complex and are still the topic of considerable research. However, we can identify three distinct perspectives—human performance, learning and cognition, and collaborative activity—that have contributed to modern views of usability (Figure 1.4). Although these perspectives emerged at different points in time, they are not independent, and their relation is not one of succession. Rather they are complementary, pointing to the increasing richness of the general concept.

Figure 1.4 Three perspectives contributing to the general concept of usability.

1.3.2 Usability Engineering

The term usability engineering was coined by usability professionals from Digital Equipment Corporation (Good, et al. 1986). They used the term to refer to concepts and techniques for planning, achieving, and verifying objectives for system usability. The key idea is that measurable usability goals must be defined early in software development, and then assessed repeatedly during development to ensure that they are achieved (Bennett 1984; Gilb 1984).

From the start, usability engineering has relied on user interaction scenarios. For example, early proposals suggested that developers should track changes in performance times, errors, and user attitudes for specific task scenarios (Carroll & Rosson 1985). Such a process would allow developers to measure the impact of particular design changes on usability. Although the focus might be on the general implications of display features or commands, these functions would be considered in a concrete user interaction context.

Initially, usability engineering focused on the design of the user interface-on engineering effective interactive presentations of information and functions. More recently, the management of usability goals has been extended to other software development activities, particularly requirements analysis and system envisionment. This had a notable effect on software development documents: In the early 1980s, increased attention to usability led to the inclusion of user interaction scenarios as appendices in design specifications. By the late 1980s, such scenarios appeared at the front of these documents. Scenarios conveyed design concepts vividly and succinctly, and presented core functions within a meaningful usage context.

In the past 30 years, usability has become a central focus in software development. A 1992 survey of software developers reported that close to 50% of a system’s software is devoted to the user interface (Myers & Rosson 1992). But, as we have observed above, the scope of usability is actually far greater than user interface development. Today, usability engineers help to determine what functionality is necessary and appropriate, as well as how it should be presented.

Nevertheless, usability is not everything. Many issues and constraints that bear significantly on the development of usable software fall outside the scope of usability engineering, and are not addressed directly in this book. Examples include team formation, resource assignment, or dependencies on legacy systems. Such concerns may be addressed by the methods of software engineering, or by business activities such as resource planning and scheduling. However, such concerns can have an indirect influence on the final usability of an interactive software system. Table 1.1 lists a number of such concerns; these concerns are often referred to as nonfunctional requirements, because like usability, they form external constraints on a project that are not directly related to the functions it will provide (Sommerville 1992). For each concern we briefly indicate how it might influence the goals of usability engineering.

Table 1.1 Examples of other nonfunctional requirements in a system development project that might interact with usability concerns.

Ultimately, software development is driven by economics. Even in a research setting where systems are designed to demonstrate or explore new concepts, project managers must make wise choices about relative costs and benefits of design features (Bias & Mayhew 1994; Karat 1993). As a simple example, a system that requires communication support can include email with considerably less cost than a collaborative virtual environment. Usability experts may argue persuasively for the latter, but the decision maker must consider usability benefits in light of many other constraints such as those summarized in Table 1.1. While we acknowledge this, the presentation in this book focuses more narrowly on usability issues—the manner in which a system supports users’ work activities, the relative ease with which the system is learned and used, and the satisfaction that its users experience.

1.4.1 User Interaction Scenarios

A user interaction scenario is a story about people and their activities (Carroll & Rosson 1990). For example, suppose an accountant wishes to open a folder displayed on his screen in order to open and read a memo. However, the folder is covered by a budget spreadsheet that he also needs to see while reading the memo. The spreadsheet is so large that it nearly fills the display. The accountant pauses for several seconds, then resizes the spreadsheet, moves it partially out of the display, opens the folder, opens the memo, resizes and repositions the memo, and continues working.

This is about as routine a work scenario as one could imagine. Yet even this story conveys important information about window management and application switching: People need to coordinate information sources, to compare, copy, and integrate data from multiple applications; computer displays inevitably get cluttered; and people must find and rearrange windows in these displays. Scenarios highlight goals that are suggested by the appearance and behavior of a system; what people try to do with the system; what procedures are adopted, not adopted, and carried out successfully or unsuccessfully; and what interpretations people make of what happens to them.

Scenarios have characteristic elements (Table 1.2). They include or presuppose a setting or starting state. The accountant scenario describes the starting state for the episode: the relative positions of the folder and spreadsheet and the presence of a single user. Other setting factors are implied by identifying the person as an accountant, and the work objects as budgets and memos.

Table 1.2 Characteristic elements of user interaction scenarios.

Scenarios describe the behaviors and experiences of actors: There is just one actor in the example, but many human activities involve several or even many actors. Each actor has task goals. These are changes that the actor wishes to achieve in the circumstances of the setting. Every scenario involves at least one actor and at least one task goal. When multiple actors or goals are involved, some are usually more prominent than others. Often one goal is the highest-level scenario goal; this high-level goal answers the question “why did this story happen?” Similarly, one actor often has a principal role, the answer to the question “who is this story about?”

In the accountant scenario, the high-level goal is to compare the budget and memo information. A lower-level goal (often called a subgoal) is opening the folder that contains the memo; a further subgoal is resizing and moving the spreadsheet to expose the folder. Each goal or subgoal of a scenario is tied to efforts aimed at achieving the goal. Translating a goal into action and making sense of what happens afterward usually take place inside the actor’s mind. But sometimes this mental activity is important to a situation, so scenarios usually include information about planning and evaluation. The emphasis on people’s changing goals, plans, and understandings is one thing that distinguishes user interaction scenarios from the related software engineering concept of use cases (see “Use Cases” sidebar).

Scenarios have a plot; they include sequences of actions and events, things that actors do, things that happen to them, changes in the setting, and so forth. These actions and events may aid, obstruct, or be irrelevant to goal achievement. Resizing and moving the spreadsheet supports the goal of opening the folder. Resizing and moving the memo displays it in a way that enables simultaneous viewing with the spreadsheet. Pausing does not contribute directly to task goals, although it suggests that the accountant’s actions were not completely fluent or automatic.

Representing the use of a system or application with a set of user interaction scenarios makes the system’s use explicit, and in doing so orients design and analysis toward a broader view of computers. It can help designers and analysts to focus attention on assumptions about people and their tasks. Scenario representations can be elaborated as prototypes, through the use of storyboards, videos, or rapid prototyping tools (Chapter 6).

1.4.2 Why Scenarios?

Design and engineering always involve the management of tradeoffs. For example, the focus in usability engineering is often on “throughput”—optimizing user performance. However, usability engineers typically measure user satisfaction as well, and this does not always improve when performance is made more efficient (e.g., users may be required to learn complex keystroke combinations to speed interaction). Such a disparity between performance and satisfaction is not always problematic. Sometimes efficient performance is the highest-priority goal, and as long as user satisfaction stays within specified limits, the product meets its usability goals. But if a team is trying to optimize both performance and satisfaction, difficult tradeoffs may arise.

Explicit usability objectives—such as a 20% reduction in performance times—are needed to guide the usability engineering process (Bennett 1984; Gilb 1984). They take an abstract usability goal such as “more efficient human performance” and make it concrete and testable. These usability objectives must be clear and specific to be effective. They should be related to what people know and can do and what they wish to accomplish. They should state what will indicate success and what experience a user should have when carrying out a set of task actions and obtaining results.

At the same time, there is no guarantee that the starting goals of an engineering process are appropriate or even attainable. Sometimes good ideas are simply not practical: People may not accept the training needed to fully utilize a system’s capabilities. The display hardware may not have the required resolution. Thus, while explicit and measurable goals are necessary, any particular goal may ultimately be discarded.

Scenario descriptions can be very useful in managing the tradeoffs of usability engineering (Figure 1.5). For example, scenarios are both concrete and flexible. A scenario can say what happens in a particular situation without committing to details of precisely how things happen. Much of the richness of a scenario is in the things that are not said. A scenario specifies its actors’ goals and behaviors, and these can be arbitrarily detailed. Yet a scenario narrative is easily modified or elaborated, and can be made deliberately incomplete to help developers cope with uncertainty.

Figure 1.5 Tradeoffs in usability engineering addressed by scenarios. Numbers in figure correspond to the tradeoff numbers in the text.

The concrete and flexible character of scenarios addresses the tension between wanting to make progress quickly but at the same time keeping the design space open for further change (Tradeoff 1.3). Designers can use scenarios to try out ideas and get feedback. But scenarios can be revised quickly and easily, helping to avoid premature commitment. Sharing and developing scenarios helps to control the uncertainties of design work, while sharpening and strengthening design goals.

Another tradeoff in usability engineering is related to the observation that people’s activities co-evolve with the technology they use: Designers must understand people’s tasks to be able to support them with technology, but the new technology will change what people do (Tradeoff 1.4). For example, early spreadsheet programs revolutionized budget management. That success caused an increase in time spent using spreadsheet programs, which in turn caused spreadsheet users to develop new needs (Nielsen, et al. 1986). They wanted better support for budget projections, and better integration with other computer-based tasks, such as planning, communicating, and presenting information. Subsequent spreadsheet programs were designed to provide this support.

Scenarios help designers respond to current needs while also anticipating new needs. They offer insight into meaningful situations, but at the same time do not imply that things will stay the same. They describe systems in terms of the goals that people will be pursuing as they use the system. Scenarios focus designers on the needs and concerns of people in the real world.

Most designers hope to facilitate human activity with elegant and innovative systems. Everyone wants to invent the replacement to the spreadsheet or a better Web authoring language. However, not all elegant and innovative ideas will succeed like the spreadsheet or HTML; even elegant and innovative functionality can sometimes undermine usability (Tradeoff 1.5).

Sometimes good ideas are ahead of their time. In 1982, IBM produced the Audio Distribution System, a digital phone messaging system that even by today’s standards had a very powerful set of file management and editing features. But the product did not do well in a marketplace oriented to analog phone answering technology—it was too advanced for the time. It required too much learning and too much conceptual change by users.

Software applications that are developed and refined over many versions often suffer from “creeping feature-itis.” In searching for novel and elegant design ideas, developers can lose sight of people and their tasks. They push the technology envelope, but they do not create useful systems. Unfortunately, when functions do not contribute to the solution, they can become the problem: Unneeded functions create a learning burden for new users and continuing confusion for more experienced users.

Scenarios address this tradeoff by focusing software development on use, rather than on features that might enhance use. While it is certainly important for developers to push ahead with new technologies, pursuing them on a feature-by-feature basis invites side effects. Changing any individual user interface feature may impact the consistency of displays and controls throughout; it may even raise requirements for new functionality. Scenario-based analysis helps designers to steer between the twin risks of overconfidence (attempting to accomplish too much) and conservatism (attempting to do too little).

Yet another tradeoff concerns communication and collaboration in software projects. Programmers often use technical design representations (e.g., a data flow diagram) to express and share ideas; managers use their own specialized representations (e.g., a job specification) to describe their needs. These special-purpose representations increase the precision of communication. But they may also exclude participation by some individuals or groups who are important to successful development (Tradeoff 1.6). For example, end users are likely to have trouble following a data flow diagram; programmers may not understand the details or implications of a personnel description.

Scenarios address this tradeoff by using a universally accessible language: All project members can “speak” the language of scenarios. Scenarios facilitate participatory design—design work that takes place as a collaboration between developers and the people who will use the system (Muller 1991, 1992). Scenarios help to integrate many different kinds of knowledge and experience by simplifying communication among different kinds of experts. Within a development team, scenarios assist in handoff and coordination, by maintaining a guiding vision of the project’s goals.

A final usability engineering tradeoff comes in the conflict between thinking and doing. Developers want to take action and make progress quickly, but too great a focus on software construction can work against the reflection and analysis needed to discover and implement high-quality design solutions (Tradeoff 1.7). Developers naturally reflect on their activities as they work. However, as humans we take pride not only in what we know and learn, but in what we can show at the end of the day. It is impossible to predict or understand everything in advance, and long discussions of alternatives can be frustrating. People want to act, to make decisions, to see progress.

Design review meetings are often used for reflection. In such meetings interim results are evaluated by working through objectives, progress reports, specifications, and so on. Such reviews can improve design work in many ways, by clarifying problems, alternatives, or decisions. However, a review meeting removes designers from the day-to-day context of their work; they must stop working to reflect.

The evocative nature of scenarios helps to address this. By telling a concrete story of user interaction, a scenario conveys a vivid image of what the system will do. It stimulates imagination and encourages “what-if” reasoning about alternatives. In a scenario it is easy to change the values of several variables at once and then think about the new states or events that might transpire. With scenarios designers can integrate their thinking about features that will or will not meet users’ needs with the construction of situations that illustrate these thoughts.

Ultimately, the success of a design project depends on the care with which the problem is analyzed and solved. Scenarios are not a solution to a shoddy engineering process: If a team is unwilling or unable to take the time to analyze the needs of users, assess the available technology, and consider alternative solutions, only excellent design intuitions or simple luck will lead to good outcomes. However, scenarios are a lightweight usage-centered design representation that keeps designers focused on the overall goal of usability engineering—a useful and usable system.

1.5.1 Analysis

The successive transformation of scenarios in SBD echoes the phases of software development—scenarios are used to analyze requirements, envision new designs, guide prototyping and implementation, and organize evaluation. In requirements analysis, the problem situation is studied through interviews with clients and other users (the stakeholders), field studies of the current situation, and brainstorming among users and developers. This input is used to formulate problem scenarios that convey important characteristics of the users, the typical and critical tasks they engage in, the tools they use, and their organizational context (Chapter 2).

A key contribution of scenarios during requirements analysis is that they evoke reflection and discussion. Writing down a narrative of one situation almost immediately raises questions about other situations, about why this situation (these users, these tasks) works the way it does, and how other situations might work differently. The concrete and narrative character of scenarios also facilitates mutual understanding and communication among the different groups who participate in requirements analysis.

In SBD, the analysis and refinement of scenarios is stimulated by claims, statements that list important features of a situation and their impacts on users’ experiences. In requirements analysis, these features are elements in the current situation; as the scenario content shifts from analysis to design, the claims call out features of the proposed solution. Claims are related to the general notion of tradeoffs in design, because they always analyze both positive and negative usability impacts. The analysis of claims organizes and documents the “what-if” discussions the design team carries out when considering and prioritizing alternatives.

1.5.2 Design

The hub of any software development process is design—moving a project from problem understanding to envisioned solutions. As a creative act, design often seems mysterious. Requirements analysis can be overwhelming, but at least it is anchored in the needs and possibilities of an observable situation. Evaluation can also seem vast, but it too is anchored in the activities of real users working with concrete design ideas or prototypes. Design stands between the two, vaguely indicating that a miracle occurs.

SBD organizes design into three substages with a rough ordering. First, developers envision activity scenarios—narratives of typical or critical services that people will seek from the system (Chapter 3). These early scenarios provide a concrete glimpse of the future that the designers are trying to enable through their efforts. However, they deliberately focus on pure functionality, refraining from specifying details about what the system will look like or how users will manipulate it.

In the second design substage the team produces information scenarios. These are elaborations of activity scenarios that provide details about the information that the system will provide to users. There are many complexities to information scenarios. It is more than merely a matter of making it possible for people to see things on a computer display (Chapter 4).

The third substage involves the design of interaction scenarios. These scenarios describe the details of user action and feedback (Chapter 5). Each interaction scenario is a fully specified design vision: the users and task(s) being supported, the information needed to carry out the task, the actions the users take to interact with the task information, and the responses the system provides to users’ actions.

System design does not happen in a vacuum. Although the designers using SBD methods begin with problem scenarios, they must actively search for new ideas to use in transforming the problem scenarios into design scenarios. They draw on many resources in this—analogies to real-world situations and objects, and their own knowledge of current information technology, along with their understanding of human abilities and preferences and relevant design guidelines. Throughout the design process, claims analysis is used to identify and discuss key features and usability tradeoffs.

As with requirements analysis, the reflection and discussion promoted by scenarios facilitate design at points where it is crucial to consider alternatives, and to work through the implications of design decisions. Scenarios are easy to write and change, so they support fluid and creative design reasoning. Again, as for requirements, the concrete and familiar form of scenarios enables input from many different interested parties.

1.5.3 Prototyping and Evaluation

SBD assumes that design ideas will be evaluated in a continuing fashion. This is often accomplished via a prototype that implements or demonstrates one or more pieces of the solution proposed in a scenario. Prototypes may be constructed at many points in design and with many different degrees of completeness or polish (Chapter 6).

A prototype can take many forms. For example, a very rough sketch could be used to prototype an activity scenario. Details of system interaction would not be specified, but people could evaluate the sketch in the context of the scenario, critique it, act out the scenario, explain it to peers, and so on. Potential users could read the scenario and look at the sketch, as an aid to considering whether the envisioned scenario meets their requirements, and how it might be elaborated to meet their information and interaction needs.

In SBD we distinguish between formative evaluation, which is carried out to guide redesign, and summative evaluation, which serves a system verification function (Chapter 7). Questions involved in the latter are: Have we actually built the system that was envisioned and specified? Did we meet or exceed the usability goals quantified in the usability specifications? In product development, summative evaluation is sometimes called the “go/no-go” test. If the product fails in summative evaluation, the process may start over (perhaps with a new product manager!).

In contrast, formative evaluation is aimed at improving a design prototype, not merely measuring overall quality. It asks questions such as: What is working poorly? Why? What changes might fix the problem? By the time the development process carries out a summative evaluation, it may be sufficient to know simply whether goals have been met. But earlier in the process, the development team needs information that can guide further development.

Scenarios guide evaluation through usability specifications—user tasks with specified usability outcomes that are evaluated repeatedly to guide redesign work. Scenario narratives describe the actors and their motivation, and other situation details that may influence people’s ability to use or appreciate a prototype. Scenarios also predict the kinds of goals and reactions an evaluator will observe. As scenarios become more refined and concrete, they describe usability objectives more precisely, such as indicating how long a sequence of actions should take, or what reaction a piece of system feedback should provoke. In this sense, a scenario can be seen as a set of hypotheses about system use.

1.5.4 Other Approaches

All software development methods—and this includes all usability engineering methods—struggle with the tension between a waterfall with well-specified handoffs, and a flexible prototyping approach. Resolving the tradeoffs between these two perspectives will almost always lead to a linear development flow, accompanied by iterative feedback and reworking.

A good example is seen in Mayhew’s (1999) usability lifecycle. This framework incorporates five major phases: requirements analysis, conceptual model design, screen design, detailed user interface design, and installation. Prototyping and iteration are integrated within a waterfall—all phases except requirements analysis include assessment activities that support iteration. The three central design phases (conceptual model design, screen design, and detailed user interface design) also include a combined assessment of whether all functionality has been addressed. If that assessment is not satisfactory, the process returns to requirements analysis.

Mayhew’s usability lifecycle corresponds closely to the flow of analysis and development in SBD. One difference is in the role of scenarios in SBD as a unifying design representation. For Mayhew, the output of requirements analysis is a list of goals; the output of conceptual model design is a paper or computerized mock-up. In SBD the output of any phase includes user interaction scenarios. A secondary contrast is that SBD emphasizes the documentation and reasoning about tradeoffs throughout development.

Other general approaches to usability engineering include Nielsen’s (1992) work on heuristic evaluation, Beyer and Holtzblatt’s (1998) contextual design, and Constantine and Lockwood’s (1999) essential use cases. As an eclectic framework, SBD shares features with all of these approaches: a mixture of analysis and design techniques, an emphasis on the detailed context of use, and an early emphasis on the basic functionality that users want. SBD differs from all of these other approaches in its central reliance on user interaction scenarios as an ongoing source of insight and reasoning about users’ needs and experiences.

1.6.1 Case Study: A Virtual Science Fair in MOOsburg

Our example is drawn from a community network research project. HCI researchers at Virginia Tech are working with the town of Blacksburg, Virginia, on a community network system called MOOsburg (see http://moosburg.cs.vt.edu). MOOsburg is a MOO—a collaborative environment modeled on a geographic space, in this case the town of Blacksburg. People use MOOsburg to post or review community information (as they might also do using conventional Web sites; see http://www.bev.net). However, MOOsburg also provides a variety of shared interactive tools such as chat, electronic whiteboard and notebook, message board, calendar, simulations, and so on (Carroll, et al. 2001, 2001b). Co-present visitors can interact directly with these tools. Visitors can also create or modify objects for later use.

Figure 1.7 shows three people visiting a local history museum in MOOsburg. The main view displays a panorama of the real-world museum; using the field-of-view control at the upper left, visitors can rotate the image to see the entire room. In front of the image are icons representing the three people online at this location. The visitors are using the text chat tool to discuss some of the exhibits. On the right is a toolbox from which they can create other objects for collaborative activities—for example, a shared whiteboard or a message board.

Figure 1.7 The MOOsburg system for community interaction in Blacksburg, Virginia.

The map at the lower right is used to navigate to the virtual museum. The map corresponds to the real-world map of Blacksburg, and the virtual museum has been positioned at the real museum’s street location in the town. MOOsburg users navigate by selecting dots on the map—each blue dot is an online site that can be visited; and places with other visitors are displayed in green. The map is zoomable, so that visitors can get an overview of the entire town (just the main roads show at the highest level) or zoom into a very detailed view (all roads, streets, and buildings are displayed). In this screen shot the user has zoomed in enough to see the building outlines.

MOOsburg has been explored and extended through the development of specific activities and tools within the general collaborative framework. We chart the development of one of these activities—a virtual science fair (VSF)—as the case study. The virtual science fair uses MOOsburg tools (e.g., email, online chat, discussion forums, and multimedia displays) to create a supplement to a traditional American science fair.

In a science fair, students develop individual projects. They exhibit their projects at the fair, where the exhibits are judged and awarded prizes. Although a science project is developed over many months, the fair itself takes place over a few hours. Science fairs are open to the public, but normally are attended by the participating students and their friends and families. The high-level concept for the virtual science fair is to extend the boundaries of a traditional science fair. Using MOOsburg, we hope to make the fair attractive and accessible to a larger group of community members, and to enrich the activities of exhibit construction, viewing, and judging.

The science fair case study will be presented in a cumulative fashion to illustrate the SBD process shown earlier in Figure 1.6. The central elements are covered in Chapters 2 through 8 (Table 1.3). Chapter 2 covers techniques for analyzing a problem situation (in this case a traditional science fair), and generating problem scenarios. Chapters 3 through 5 cover the three phases of design, first focusing on the activities that will be supported, then elaborating the scenarios to include the details of information representation and interaction techniques. Chapter 6 describes the creation of virtual science fair prototypes, and Chapter 7 illustrates how these prototypes can be used in usability evaluation. Chapter 8 illustrates the special design problem of creating effective learning and help materials.

Table 1.3 Scenario-based design techniques and methods illustrated by the virtual science fair case study.

Some of the case study materials presented in the book were developed in the MOOsburg project; others were created to serve the educational goals of this textbook. The result is a comprehensive model for students or practitioners who wish to apply scenario-based methods to usability engineering projects. At the same time, the science fair project has several domain-specific characteristics, including the following:

Thus, while the methods illustrated are general, students will find that not all details will map directly to other usability engineering projects. Other examples can be found on the textbook’s Web site (www.mkp.com/ue-sbd).

Recommended Reading

Brooks, F. 1995. The Mythical Man-Month: Essays on Software Engineering. Anniversary ed. Reading, MA: Addison-Wesley.

Carroll, J. M. 2000. Making Use: Scenario-Based Design of Human-Computer Interactions. Cambridge, MA: MIT Press.

Carroll, J. M., ed. 1995. Scenario-Based Design: Envisioning Work and Technology in System Development. New York: John Wiley & Sons.

Jacobson, I., M. Christersson, P. Jonsson, & G. Övergaard. 1992. Object-Oriented Software Engineering: A Use Case Driven Approach. Reading, MA: Addison-Wesley.

Mayhew, D. J. 1999. The Usability Engineering Lifecycle: A Practitioner’s Handbook for User Interface Design. San Francisco: Morgan Kaufmann.

Sommerville, I. 1992. Software Engineering. 4th ed. Reading, MA: Addison-Wesley.

PLATE 1 Screen shots of some of the tools making up the Virtual School.

PLATE 2 The MOOsburg system for community interaction in Blacksburg, Virginia.