During the past five years, our research group worked with a group of public school teachers to define, develop, and assess network-based support for collaborative learning in middle school physical science and high school physics. From the outset, we committed to a participatory design approach. This design collaboration has now existed far longer than is typical of participatory design endeavors, particularly in North America. The nature of our interactions, and in particular the nature of the role played by the teachers has changed significantly through the course of the project. We suggest that there may be a long-term developmental unfolding of roles and relationships in participatory design.

Abstract. Scenarios have gained acceptance in both research and practice as a way of grounding softwareengineering projects in the users ’ work. However, the research on scenario-based design (SBD) includes very few studies of how scenarios are actually used by practising software engineers in real-world projects. Such studies are needed to evaluate current SBD approaches and advance our general understanding of what scenarios contribute to design. This longitudinal field study analyses the use of scenarios during the conceptual design of a large information system. The role of the scenarios is compared and contrasted with that of three other design artefacts: the requirements specification, the business model, and the user interface prototype. The distinguishing features of the scenarios were that they were task-based and descriptive. By being task-based the scenarios strung individual events and activities together in purposeful sequences and, thereby, provided an intermediate level of description that was both an instantiation of overall work objectives and a fairly persistent context for the gradual elaboration of subtasks. By being descriptive the scenarios preserved a real-world feel of the contents, flow, and dynamics of the users ’ work. The scenarios made the users ’ work recognisable to the software engineers as a complex but organised human activity. This way the scenarios attained a unifying role as mediator among both the design artefacts and the software engineers, whilst they were not used for communication with users. The scenarios were, however, discontinued before the completion of the conceptual design because their creation and management was dependent on a few software engineers who were also the driving forces of several other project activities. Finally, the software engineers valued the concreteness and coherence of the scenarios although it entailed a risk of missing some effective re-conceptions of the users’ work.

This article presents a cognitively oriented viewpoint on design. It focuses on cognitive, dynamic aspects of real design, i.e., the actual cognitive activity implemented by designers during their work on professional design projects. Rather than conceiving designing as problem solving—Simon’s symbolic information processing (SIP) ap-proach—or as a reflective practice or some other form of situated activity—the situativity (SIT) approach—we consider that, from a cognitive viewpoint, designing is most appropriately characterised as a construction of representations. After a critical discussion of the SIP and SIT approaches to design, we present our viewpoint. This presentation concerns the evolving nature of representations regarding levels of abstraction and degrees of precision, the function of external representations, and specific qualities of representation in collective design. Designing is described at three levels: the organisation of the activity, its strategies, and its design-representation construction activities (different ways to generate, transform, and evaluate representations). Even if we adopt a “generic design ” stance, we claim that design can take different forms depending on the nature of the artefact, and we propose some candidates for dimensions that allow a distinction to be made between these forms of design. We discuss the potential specificity of HCI design, and the lack

Personalization customizes information access. The PIPE (`Personalization is Partial Evaluation') modeling methodology represents interaction with an information space as a program. The program is then specialized to a user's known interests or information seeking activity by the technique of partial evaluation. In this paper, we elaborate PIPE by considering requirements analysis in the personalization lifecycle. We investigate the use of scenarios as a means of identifying and analyzing personalization requirements. As our first result, we show how designing a PIPE representation can be cast as a search within a space of PIPE models, organized along a partial order. This allows us to view the design of a personalization system, itself, as specialized interpretation of an information space. We then exploit the underlying equivalence of explanation-based generalization (EBG) and partial evaluation to realize high-level goals and needs identified in scenarios

Electronic voting support systems should not focus only on ballot casting and recording. Instead, a user-centered perspective should be adopted for the design of a system that supports information gathering, organizing and sharing, deliberation, decision making, and voting. Relevant social science literature on political decision making and voting is used to develop requirements. A design concept is presented that supports extended information browsing using combined filtering from ballot materials and voter profiles. The system supports information sharing and participation in electronic dialogues. Voters may interweave information browsing, annotation, contextualized discussion, and ballot markup over extended time periods.

This paper argues that a user's manual makes an excellent, if not the best, software requirements specification. It discusses several lessons learned from experiences writing user's manuals as requirements specifications. Keywords: ambiguity, requirements analysis, requirements elicitation, requirements validation, requirements, scenarios, specification, test cases; use cases, user's manual 1

Abstract not found

1.1 Intentions and Relevance of this Study....................... 1

adoption of the World Wide Web over the past decade by both content producers and information consumers has resulted in greater volumes of content on an ever-widening array of subjects to be available to larger numbers of users. Clearly we are past the stage at which the primary challenge is being able to put the information where the public can have access to it; now the challenges include making it possible for the user to find the information she wants, and contributing to the user’s ability to make sense of the information she finds. The search engine companies (Google being the most notable and successful) are working to improve the process of finding relevant information; the area that is the concern of this review has to do with what the user does with the information after it has been found. In particular, what are the processes involved with integrating information from a number of sources into some coherent piece of knowledge? What happens if the information from two different sources is contradictory? How does the user know when it is appropriate to make comparisons between information gathered from more than one source? And, at the crux of the matter, are there things we as information scientists can

This paper argues that a user#s manual makes an excellent software requirements specification. It describes several experiences, including one in industry, of writing user#s manuals as requirements specifications. Finally, it discusses several lessons learned from the experiences.