J. M. Carroll and M. B. Rosson. Getting Around the Task-Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems, Vol. 10(2):pages 181--212, April 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....is to identify a limited set of task scenarios which are representative of the intended artifact and then carry out the information mapping analysis on these. The problem is that no guaranteed method for generating an appropriate set of scenarios currently exists in HCI. One proposed heuristics [10] is too weak for this purpose and we are currently testing an alternative method [15] Let us just assume that the best current methods or heuristics are being applied in identifying representative tasks. The results of Step 1 would normally be (a) high level task domain information relevant to ....

Carroll, J. M., Kellogg, W. A. and Rosson, M. B. Getting Around the Task - Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems, 10, 2, 1992, 181-212.

.... Intl. 908 562 3966. 2 Comprehension Models and Design Reasoning One of the most significant uses of cognitive models of software comprehension for designing and re designing tools has been to facilitate usability testing and analysis. In these circumstances, designers will reason backwards [2] from existing (or partly designed) tools to cognitive models of how the user performs the tasks of interest. This type of backward reasoning has frequently been used to reveal potential difficulties that can be identified by the model. For example Soloway et al. 11] traced the causes of ....

....(as compared to a design space [7] which also describes an artifact space) Since our interest is in reasoning about performance, the points within the space are explanations of how performance is improved. Links from artifacts to these explanations can be used by a designer to build claims [2] as to why the artifacts achieve design goals. We shall describe the broad outline of the design reasoning space, including how we envision claim generation by designers. We will then touch on how design goals can be identified by examining the features of the cognitive models. 3.1 The Cognition ....

[Article contains additional citation context not shown here]

Carroll, J. M., and Rosson, M. B. Getting around the taskartifact cycle: How to make claims and design by scenario. ACM Transactions on Information Systems, 10(2), 1992, pp. 181--212.

.... possibility is that it is to a great extent accidental: good tools can be built without knowing, a priori, if or why they are good (this thesis is expanded upon in Chapter 7) That is, the psychological and supportive knowledge embodied in a tool may not have been known to its designer in advance [110]. Iterative testing weeds out features that incorrectly understand the psychology of the user it separates nuggets of gold from dirt [370] This means that even pure guesswork (or, somewhat more charitably, a lucky hunch [370] is occasionally rewarded [189] Furthermore the lucky hunches ....

....many of the tools of anthropologists, sociologists, and psychologists, however in a much more informal and a less rigorous or controlled manner. The distinction between an acknowledged science discipline and these sorts of craft disciplines can be, in some respects at least, surprisingly small [110]. The claim that cognitive support is not studied at all is therefore quite incorrect, but the characteristics of that study is of a craft like discipline, not a science like discipline. In summary, tools research in SE has historically managed to creep along as a craft discipline. Knowledge ....

[Article contains additional citation context not shown here]

Carroll, J. M., and Rosson, M. B. Getting around the task-artifact cycle: How to make claims and design by scenario. ACM Transactions on Information Systems, 10(2), 1992, pp. 181--212.

....positive results, interviews and observations revealed some major shortcomings with TopicShop and thus important lessons for us. Subsequent reflection led to a major system redesign. Like all artifacts, the TopicShop Explorer embodied claims about how users will conceive and carry out their tasks [7]. With its two separate windows for exploring site details and for organizing icons into groups, only one of which could be visible at a time, it embodied a claim that the tasks of evaluation and organization must be carried out separately. Further, it assumed a single data set (the collection of ....

Carroll, J.M. and Rosson, M.B. Getting Around the Task-Artifact Cycle: How to Make Claims and Design By Scenario. ACM Transactions on Information Systems 10(2), 181-212, 1992.

....or misuse of Boolean operators. We think that Web IRS should help correct such mistakes for users. Another study could look into the session characterization problem in more detail. Chapter 7 Network Tra#c is not the Sum of its Components 7. 1 Introduction In this chapter we define scenarios [CR92, JRC97] that can be used to test the WWW and distributed information systems scalability with emphasis on the educational systems. We do that by first defining a scenario, second we define the objective of developing scenarios, and finally we discuss several scenarios that will show how to ....

J. M. Carroll and M. B. Rosson. Getting around the task-artifact cycle: How to make claims and design by scenario. TOIS, 10(2):181--212, 1992.

....information for the developers would be lost. 5 Related Work It is infeasible here to give a comprehensive overview of all the work proposing uses of scenarios. A selection of important work in Human Computer Interaction and the field of O O related to requirements capture can be found in [2, 3, 9]. However, none of these approaches deals explicitly with the purpose(s) of the interactions described in a scenario. Although Carroll et al. 2] mention that the sequence of actions in a scenario is aimed at accomplishing some task goal (which can be the answer to a why question) this key ....

....described in a scenario. Although Carroll et al. 2] mention that the sequence of actions in a scenario is aimed at accomplishing some task goal (which can be the answer to a why question) this key information appears not yet to be adequately represented and used. While the use of claims in [3] deals with causes of a design on the human user, our approach makes explicit the causality of the system to be built on the overall system. We also cannot give here a comprehensive overview of all the proposed approaches to requirements engineering. Especially for the traditional ones, the ....

J. M. Carroll and M. B. Rosson. Getting around the task-artifact cycle: how to make claims and design by scenario. ACM Transactions on Information Systems, 10(2):181-- 212, April 1992. 19

....technique has been applied in different research areas and a variety of definitions, ways of use and ways of interaction with the user are given. In particular, scenarios have been used in the area of Software Engineering [13] 14] Business process reengineering [15] User Interface Design [16], Documentation and demonstration of software and many more. In addition the term script used in Artificial Intelligence [17] and in Object behaviour Analysis [18] is very similar to the various definitions of scenarios . Page 5 The idea of using scenarios as a means of validating a ....

Carroll J.M. and Rosson M.B., Getting around the Task-Artifact Cycle: How to make Claims and Design by Scenario, IBM Research Report, Human Computer Interaction, RC 17908 (75365) 7/1/91

....of enterprise goals. Until now, scenarios have been used in goal oriented approaches mainly for goal identification ( Potts [4] Dardenne, Lamsweerde [7] Rubin and Goldberg [29] Thebaut, Interrante [30] Holbrook [31] validation ( Potts, Takahashi [32] Carroll and Rosson [33] , Anderson and Durney [34] and prototyping purposes ( Rosson and Carroll [35] Hsia, Samuel [36] Hooper and Hsia [37] The novelty of our work is in the use of scenarios as the means of goal operationalisation. The framework is still under refinement and a prototype implementation is ....

Carroll, J.M. and M.B. Rosson, Getting Around the Task-Artifact cycle: How to Make Claims and Design by Scenarios. ACM Transactions on Information Systems, 1992. 10(2, April): p. 181-212

....in the system and environment prior to its happening. Scenarios are already used for different purposes including describing the properties of an application domain [BFJZ93] uncovering and understanding requirements [DvLF93, PTA94] Human Computer Interaction analysis [MW90, Kyn91, Nar92, CR92] specification or prototype generation [HY88, KN91, AD93] Scenarios are also used within object oriented design methods such as OMT [RBP 91] OBA [RG92] and OOSE [JCJ O93] In this paper, we first describe in Section 2, the whole activities of our approach for requirement engineering with ....

J M. Carroll and M B. Rosson. Getting Around the Task-Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems, 10(2):181--212, april 1992.

....Developers use scenarios to validate their understanding of customers work practices, organizational goals and system requirements. Scenarios are receiving widespread attention in various intellectual communities such as objectoriented development [8, 13, 16, 24, 25] human computer interaction [11], and strategic planning [10] In the requirements engineering community, scenarios have proven effective for discovering [4, 18, 22, 23] elaborating [16, 18] refining [27] and validating [1, 7, 15] requirements. A recent study of scenario usage in industrial projects, 29] highlights the ....

J. Carroll and M. Rosson. Getting Around the Task-Artifact Cycle: How to Make Claims and Design by Scenario. ACM Trans. on Information Systems, 10(2):181--212, Apr. 1992.

....Likewise, validating the implemented system against client intent involves evaluating the system s behavior in specific situations. Scenarios have attracted interest lately in the human computer interaction (HCI) community, as a way of describing sequences of interactions between systems and users [5, 16]. Campbell notes [4] that they can be used to illustrate how a user might accomplish particular tasks with the system, to evaluate system usability, to guide interface design, and to test theories of human computer interaction. There has been limited discussion in the software engineering ....

J.M. Carroll and M.B. Rosson. Getting Around the Task-Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems, 10(2):181--212, April 1992.

....serve for the automatic generation of formal specification. Scenarios have already been used for different purposes including describing properties of an application domain [BFJZ93] uncovering and understanding requirements [DvLF93, PTA94] Human Computer Interaction analysis [MW90, Kyn91, Nar92, CR92] specification or prototype generation [HY88, KN91, AD93] and Object Oriented conception [RG92, JCJ O93] Our work differs to approach such as WATSON [KN91] by a use of formal scenarios in order to reduce domain knowledge needed. We also differs from other approaches by the inclusion of ....

J M. Carroll and M B. Rosson. Getting Around the Task-Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems, 10(2):181--212, april 1992.

....of the group discussions touched upon tasks that web site users may engage in, and artefacts that are constructed to support them. What was especially interesting to observe was how the groups put tasks and artefacts together, to synthesise new tasks and new artefacts a task artefact cycle (Carroll and Rosson 1996). Group 3 spent a lot of time evaluating web sites and browsers, using thought experiments to probe the usability of designs suggested in the case study document and their own, novel designs. They were systematic in their approach to the evaluation, deciding on a user model and a set of ....

Carroll, J. M. and M. B. Rosson (1996). Getting around the task artifact cycle: How to make claims and design by scenario. In M. Rudisill, C. Lewis, P. G. Polson, and T. D. McKay (Eds.), Human computer interface design: success stories, emerging methods and real-world context. San Francisco: Morgan Kaufmann.

....technique has been applied in different research areas and a variety of definitions, ways of use and ways of interaction with the user are given. In particular, scenarios have been used in the area of Software Engineering [22] 23] Business process reengineering [24] User Interface Design [25], Documentation and demonstration of software and many more. In addition, the term script used in Artificial Intelligence [26] and in Object behaviour Analysis [27] is very similar to the various definitions of scenarios . In requirements elicitation scenarios are a behavioural specification. A ....

Carroll J.M. and Rosson M.B., Getting around the Task-Artifact Cycle: How to make Claims and Design by Scenario, IBM Research Report, Human Computer Interaction, RC 17908 (75365) 7/1/91

....collected. In SBD, field data such as these are summarized to characterize the users and their tasks. Claims analysis is used to identify tradeo#s that implicit in the current situation features that have both positive and negative consequences for the web site designers or the site s users [19]. The implicit assumption is that these are the features that will provide the most leverage in a new design. The tradeo#s provide the motivation for scenarios that convey the concerns and opportunities of current practice. Thus it is the identification and discussion of tradeo#s that is ....

J.M. Carroll and M.B. Rosson. Getting Around the Task-Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems, Vol. 10(2):pp. 181--212, 1992.

....and rapid progress in interface technologies [9] In this section, we view scenarios as tools to enable change in both the HCI and Information Systems communities, with a varying degree of interpretation and use. In particular, we refer to a framework used for a long time in system evolution [45, 12] and made explicit in [33] as in figure 1a. According to this framework, change management involves four basic tasks: a) re constructing the concepts and rationale behind the current system, b) defining the desired change at the conceptual level, c) implementing the changed concepts to reach ....

Carroll, J.M. & Rosson, M.B. 1992. Getting around the task-artifact cycle: How to make claims and design by scenario. ACM Transactions on Information Systems, 10, 181-212.

No context found.

J. M. Carroll and M. B. Rosson. Getting Around the Task-Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems, Vol. 10(2):pages 181--212, April 1992.

No context found.

Carroll, J. M., Kellogg, W. A. and Rosson, M. B. Getting Around the Task - Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems, 10, 2, 1992, 181-212.

No context found.

Carroll J. M. and Rosson M. B. (1992). Getting Around the Task-Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems Vol. 10 No. 2 pp181-212

No context found.

CARROLL,J.M.&ROSSON, M. B. (1992). Getting around the task-artifact cycle: how to make claims and design by scenario. ACM ransactions of Information Systems, 10, 181---212.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC