FURTHER USES OF "SCENARIO" David Reisner Robert Campbell observes a variety of different usages of the term "scenario". He identifies four types of usage and coins terms to disambiguate usage and intent: demonstration examples (description), evaluation tasks (evaluation), user tasks for design (design), and test cases (theory testing). Webster's 7th New Collegiate Dictionary defines "scenario" as "I a: an outline or synopsis of a play; esp'. a plot outline used by actors of the commedia deU'arte, b: the book of an opera, 2a: SCREENPLAY, b: SHOOTING SCRIPT". This classical, common English usage focuses on scenario as a list or guideline of events which orders a set of actions. All of Campbell's usages, save perhaps "test cases", fit this pattern. I prefer to focus not on script or stage direction, but on the elements of plot and intent, which are not always made explicit. In Reisner (1986a), I presented two usages of the term "scenario": as a technique for describing how to accomplish a task or activity using a given system, similar to Campbell's "demonstration examples", and as a technique in system design, similar to Campbell's "user tasks for design". As "demonstration examples", the intent is to supply the user with an appropriate model for system usage how to use the system naturally to accomplish a task. For Unix, such a "scenario" might develop the. ideas of shell scripts and filters, through examples of common high-level tasks. As "user tasks for design", I used "scenarios" to describe a user task domain, attempting to identify approaches the user would naturally adopt, and then developing a system or set of tools which would be consonant the user's desires and expectations. For example, one might describe a user's thought process in the course of developing a program, and then describe a style of programming environment which would support that process. Reisner (1986b) illustrates this in a rudimentary fashion. Reisner (1986c) describes a somewhat more successful "design by scenario", though the scenario is not explicitly stated. Both usages focus almost completely on the user's internal model of the system. Specific command usage and behavior only shows up incidentally. The "scenarios" are not substitutes for traditional tutorials and usage or design documentation. Rather, they provide the higher-level context in which those other documents become useful and meaningful. The utility of this type of "demonstration example" scenario could be tested fairly easily by the use of different documentation sets in introducing novice and experienced users to a new system, as outlined in Reisner (1986a). With this emphasis, "user paradigms" might be a better term than "demonstration examples" (if somewhat overused). "User tasks for design" is somewhat cumbersome, and does seems to focus on very specific actions rather than on process and motivation; I would be tempted to retain "scenario", perhaps paired with "problem", "domain", or "design". "Test cases" does not emphasize the hypothesis and theory testing nature of the usage - alternatives? "Evaluation tasks" seems direct and to the point. Scenarios, in their various usages, clearly provide useful methods for thinking about and describing systems, theories, and user models. A taxonomy may be useful in retaining focus and clarifying purpose of usage in different contexts.

/lp/association-for-computing-machinery/further-uses-of-scenario-TPji8RPloz