The role of critiquing in cooperative problem solving

Abstract

Cooperative problem-solving systems help users design solutions themselves as opposed to having solutions designed for them. Critiquing-presenting a reasoned opinion about a user's product or action-is a major activity of a cooperative problem-solving system. Critics make the constructed artifact "talk back" to the user. Conditions under which critics are more appropriate than autonomous expert systems are discussed. Critics should be embedded in integrated design environments along with other components, such as an argumentative hypertext system, a specification component, and a catalog. Critics support learning as a by-product of problem solving. The major subprocesses of critiquing are goal acquisition, product analysis, critiquing strategies, adaptation capability, explanation and argumentation, and advisory capability. The generality of the critiquing approach is demonstrated by discussing critiquing systems developed in our group and elsewhere. Limitations of many current critics include their inability to learn about specific user goals and their intervention strategies.

Case-based reasoning systems: from automation to decision-aiding and stimulation

“…Stimulative CB-DSSs raise an additional set of issues. The suggestions/criticisms of stimulative CB-DSSs are similar in nature to educational critiquing systems [15] but imply a further adaptation in the design of CBR procedures. The knowledge stored within cases should include models of the DM in addition to the decision process and case retrieval algorithms need to account for a different learning-oriented definition of relevance.…”

Supporting Indirect Collaborative Design With Integrated Knowledge-Based Design Environments

“…Our design environments include knowledge-based critics similar to the rules found in an expert system. In our conceptual framework, critiquing is used to empower designers (e.g., by informing them of interactions with the group knowledge base) and not to replace them (Fischer, Lemke, Mastaglio, & Morch, 1991).…”

“…The issue base has the following functions: (a) supporting reflection in action by explaining breakdowns (identified by critic messages; Fischer, Lemke, Mastaglio, & Morch, 1991) and suggesting ways to repair them; (b) allowing designers to record design rationale and to react to rationale supplied by others (Fischer, Lemke, McCall, & Morch, 1991); and (c) making designers aware of issues, possible answers, and argumentation as they browse the issue base. For the development of the seed of our issue base, we videotaped a number of design sessions.…”

Extending design environments to software architecture design

“…Design environments such as Framer [19], Janus [6,8,9], and Hydra [10] support reflection-in-action. Figure 1 shows facilities of the Janus family of design environments.…”

“…The design environment facilities explored by Fischer and others [6][7][8][9][10] have provided an essential basis for our work. In building Argo, however, we have found it necessary to extend the basic facilities provided by these earlier systems, and have devised an architecture that will support further extensions and applications to new domains.…”