Mary Beth Rosson and John M.Carroll
We describe an approach to developing object-oriented applications that seeks to integrate the design of
user tasks with the design of software implementing these tasks. Using the Scenario Browser -- an
experimental environment for developing Smalltalk applications -- a designer employs a single set of task
scenarios to envision and reason about user needs and concerns and to experiment with and refine object-
oriented software abstractions. We argue that the shared context provided by the scenarios promotes rapid
feedback between usage and software concerns, so that mutual constraints and opportunities can be
recognized and addressed early and continuingly in the development process.
In contemporary design practice for applications and user interfaces, task scenarios are a medium for
reasoning about user activities; they are used for requirements capture and analysis, user-designer
communication, system envisionment and development, documentation and training, usability evaluation.
Scenarios have raised the hopes of many in human-computer interaction for an integrated design
framework.
Nevertheless, scenario-based design methods are not a mature technology; currently they are not even a
coherent methodology (see, e.g., the discussion in the April 1992 issue of SIGCHI Bulletin). For
example, there is little consensus about the appropriate level or levels at which to couch scenario
descriptions: is it the level of self-conscious human activity, the level of input and output transactions, or is
it both? What implications arise from couching scenario descriptions at different levels? What are the
procedures and representations for doing this? It is more than likely that at the current time no developer or
practitioner of scenario-based methods would render the same answers to these questions.
Scenario-based methods also raise a serious -- indeed classic -- system development issue: Will scenario
design representations increase the "gap" between specification and implementation? While much
work in software engineering in past decade has been directed at narrowing this gap [9, 16], it seems prima
facie that a focus on detailed narratives of user interaction may widen it anew.
Researchers studying object-oriented design (OOD) have developed scenario-based approaches that
complement those used in the design of human-computer interaction: scenarios are often used in
developing a problem domain model, which is then further elaborated and refined to build an object-
oriented design [6, 10, 15, 17] By using scenarios as a source of important problem objects and their
interactions, these approaches narrow the gap between specification and implementation. However, the
OOD methods are not focussed on reasoning about user tasks -- they use the scenarios to gain insight into
possible software models.
We are trying to integrate these complementary uses of scenarios in design. In this paper we describe our
work with the Scenario Browser, an experimental design environment for Smalltalk applications, in which a
single set of task scenarios is used both to envision and reason about user needs and concerns, and to model
and refine object-oriented abstractions that implement these tasks. For concreteness, our discussion focuses
on an example application (a bibliography utility) developed using the tool. We begin with an overview of
how the applications are developed in the Scenario Browser environment, then consider in more depth the
issues of scenario evolution, completeness, consistency, task prototyping and object-based task models that
arise in this approach to application development.
We assume a view of scenarios as couched at the level people construe their work to themselves, the level at
which tasks become meaningful to the people who carry them out. For a person building our example
bibliography utility, example scenarios might be "making a note of an interesting multi-media education
article from Jack", "looking up the Singley reference", "adding the Lange&Moher CHI paper on reuse", and
so forth. Our design method involves generating scenarios -- narrative descriptions of specific task episodes
-- to document requirements, problems, and goals, and from this to systematically envision reason about,
and debate design solutions [4].
In the Scenario Browser environment, the designer uses a Scenario View to create and elaborate textual
versions of the task scenarios. Figure 1 shows such a view being used to develop a bibliography scenario.
FIGURE 1: A Scenario View of the bibliography application.
In developing these task narratives, the designer might start with a few general situations, using them as a
heuristic for generating a broad range of user concerns [4]. So, for example, a common situation involves
the carrying out of straightforward procedures. The addition of a reference would normally be such a task
(in Figure 1, this is indicated by the prefix HOW-TO); in contrast, browsing someone else's reference for
interesting article reflects opportunistic behavior.
FIGURE 2: A Claims View of the conference paper scenario.
Figure 2 displays a Claims View of the conference paper scenario described above. Designers use this view
to record usability rationale associated with individual scenarios, in the form of claims [4]. A claim
is a causal hypothesis about some aspect of the scenario; it relates features of the system in use to one or
more possible consequences for the user (positive consequences appear in the middle pane, negative in the
bottom). Early in development, these claims may reflect analytic work by the designers; later on, they may
incorporate observations obtained through usability testing. At any point in development, however, the
claims analyzed for a scenario represent the designers' current best guesses about the usability issues
pertaining to that particular use situation.
In the example scenario -- adding the Lange and Moher CHI'89 paper -- we considered that users might
want to create a personal nickname for the reference. As the scenario suggests, this feature could have
various consequences for a user: The user might benefit from being able to make use of personal
experience and article content to build a more meaningful citation name. On the other hand, people are
often unreliable at designing names, and the user might have difficulties, might even create a quirky
nickname that is rapidly forgotten, necessitating wasteful search. By recording these hypothesized
consequences, we identified this scenario as one context for considering usability issues associated with the
nicknaming feature.
Our design approach concentrates on developing a coherent set of basic tasks first and only then developing
an effective user interface to these tasks. One consequence of this is that most of the early scenarios are of
the "How-to" variety -- this situation includes the basic tasks a user can perform with a system. The other
situations emerge once the system has been elaborated enough to evoke or facilitate particular goals or
problem-solving strategies in the user. For example, "Why" scenarios normally describe situations in which
the user is trying to understand an unexpected or problematic response from the system; envisioning such
situations requires that a fairly detailed progression of user actions and system responses has been specified.
As soon as a task has been described -- at any level of detail -- the designer can begin building software to
implement this specification. In Smalltalk, this consists of creating and refining an object model of the
scenario: Smalltalk objects are created, connected to one another, and given scenario-relevant behaviors.
Depending on the degree of elaboration provided by a scenario, this object model may be more or less
complete. However, even if just one object can be modeled, the designer can begin experimenting with this
part of the scenario implementation, sending test messages to the object, and refining its characteristics and
behavior.
Incremental software development in the Scenario Browser environment is supported by the
Implementation View (on the left in Figure 3), Bittitalk Browser (upper right in Figure 3) and Software
Claims View (lower right in Figure 3). The designer can either instantiate classes already existing in the
system (e.g., creating an instance of OrderedCollection to serve as the "refs" object) or create and
instantiate new classes to represent new abstractions (e.g., a Name class that structures the text components
of author names). The objects created to implement a scenario are graphed in the lower pane of the
Implementation View, so that the designer can see a visual representation of the various cooperating
Smalltalk objects and their relation to one another (Smalltalk objects "point" to one another via instance
variables, and these are graphed as arcs). The Bittitalk Browser provides access to the class definitions
behind the instances in the object model -- this tool is identical to the standard Smalltalk/V class browser,
but instead of providing access to the entire (and very large) Smalltalk/V class hierarchy, it lists only the
classes currently being used to implement a scenario [14].
From the perspective of object-oriented design, an important characteristic of our approach is that the
software development is instance-centered: the designer develops new abstractions (classes) and
behaviors (methods) by creating and experimenting with instances playing various roles in a scenario, rather
than focussing on the more abstract task of writing class definitions and methods in a class hierarchy
browser [7]. The testing and refinement of objects in the model is driven by the needs of specific scenarios.
So, for example, in working on the conference paper scenario, we first used strings to model author names
(i.e., ÔBeth M. Lange'); as we elaborated the scenario to include visual feedback to the user, these string
implementations were replaced by instances of the new class Name, which contained more intelligence
about the structure of names.
The concrete situations provided by individual task scenarios promote the analysis of object responsibilities,
a fundamental aspect of OOD [6, 15, 17]. But from the perspective of usability, they also create a focus on
tasks during the implementation of an application. Thus any software design issues or alternatives
that arise can be considered in light of specific tasks that they might impact, at the time that the
issues first surface. Designers can use the Software Claims View to encode an explicit analysis of such
issues. In the example, we have noted some trade-offs associated with holding the bibliographic entries in a
separate "storage" object.
The scenario framework also supports communication between the designer and "user" of the bibilography
(the first author used the Scenario Browser to build the bibliography utility, with requirements obtained in
conversation with the second author). Designer-user communication has long been recognized as a problem
in development, in that designers tend to think and talk about design objects, while users think and talk
about tasks [8]. A number of researchers have argued that building object-oriented design models should
ease this communication, in that the main elements of the software model will be objects from the problem
domain [1, 12]. We found that task scenarios did provide a concrete medium for questions and
clarifications concerning the user's needs and preferences: bits of functionality could be described or
demonstrated and alternatives considered (with reference to the current usability or software rationale), with
the relevant scenario serving as a shared context for discussion.
To sum up, object-oriented applications are developed in the Scenario Browser environment through an
integrated process of scenario specification and implementation. Tasks are specified and analyzed for
usability issues in parallel with the development and analysis of object models that implement the tasks.
We now turn to some of the general issues raised by this approach to application development.
Developing an application through the creation and elaboration of task scenarios is an evolutionary process
in which analysis and experimentation with individual scenarios reveals increasingly more about task and
software requirements. In the simplest cases, scenarios develop through accretion -- successively more of
the problem requirements are specified and implemented. For the task specifications, this involves adding
textual description. But for the scenario implementations, it means adding or altering computational
objects.
As long as the designer has anticipated the nature of the relevant software abstractions, additional objects
can be instantiated and integrated seamlessly into the developing object model for a scenario. However,
designers cannot anticipate all of the elements needed in an object model, and some refinements will require
changing the abstraction (class) behind one or more objects already in the model; in Smalltalk/V, such a
modification is difficult.
For example, our initial object model of the conference paper scenario did not include the date and location
of the conference. Later, while working on a formatting scenario, we recognized that some reference
formats require this information, and so needed to elaborate the conference paper object accordingly. In the
standard Smalltalk environment, we would have been forced to destroy the conference paper object already
in the model, add the new structural information (to the class definition for that object), and then re-build
the object. The Scenario Browser environment eased this object model evolution by allowing us to add to
(or remove) an existing object's attributes, so that we were able to add elements to a scenario without
destroying and rebuilding the existing context.
The Scenario Browser also supports cases in which design objects are re-engineerd (i.e., not merely added
to an object model). Any object in the implementation of a scenario can "mutate" to a new kind of object
(i.e., class), without disrupting its current role in the model. For example, the conference paper was
originally modeled as a relatively simple object, whose state consisted largely of strings and collections of
strings (e.g., title, authors, proceedings title and editors). At a later point, we reconceptualized conference
papers as objects that contain information specific to a paper (e.g., title, authors), but whose conference
information (e.g., proceedings title, editor) is held by a second reference object, a conference proceedings.
Again, in most object-oriented environments, the original object model would have been thrown away and
re-implemented to reflect the new abstraction. However, we were able to use the tools in the Scenario
Browser environment to "split" the original conference paper object into two objects -- instances of the
revised conference paper class and the new conference proceedings class.
A development process that relies heavily on scenarios must be very sensitive to issues of completeness:
How many scenarios are sufficient as a specification for a system? Should we expect that the scenario set
covers all of the intended functionality? In our earlier work, we have have found that a dozen or so key
scenarios have provided a good specification for systems under design. [4]. Clearly, however, we would
not recommend that designers implement exactly and only these dozen or so tasks; the software solution to
a problem must be a general one.
In our bibliography utility scenarios, the object model we built for any given scenario was much more
general than its specification. This appears to be a natural consequence of moving to a more symbolic and
abstract representation (i.e., the domain of algorithmic entities). Whereas a task narrative focusses on the
detailed goals and experiences of the user in a particular situation, the object model implicitly
covers many variations of a scenario, for example, strings of varying length, typing errors, missing data and
so on. In this sense, the "scenario" that we implemented can be seen as a kind of use case in the sense of
Jacobson et al. [10]. Some of the considerations bearing on this generalization process are captured in a
scenario's software claims; others are captured more informally as textual notes (e.g., in the workspace
section of the Implementation View).
Another critical issue for scenario-based design methods is maintaining consistency across scenarios.
Scenario elaboration can be viewed as a bottom-up approach to design problem-solving, with an emphasis
on the rich context provided by specific task situations. However, modeling the details of each particular
task setting might introduce inconsistencies in the overall design. For example, we began our work on the
conference paper object in the context of reference-entry tasks, and the view we developed reflected our
analysis of how users think of references when adding them to a database (e.g., with components ordered in
the fashion they are normally seen, with the option of a personalized encoding). In contrast, a designer
working initially on another scenario -- browsing OOD design papers perhaps -- might have come up with a
rather different concept of a reference, one that was heavily weighted with attributes representing relations
among references.
An explicit integration of scenario descriptions and their implementations can promote consistency in the
overall design. For example, an important aspect of OOD is the development of abstraction hierarchies --
abstract classes are used to define shared characteristics of related objects; subclasses then "inherit" the
shared behavior, leading to a more efficient design. For designers modeling an object in a specific scenario,
then, one design issue concerns the attributes or behavior this object might share with objects in other
scenarios. Our first bibliography scenario modeled just one reference item, a conference paper. When we
moved to other scenarios involving different kinds of reference items, however, we began to create a
"BiblioReference" hierarchy (see the Bittitalk Browser in Figure 3); as additional scenarios were designed,
this hierarchy was expanded and refactored.
The Scenario Browser environment also supports the reuse of pieces of object models developed in
different scenarios. At any point, the designer can "grab" any object modeled in an existing scenario
implementation, and incorporate it into a new scenario. Thus, several of our object models used the Lange
and Moher conference paper, but in different roles (e.g., creating it, citing it in a document, updating it).
Rather than building a new conference paper instance for each case, we simply carried our original object
from scenario to scenario, elaborating it as needed for the new settings. Through such reuse we ensured that
we always had a single, consistent implementation for this problem entity.
Of course, changing the implementation of an object in a second scenario can cause a scenario implemented
earlier to "break": the other objects in this earlier scenario may no longer be able to communicate correctly
with the changed object. When we "split" the Lange & Moher conference paper object into two objects (the
paper and its proceedings), we went back to other scenarios whose implementations used this object and
updated them as necessary. The Scenario Browser anticipates such a re-engineering process by providing
direct access to all other scenario implementations using ann given object.
A more analytic approach to consistency management is to withdraw periodically from work on individual
scenarios, to take a more cumulative view of the developing application. In the Scenario Browser
environment, views of the objects, classes, and rationale developed across all scenarios are available. The
designer can analyze a cumulative object graph for related but inconsistent objects, or for missed
opportunities for abstraction. Our bibliography application was developed by one designer, but a system
developed by a group of designers, or over a more extended time period, would be more prone to
inconsistencies and redundancies (e.g., two different instantiations of the "same" conference proceedings
object, one named chi89, the other chi1989). By analyzing the objects in a cumulative graph and the roles
that they are playing, a designer may discover objects whose functionality is identical or overlapping, and
carry out appropriate modifications (e.g., breaking up one object into two or more others, replacing one
object with another, combining one or more objects into a single new object).
User tasks and the software designed to support them are interdependent. Tasks set requirements for new
systems; as systems are developed, their software and hardware characteristics create constraints or
opportunities for the tasks [2]. Many development projects manage this mutual interdependency through
tight feedback loops between task specification and implementation, codifying specifications in prototypes
early and repeatedly to "try out" on users [11]. The approach we have described can be seen as a
refinement of rapid prototyping: it encourages early and continued testing of a design specification, even
before a conventional "user interface" has been implemented. However it goes beyond the purely empirical
feedback of prototyping with its parallel creation and evolution of design rationale for the tasks and
supporting software.
An important characteristic of our approach is that we prototype tasks. We are seeking to support a
process in which designers experiment early and often with software abstractions, but always in the context
of specific task requirements. So, for example, when generating an object model for the conference paper
scenario (see Figure 1), we worked directly from a usage description and analysis reflecting hypotheses
about the user's concept of a reference (e.g., references contain components such as authors and
title, and reference-entry consists of specifying these parts). This motivated and rationalized a software
design in which these components were easily identifiable and manipulable. This is a common sort of
dependency between user tasks and the software supporting them, where some aspect of the user's task
structure must be respected or reified in the software model.
From the perspective of object-oriented software engineering, our approach can be seen as an extension of
an emerging family of scenario-based analysis and design methods [6, 10, 15, 17]. These methods argue
that analysis of task scenarios is a useful technique for developing a problem domain model, a fundamental
task in object-oriented design. Like these researchers, we have argued that scenarios are the right starting
point for constructing a model of cooperating problem objects [13]. However, these scenario-based
approaches to OOD have focussed only on the goal of developing good software models. Our work extends
this goal to include parallel development of useful and usable tasks [3, 4].
Most development projects will uncover tradeoffs between usability and implementation concerns, and the
discovery and resolution of these tradeoffs is an important aspect of task prototyping. The formatting
scenarios provide an example from the bibliography project. One of our first descriptions of a formatting
scenario described an author citing references in a familiar style, with the added ability to use nicknames.
When implementation began, however, a number of issues arose dealing with how the document was to be
parsed (e.g., recognizing a variety of citation forms, distinguishing between citations and other
parenthesized material, recognizing and responding appropriately to prior mentions of a reference author).
These issues were then considered, but in the context of the affected scenarios, so that consequences for
usability and for implementation could be considered jointly. The usability and software claims developed
at this point documented these concerns, marking the issue as one to be carefully tracked.
Most developers are familiar with the constraints that user requirements place on software and vice versa.
A less familiar -- but perhaps even more important -- form of interaction between tasks and software occurs
when reasoning about a software model suggests new opportunities for users' tasks. Users
conceptualize their tasks in certain ways and their understanding of task requirements typically reflects this
conceptualization. However, computerizing a task can significantly change the way it is carried out,
enabling or suggesting activities that had been difficult or even impossible to achieve [2]. If designers hope
to generate innovative solutions to users' needs, they must recognize, exploit and refine such opportunities
early and continuingly in application development.
Application of the object-oriented pardigm is one vehicle for discovering possible extensions to existing
tasks. In OOD, problems are decomposed into computational objects and their responsibilities; when a
problem entity is conceptualized as an "active" agent, it is often given responsibilities normally carried out
by humans or other agents [12]. Thus our object-oriented analysis of the bibliography suggested that the
various reference types should be "responsible" for their own formatting rules: a conference paper should
contain knowledge about how to format itself in IEEE style, in ACM style and so on. This is in contrast to
the non-computerized version of the task, where formatting rules are stored in the author's head, or in a
reference manual of some sort. This object-oriented view of the formatting task tied formatting knowledge
intimately to the object being formatted. It suggested a task model in which doing the formatting was
integrated with specifying the rules for the formatting; a user should have access to (and thus be able to
experiment with) an object's format at any time, rather than being forced to leave a particular formatting job
and move to a distinct formatting "rules" task.
An example of how we documented such task extensions can be seen in our reasoning about conference
proceedings. Our initial model of a conference paper did not include a separate component for the
proceedings containing the paper; authors do not normally cite an entire proceedings or journal issue, so
items such as these did not appear in our task analysis. But as we developed the object models for the
various conference paper scenarios, we recognized that an individual conference paper should not be
responsible for information about its containing volume. This pointed to the need for separate volume
objects, which in turn suggested a task enhancement: creation or modification of a volume reference
through work on any of the papers it contains. We immediately explored usability and software rationale
for such an enhancement in the context of the affected scenarios. Our conclusion was that while the user's
conceptual model would now be more complex (journal articles, book chapters and conference papers
would be "compound" references), the additional power provided by the new model warranted the change.
We recorded the usability and software claims that that we had developed in reasoning about these
tradeoffs; an explicit link between the two sets of claims was created to document this input from the
software model to the task design.
These examples argue for particular contributions of the object-oriented paradigm to scenario-based
development. Certainly there is nothing in principle that prevents the interleaved development of task
scenarios and a non-object-oriented software design. However, we believe that the integration of task and
software development will produce the greatest payoff in the design of object-oriented systems: the use-
oriented descriptions offer a rich and concrete context for the analysis of object responsiblities, while at the
same time this responsibility analysis can suggest new ways of envisioning elements of users' tasks [12].
Abstract
Keywords:
Prototyping, Design tools, Scenarios, Object-oriented programming, Software
engineering, design rationale
Introduction
Scenario-based development
Scenario Evolution
Completeness
Consistency
Task Prototyping
Object Responsibilities in a Task
