~ University of Colorado at Boulder

Department of Computer Science

ECOT 7-7 Engineering CenterCampus Box 430Boulder, Colorado 80309-0430(303) 492-7514, FAX: (303) 492-2844

Critics: An Emerging Approachto Knowledge-Based Human Computer Interaction

Gerhard Fischer, Andreas C. Lemke and Thomas MastaglioDepartment of Computer Science and Institute for Cognitive Science

University of Colorado, Boulder, USA

Anders I. MorchNYNEX Artificial Intelligence Laboratory

White Plains, NY, USA

To appear in: International Journal ofMan-Machine Studies (IJMMS)

Abstract: We describe the critiquing approach to building knowledge-based interactive systems. Critiquingsupports computer users in their problem solving and learning activities. The challenges for the next genera­tion of knowledge-based systems provide a context for the development of this paradigm. We discuss criticsfrom the perspective of overcoming the problems of high-functionality computer systems, of providing a newclass of systems to support learning, of extending applications-oriented construction kits to design environ­ments, and of providing an alternative to traditional autonomous expert systems. One of the critiquing systemswe have built - JANUS, a critic for architectural design - is used as an example for presenting the key aspectsof the critiquing process. V.Ie then survey additional critiquing systems developed in our and other reseaichgroups. The paper concludes with a discussion of experiences and extensions to the paradigm.

Acknowledgements. Many people have contributed to the development of our notion of the critiquing paradigm.The authors would like to thank especially: the members of the Janus Design Project (Ray McCall, KumiyoNakakoji, and Jonathan Ostwald), the members of the LISP-CRITIC project (Heinz-Dieter Boecker, Chris Morel,Brent Reeves, and John Rieman), all the people who have participated in discussions about the general frameworkfor critiquing (Thomas Schwab, Helga Nieper-Lemke, Curt Stevens, Tom DiPersio, and Hal Eden), and the HCCresearch group as a whole. This research was partially supported by grant No. IRI-8722792 from the NationalScience Foundation, grant No. MDA903-86-C0143 from the Army Research Institute, and grants from the Intel­ligent Interfaces Group at NYNEX and from Software Research Associates (SRA), Tokyo.

Critics: An Emerging Approachto Knowledge-Based Human Computer Interaction

Gerhard Fischer, Andreas C. Lemke, and Thomas MastaglioDepartment of Computer Science and Institute for Cognitive Science

University of Colorado, Boulder, USA

Anders I. MorchNYNEX Artificial Intelligence Laboratory

White Plains, NY, USA

AbstractWe describe the critiquing approach to building

knowledge-based interactive systems. Critiquingsupports computer users in their problem solving andlearning activities. The challenges for the nextgeneration of knowledge-based systems provide a.context for the development of this paradigm. Wediscuss critics from the perspective of overcoming theproblems of high-functionality computer systems, ofproviding a new class of systems to support learning,of extending applications-oriented construction kits todesign environments, and of providing an alternativeto traditional autonomous expert systems. One of thecritiquing systems we have built - JANUS, a criticfor architectural design - is used as an example forpresenting the key aspects of the critiquing process.We then survey additional critiquing systemsdeveloped in our and other research groups. Thepaper concludes with a discussion of experiences andextensions to the paradigm.

Keywords: critics, critiquing, high functionalitycomputer systems, intelligent support systems, designenvironments, cooperative problem solving systems.

IntroductionA critic is a system that presents a reasoned opinion

about a product or action generated by a human. Thecritiquing approach is an effective way to make use ofcomputer knowledge bases to aid users in their work andto support learning. Our experience with this approachincludes several years of innovative system building ef­forts, the integration of cognitive and design theories, em­pirical observations, and the evaluation of prototypes.This paper combines our experience with the research ef­forts of others to articulate foundations and characteristicsfor the critiquing paradigm. We describe the rationale forcritiquing (Section 2) and illustrate the approach using oneof our systems (JANUS) as an example (Section 4).Section 5 gives a general characterization of the critiquingprocess. Other critics are surveyed in terms of the critiqu­ing framework, showing the applicability and usefulnessof critics in other domains (Section 6). We conclude witha discussion of future directions for research on thecritiquing paradigm.

Challenges for the Next Generation ofKnowledge-Based Systems

The next generation of knowledge-based systems willpresent the following challenges:• They will be high functionality systems, and their com­

plete mastery will exceed the cognitive capabilities ofmost individuals.

• They will need to support a broad spectrum of learningand working activities.

• They should be integrated design environments.• Rather than autonomous expert systems, they will often

be joint human-computer systems supporting coopera­tive problem solving.

We will discuss how critics can meet each of these chal­lenges.

High-Functionality Computer SystemsAs powerful computer hardware has become widely

available, so have software systems for general applica­tions with a large range of capabilities. Technical com­plexity and the associated human cognitive costs to masterthese systems have grown dramatically limiting the abilityof users to take full advantage of them. One illustration ofthis situation is the Symbolics LISP machine; it containsover 30,000 functions and 3300 flavors (or classes) ac­companied by 12 books with 4400 pages of writtendocumentation. Even a modern microcomputer wordprocessor has more than 400 pages of documentation andan amount of functionality that very few people master inits entirety.

For systems to be useful and applicable to a wide rangeof problems, they have to offer rich functionality. Moderncomputer systems are best understood not in their capacityto compute but to serve as knowledge stores. And becausethe amount of knowledge is extensive, these systems willnot be small and simple, but will be large and complex.

"Reality is not user friendly," i.e., typical problems arecomplex and cannot be easily solved using a small set ofgeneral building blocks and tools. Such minimal tools arenot always useful even though, in principle, anything canbe computed with them. These tools force the user toreinvent the wheel rather than supporting reuse andredesign of existing components.

Systems that offer a rich functionality are a mixed bless-

ing. In a very large knowledge spacet something related towhat we need is likely to exist but may be difficult to find.It is impossible and infeasible for anyone individual toknow such systems completely. Empirical studies(Draper, 1984) have shown that even very experiencedusers know only a subset of a large system. They en­counter the following problems: They do not know aboutthe existence of building blocks and tools; they do notknow how to access tools, or when to use them; they donot understand the results that tools producet and they can­not combinet adapt, and modify tools according to theirspecific needs. Our goal is to increase the usability of highfunctionality computer systemst not by "watering downtt

functionality or steering the user toward only a subset ofthe systems' capabilities, but by facilitating learning abouttaccess tOt and application of the knowledge these systemscontain. Critics contribute to these goals by providing theuser with selective information at the time it is needed.

Systems to Support LearningThe computational power of high functionality com­

puter systems can provide qualitatively new learning en­vironments. Learning technologies of the future should bemulti-facetedt supporting a spectrum extending from open­ended, user-centered environments such as LOGO (papert,1980) to guided, teacher-centered tutoring environments(Wengert 1987).

Tutoring is one way to support learning the basics of anew system. One can pre-design a sequence ofmicroworlds and lead a user through them (Anderson &Reiser, 1985). However, tutoring is of little help in sup­porting learning on demand when users are involved intheir "own doing. tt Tutoring is not task-driven, becausethe total set of tasks cannot be anticipated. To supportuser-centered learning activities, we must build computa­tional environments that match individual needs and learn­ing styles. Giving users control over their learning andworking requires that they become the initiators of actionsand set their own goals.

In open learning environments users have unlimitedcontrol (papertt 1980), but there are other problems. Theydo not support situations where users get stuck during aproblem solving activity or settle at a suboptimal plateauof problem solving behavior. To successfully cope withnew problems, users can benefit from a critic that pointsout shortcomings in their solutions and suggests ways toimprove them.

In contrast to passive help systems, critics do not requireusers to formulate a question. Critics allow users to retaincontrol; they interrupt only when users' products or ac­tions could be improved. By integrating working andlearningt critics offer unique opportunities: users under­stand the purposes or uses for the knowledge they arelearning; they learn by actively using knowledge ratherthan passively perceiving it, and they learn at least onecondition under which the knowledge can be applied. Astrength of critiquing is that learning occurs as a naturalbyproduct of the problem solving process.

Design Environments

To accomplish most things in this worldt selectivesearch, means-ends analysis, and other weak: methods arenot sufficient (Simon, 1986); one needs to employ strongproblem solving techniques with knowledge about the taskdomain. Designers-architects, composerst user interfacedesigners, database experts, knowledge engineers-are ex­perts in their problem domain and are not interested inlearning the "languages of the computert>; they simplywant to use the computer to solve their problems and ac­complish required tasks. To shape the computer into atruly usable as well as useful medium, we have to makelow-level primitives invisible. We must "teachtt the com­puter the 13.t'1guages of experts by endowing it wiL~ L~e

abstractions of application domains. This reduces thetransformation distance between the domain experCsdescription of the task and its representation as a computerprogram. Human problem-domain communication is ourterm for this idea (Fischer & Lemket 1988).

Design environments (Lemke, 1989; Fischert McCall, &Morcht 1989a) are tools that foster human problem­domain communication by providing a set of buildingblocks that model a problem domain. Design environ­ments also incorporate knowledge about which com­ponents fit together and how. These systems containcritics that recognize suboptimal design choices and in­efficient or useless structures.

Cooperative Problem Solving SystemsThe goal of developing joint human-computer cognitive

systems in which the computer is considered a cognitiveamplifier has challenged the more widely understood goalof artificial intelligence: The understanding and buildingof autonomous, intelligentt thinking machines. For us, amore important goal is to understand and build interactiveknowledge media (Stefik, 1986) or cooperative problemsolving systems (Fischer, 1990). The major difference be­tween classical expert systemst such as MYCIN and R 1tand cooperative problem solving systems is in the respec­tive roles of human and computer.

Traditional expert systems ask the user for input, makeall decisions, and then return an answer. In a cooperativeproblem solving systemt the user is an active agent andparticipates together with the system in the problem solv­ing and decision making process. The precise roles playedby the two parties may be chosen depending on their dif­ferent strengths with respect to knowledge of goals andtask domain. Critics are an important component ofcooperative problem solving systems, especially whenthey are embedded in integrated design environments.These critics detect inferior designst provide explanationsand argumentation for their "opiniontt and suggest alter­native solutions.

Cooperative problem solving refers in our work to thecooperation between a human and a computer. It sharessome research issues with two related but differentresearch areas: Computer Supported Cooperative Work

User Model

DomainKnowledge

J

Critique

ProposedSolution

"--.('

Goals

DomainExpertise

Figure 1: The Critiquing Approach

A critiquing system has two agents, a computer and a user, working in cooperation. Both agents contribute what they knowabout the domain to solving some problem. The human's primary role is to generate and modify solutions, while thecomputer's role is to analyze those solutions producing a critique for the human to apply in the next iteration of this process.

(esew) (Greif, 1988), which describes the cooperationbetween humans mediated by computer, and DistributedArtificial Intelligence (Bond & Grasser, 1988), whichrefers to cooperation between computer systems.

Traditional expert systems are inadequate in situationswhere it is difficult to capture all necessary domainknowledge. Leaving the human out of the decisionprocess, autonomous expert systems require a comprehen­sive knowledge base covering all aspects of the tasks to beperformed; all "intelligent" decisions are made by thecomputer. Some domains, such as user interface design,are not sufficiently understood, and creating a complete setof principles that adequately captures the domainknowledge is not possible. Other domains are so vast thattremendous effort is required to acquire all relevantknowledge. Critics are well suited to these situations be­cause they need not be complete domain experts.

The traditional expert system approach is also in­appropriate when the problem is ill-defined, that is, theproblem cannot be precisely specified before a solution isattempted. In contrast, critics are able to function withonly a partial task understanding.

rects a mistake in a word processor document or a se­quence of operating system commands.1 An agent, humanor machine, that is capable of critiquing in this sense isclassified as a critic. Critics often consist of a set of rulesor specialists for individual aspects of a product; we some­times refer to such an individual rule or specialist as acritic, not only to the complete critiquing system as awhole.

Critics do not necessarily solve problems for users. Thecore task of critics is the recognition and communicationof deficiencies in a product to the user. Critics point outerrors and suboptimal conditions that might otherwiseremain undetected. Most critics make suggestions on howto improve the product. With this information users canfix the problems or seek additional advice or explanations.

Advisors (Carroll & McKendree, 1987) perform a func­tion similar to critics except that they are the primarysource for the solution. Users describe a problem, andthey obtain a proposed solution from the advisor. In con­trast to critics, advisors do not require users to present apartial or proposed solution to the problem.

Critiquing systems are particularly well suited fordesign tasks and for complex problem domains. In most

The Critiquing ApproachCritiquing is a way to present a reasoned opinion about

a product or action (see Figure 1). The product may be acomputer program, a kitchen design, a medical treatmentplan; an action may be a sequence of keystrokes that cor-

lIn the remainder of the paper the term product is often used ina generic sense encompassing both product in a narrow sense andactions.

;; Stove should be away from a door(define-crack-rule stove-door-rule stove

"is not away from a door""is away from a door":argumentation-topic "answer (stove, door)":apply-to (all door):applicability

(has-design-unit 'door):condition

(not (away-from du-l du-2 threshold)))

; defined on design unit STOVE; critic message; praiser message; access to JANUS-VIEWPOINTS; test all doors (if any); test only if there is; a door in the work area

; du-l is stove, du-2 is door

Figure 4: Definition of the stove-door critic rule

cases design tasks are ill-structured problems for which nooptimal solution exists. Complex problem domains re­quire a team of cooperating specialists rather than a singleexpert. Not all problems fit this description; for example,there are problems in engineering design and operationsresearch, where one can precisely specify problems andgenerate optimal solutions. Those types of problems yieldto more algorithmic solutions and are not good candidatesfor the critiquing approach.

The term "critic" has been used to describe severalclosely related, yet different ideas. It was used first inplanning systems to describe internal demons that checkfor consistency during plan generation. For example,critics in the HACKER system (Sussman. 1975) discovererrors in blocks world programs. When a critic discoversa problem. it notifies the planner, which edits the programas directed by the critic. The NOAH system (Sacerdoti.1975) contains critics that recognize planning problemsand modify general plans into more specific ones that con­sider the interactions of multiple subgoals. Critics in plan­ners interact with the internal components of the planningsystem; critics in the sense of this paper interact withhuman users.

JANUS: An ExampleTo illustrate the critiquing approach and to provide an

example for the subsequent theoretical discussion ofcritiquing, we present in this section the JANUS design en­vironment. JANUS is based on the critiquing approach andallows a designer to construct residential kitchen floor planlayouts and to learn general principles underlying suchconstructions (Fischer, McCall & Morch. 1989a; Fischer,McCall & Morch. 1989b). JANUS is an integrated designenvironment addressing the challenges of human problem­domain communication and testing the feasibility of ap­plying relevant information from large information storesto a designer's task.

JANUS contains two integrated subsystems:JANUS-CRACK and JANUS-VIEWPOINTs. JANUS-CRACK isa knowledge-based design environment supporting theconstruction of kitchens using domain-oriented buildingblocks called design units (Figure 2). JANUS-VIEWPOINTSis an issue-based hypertext system containing general prin-

ciples of kitchen design (Figure 3). The integration ofJANUS-CRACK and JANUS-VIEWPOINTS allows argumen­tation to resolve problematic (breakdown) situations thatoccur when critics detect design rule violations.

Knowledge Representation in JANUS

The critics in JANUS-CRACK know how to distinguish"good" designs from "bad" designs and can explain thatknowledge. This knowledge includes design principlesfrom Jones & Kapple (1984). These principles fall intothree categories: building codes. such as ({The windowarea shall be at least 10% of the floor area." , safety stan­dards. such as({The stove should be at least 12 inchesaway from a door.". and functional preferences, such as({The work triangle should be less than 23 feet." Func­tional preferences are soft rules and may vary from desig­ner to designer. Building codes and safety standards areharder rules and should be violated only in exceptionalcases.

The critics are implemented as condition-action rules,which are tested whenever the design is changed. Thechanges that trigger a critic are operations that modify theconstruction situation in the work area: move. rotate. andscale. Each type of design unit has a set of critic ruleswhose condition parts are relationships between designunits that capture the design principles discussed above.Protocol studies have shown that they are important prin­ciples that professionals use during the design process(Fischer & Morch, 1988). The stove design unit. for ex­ample. has critic rules with the following condition parts:(away-from stove door). (away-from stove window). (nearstove sink), (near stove refrigerator).(not-immediately-next-to stove refrigerator). The code forone of the stove critic rules is shown in Figure 4.

JANUS as a Design/Learning ToolJANUS supports two design methodologies: design by

composition (using the Palette) and design by modifica­tion (using the Catalog). In addition. examples in thecatalog can be used to support learning. The user can copyboth good and bad examples into the work area. Onelearning example is shown in Figure 5. The system cancritique such designs to show how they can be improved,

Janus-CRACK Worl< Area

Palette Context: Appliances

walls

doors

\JDwindows

[Sat 17 Feb 11:09:51] Keyboard

Catalog

Design State~ vertical-wall-1!! vertical-wall-2!! horizontal-wall-2

right-hinged-door-1window-1double-bowl-sink-1single-door-refrigera tor-1base-cabinet-1base-cabinet-2right-hinged-door-2corner-cabinet-lbase-cabinet-3

.. four-element-stove-1dishwasher-1

New Class New Rule New Relation

.. HEWSIGI:/sigi/ai.tfischer/! ibl'hardcopiesl'janusl'shoY-exal'l" 13

Praise All

User InputCL USER:

Learning-Example-S

sinks

[]J][Jstoves

I: :11.-.11: ~11·icr~"'1

n'nI!IID

Figure 2: JANUS-CRACK: the STOVE-CRITIC

JANUs-CRACK is the construction part of JANUS. Building blocks (design units) are selected from the Palette and moved todesired locations inside the Work Area. Designers can reuse and redesign complete floor plans from the Catalog. TheMessages pane displays critic messages automatically after each design change that triggers a critic. Clicking with the mouseon a message activates JANUS-VIEWPOINrS and displays the argumentation related to that message (Figure 3).

thus allowing users to learn from negative examples. Tolearn about good features of prestored designs, designerscan run the Praise All command, thus getting positivefeedback as well. V sers can add their own designs to thecatalog for future reuse or as additional learning examples.

V sers can modify and extend the JANUS-CRACK designenvironment by modifying or adding design units, criticrules, relationships (Fischer & Girgensohn, 1990). Theability to modify critic rules is important if a designerdisagrees with the critique given. Standard building codes(hard rules) cannot be changed, but functional preferences(soft rules) vary from designer to designer and thus canand should be adapted. In this way, users have thecapability to express their preferences. For example, ifusers disagree with the design principle that the stoveshould be away from a door, they can edit the stove door

rule by replacing the away-from relation between STOVE

and DOOR with another relation (selected from a menu).After this modification, they will not be critiqued when astove is not away from a door.

We have found JANUS to be a useful environment fordesign students. It teaches them about design principles.JANUS is also an efficient tool for skilled designers as itenhances their cognitive abilities for storing and remem­bering principles of good design such as the requiredbuilding codes.

A User Scenario with JANUS

In the following scenario, the designer has selected anL-shaped kitchen from the catalog for reuse. The goal isto modify this kitchen into a V-shaped kitchen by rear-

II! ! Argument (Dining Room): i If the door leads into a dining room, it will be easy to bring hot:I food from the stove into the dining area!

I j "' " " ,..1 ~

9

IIIIi Ii!

IIiI; !

II! ~

i i! !

IIif

Janus-ViewPoints

Answer (Stove. Door)

The stove should be away from a door.

~~rdist > 12 inches

Figure 5: stove-door

Argument (Fire Hazard)By placing the stove too close to a door It will be a fire andburn hazard to unsuspected passers by (such as small children)!

the stove ;s away from a door

Visited NodesAnswer (Refrigerator, ~indow) SectionDescription (~ork Triangle) SectionAnswer (Refrigerator, Stove) SectionAnswer (Stove, Sink) Section

• Answer (Stove, Door) Section

Viewer: Default Viewer

Commandsq ....! \Show ExaMp1e: "Answer (Stove, Door) IIld Show Exa.n.ple Rnswer (Stove, lJoor)o .....Mouse-R: Menu.To see other commands, press Shift, Control. Meta-Shift. 01' Super.

Show OutlineSearch For TopicsShow Argumentation

Show Context

DoneShow Example

Show Counter ExampleShow Construction

[Sat 17 Feb 11:09:04] Keyboard CL USER: User Input

Figure 3: JANUS-VIEWPOINTs: Rationale for the stove-door rule

The JANUS argumentation component is a hypertext system implemented using the SYMBOUCS DOCUMENf EXAMINER. Clickingwith the mouse on a critique in the JANUS construction mode (Figure 2) activates JANUS-VIEWPOINfS. The Viewer pane showsthe arguments for and against the answer relating a stove and a door. The top right pane shows an example illustrating thisanswer. The Visited Nodes pane lists in sequential order the argumentation topics previously discussed. By clicking with themouse on one of these items, or on any bold or italicized item in the argumentation text itself, the user can navigate to relatedissues, answers, and arguments.

ranging some of the appliances and cabinets. Figure 2shows the construction situation just after the stove(FOUR-ELEMENT-STOVE-l) was moved to the lower rightcorner of the kitchen floor plan.

Moving the stove triggers the stove critic, which teststhe stove's location relative to the doors, sink, andrefrigerator currently in the work area. Critic messagesdisplayed in the messages pane tell the designer that thestove is not proper!y located relative to the door and thesink, and that the WORK TRIANGLE is greater than 23 feet.This identifies a problematic situation, and prompts thedesigner to reflect on it. The designer has broken akitchen safety rule: The stove should be at least 12 inchesaway from a door.

The user may not have known the safety rule or may notunderstand the rationale for the rule, in which case anexplanation is desirable. Instead of providing the designerwith prestored text reflecting one expert's opinion, it ispreferable to acquaint the designer with multiple perspec­tives. This is supported by JANUS-VIEWPOINTS, which isactivated by clicking with the mouse on the critique in themessages pane. The designer enters JANUS-VIEWPOINTS

automatically in the context relevant to the critique(Figure 3). This argumentative context shows an answerto the issue the designer is implicitly raising: ({Whatshould be the location of the stove?" The answer stateshow the stove should be positioned relative to a door andlists arguments for and against this answer. This argumen-

...................................................

...................................................

D\ D

Dr--

DW • • DD• •lUI

Figure 5: JANUS-CRACK: A learning example from the Catalog

The critics in JANUS detect the following suboptimal features of the kitchen shown in this figure: The width of the door is lessthan 36 inches, the dishwasher is not next to a sink, the stove is next to a refrigerator, the refrigerator is next to a sink, and thesink is not in front of a window.

tative context also shows an example of how this designrule was successfully applied in another design (shown inthe upper right comer of Figure 3). The example is takenfrom the catalog of prestored designs in JANUS-CRACK.

All bold and italicized words in the Viewer pane (thelargest pane in JANUS-VIEWPOINTS) and all topics in theBookmarks pane allow further exploration with a mouseclick. Hypertext access and navigation is made possibleusing this feature inherited from the SYMBOUCSDOCUMENT EXAMINER. After finishing the search for re­lated infonnation in JANUS-VIEWPOINTS, the designerresumes construction in JANUS-CRACK by selecting theDone command.

The Process of CritiquingFigure 6 illustrates the component processes of critiqu­

ing: goal acquisition, product analysis, critiquing strategy,explanation and advice giving. Not all of these processesare present in every critiquing system. This sectiondescribes these subprocesses and illustrates them with ex­amples. JANUS does not illustrate all of the issues, and wewill refer occasionally to systems that are described inSection 6.

Goal AcquisitionCritiquing a product is enhanced if the system has an

understanding of the intended purpose of the product(problem knowledge). Problem knowledge can beseparated into domain knowledge and goal knowledge.Domain knowledge without any understanding of the par­ticular goals of the user restricts a critic to reasoning aboutcharacteristics that pertain to all products in the domain.For example, domain knowledge allows JANUS to point

out that stoves should not be placed close to doors, be­cause this arrangement constitutes a fire hazard. For amore extensive evaluation of a product, some understand­ing of the user's specific goals and situation is necessary.JANUS, like most critics, does not have that understanding.The user's goal is assumed to be to design a functionalresidential kitchen; the critic does not take into accountany individual requirements such as size of the kitchen ornumber of people in the family.

Critics that work with specific goal knowledge can ac­quire it by asking the user (external goal specification) orby analyzing the product the user has generated so far(goal recognition). A kitchen with a table and chairs lo­cated in the center of the kitchen suggests that the userintends to eat meals in the kitchen. The table and chairsallow a kitchen critic to recognize the goal of providing aneating area. Goal recognition is only possible if the cur­rent version of the artifact approximates a solution to thegoal to be recognized. If the product fails to come close tothe user's goal, the critic cannot infer that goal or mightinfer a goal different from the user's goal. Goal recog­nition is related to task-oriented parsing (Hoppe,1988) and plan recognition, a research area in artificialintelligence (Schmidt, Sridharan & Goodson, 1978; Lon­don & Clancey, 1982; Carver, Lesser & McCue, 1984).Tutorial systems define a goal structure for the user.Critics, however, allow users to set their own goals and donot restrict the space of possible goals. This complicatesthe problem of goal recognition. A critic that implementsgoal recognition is ACTIVIST (Section 6.3).

A critic may also have access to an external specifica­tion of the problem to be solved. For example, users maycommunicate to the system that they need a kitchen withan eating area for informal meals. This can be done with

UserModel

Legend

eFigure 6: The Critiquing Process

Users initiate the critiquing process by presenting a product to the critic. In order to evaluate the product, the critic needs toobtain the user's goals either by recognizing them or from explicit user input. The product analyzer evaluates the productagainst the goal specification. Some critics do this by generating their own solution and comparing it to the user's. Apresentation component uses the product analysis to formulate a critique, to give advice on how to make improvements, and toprovide explanations. Critiquing strategies and a user model control the kind of critique, its form and timing. Based on thecritique, the user generates a new version of the product, and the cycle repeats, integrating the new insight.

electronic questionnaires as well as with more sophis­ticated techniques such as natural language communica­tion.

Product AnalysisThere are two general approaches to crItiquing:

differential and analytical critiquing. In the former ap­proach, the system generates its own solution and com­pares it with the user's solution pointing out the dif­ferences. An advantage of differential critiquing is that alldifferences can be found. Some domains allow radically

different, but equally valid solutions, which is a potentialproblem if the system generates its solution without regardto the user's solution approach. If user and system solu­tions differ fundamentally, the critic can only say that thesystem solution achieves good results but cannot explainwhy the user's solution is less than optimal.

Different solution attempts fulfill the goals to differentdegrees or are associated with different undesirable ef­fects. In such situations, metrics are needed to measurethe quality of alternative solutions (Fischer, Lemke &Schwab, 1985). Based on the controversial nature of

design problems, alternative, conflicting metrics can bedefined and may have to be reconciled by negotiation andargumentation.

An analytical critic checks products with respect topredefined features and effects. Analytical critics identifysuboptimal features using pattern matching (e.g., Fischer,1987), and expectation-based parsers (e.g., Finin, 1983).In analytical approaches, critics do not need a completeunderstanding of the product. JANUS is an analytical criticthat uses a set of rules to identify undesirable spatialrelationships between kitchen design units. JANUS doesnot identify all possible problems within a kitchen design.Its rule base allows it to critique kitchens without knowingexact requirements and preferences of the kitchen user.

Critics for large designs must operate on intermediatestates and not only on complete products. A design rule inthe domain of kitchen design specifies a certain minimumwindow area. The critiquing component of JANUS must beable to deal with temporary violations to avoid botheringusers when they have not yet included all the windows intheir design.

Some critics receive a stream of information that is notyet separated into individual products or actions.ACTIVIST (Fischer, Lemke & Schwab, 1985) is a critic fora text editor, which critiques keystroke sequences and, ifpossible, proposes shorter alternatives. Systems such asACTIVIST face several problems: action sequences are hardto delineate; sequences of actions may constitute a usefulplan but may also be the beginning of a different, larger,not yet complete plan, and different plans may overlap orbe included within each other. For example, users maydelete a word at one place in a text, then correct a spellingmistake, and finally paste the word at a different place.This composite action sequence needs to be recognized asan interleaved execution of a correct-spelling plan and anexchange-words plan. A critic capable of task-orientedparsing must decide how long to wait for later parts of aplan and whether interspersed actions interfere with theinterrupted plan.

Critiquing StrategiesCritiquing strategies and an optional user model control

the presentation component of a critic. The critiquingstrategies determine what aspects of a design to critiqueand when and how to intervene in the working process ofthe user. Critiquing strategies differ depending on thepredominant use of the system, either to help users solvetheir problems or as a learning environment.

The user's perception of critics. Like recommen­dations from colleagues or co-workers, messages from acritic can be seen as helpful or hindering, as supportive ofor interfering with work or the accomplishment of goals.Critiquing strategies should consider intrusiveness andemotional impact on the user. Intrusiveness is the users'perception of how much the critiquing process is inter­fering with their work. Critics can either interfere toomuch or fail to provide sufficient help, depending on thefrequency of feedback, the complexity of the tasks, and the

sophistication of the user. Emotional impact relates tohow users feel about having a computer as an intelligentassistant. Critiquing from a computer might be moretolerable than critiquing from humans if it is handled as aprivate matter between the human and the computer.

What should be critiqued? Educational critics, whoseprime objective is to support learning, and performancecritics, whose primary objective is to help produce betterproducts, have different requirements for their critiquingstrategies. A performance critic should help users createhigh-quality products in the least amount of time using asfew resources as possible. Learning is not the primaryconcern of performance systems but can occur as a by­product of the interaction between user and critic. Educa­tional critics should maximize the information users retainto improve their future performance.

Most performance critics (e.g., FRAMER, JANUS,ROUNDSMAN, KATE; see Section 6) do not select specificaspects of a product to critique. They evaluate the productas a whole to achieve the highest possible quality. Somecritics selectively critique based on a policy specified bythe user. LISP-CRITIC, for,. example, operates differentlydepending on whether cognitive efficiency or machine ef­ficiency is specified as the primary concern for writingLISP programs.

Educational critics, such as the WEST system by Burton& Brown, 1982 (see Section 6) usually employ a morecomplex intervention strategy that is designed to maximizeinformation retention and motivation. For example, aneducational critic may forego an opportunity to critiquewhen it occurs directly after a previous critiquing episode.

Most existing critics operate in the negative mode, thatis, they point out suboptimal aspects of the user's productor solution. A positive critic recognizes the good parts of asolution and informs users about them (the Praise Allcommand in JANUS-CRACK). For performance critics, apositive critic helps users retain the good aspects of aproduct in further revisions; a positive educational criticreinforces the desired behavior and aids learning.

Intervention strategies. Intervention strategies deter­mine when a critic should interrupt and how. Activecritics exercise control over the intervention strategy bycritiquing a product or action at an appropriate time. Theyfunction like active agents continuously monitoring usersand responding to individual user actions. Passive criticsare explicitly invoked by users when they desire anevaluation. Passive critics usually evaluate the (partial)product of a design process, not the individual user actionsthat resulted in the product.

For active critics the intervention strategy must specifywhen to send messages to the user. Intervening im­mediately after a suboptimal or unsatisfactory action hasoccurred (an immediate intervention strategy) has the ad­vantage that the problem context is still active in the users'mind, and they remember how they arrived at the solution.The problem can often be corrected immediately. A dis­advantage of active critics is that they may disrupt a cog­nitive process causing short term memory loss. Users then

need to reconstruct the goal structure that existed beforethe intervention. Delayed critic messages may appear outof context and hence come too late to prevent the userfrom heading towards an undesirable state.

Critics can use any of various intervention modes thatdiffer in the degree to which users' attention is attracted.A critic can force users to attend to the critique by notallowing them to continue with their work. A less in­trusive mode is the display of messages in a separate criticwindow on the screen. This gives users a choice whetherto read and process the message immediately or first com­plete an action in progress. The messages should be dis­played in such a way that they do not go unnoticed. Thosemessages that pertain to users' current focus of attentionshould be easy to find rather than being hidden among alarge set of messages related to other aspects of theproduct.

Adaptation CapabilityTo avoid repetitive messages and to accommodate dif­

ferent user preferences and users with different skills, acritiquing system needs an adaptation capability. A criticthat persistently critiques the user on a position with whichthe user disagrees is unacceptable, especially if the critiqueis intrusive. A critic that constantly repeats an explanationthat the user already knows is also unacceptable.

Critics can be adaptable or adaptive. Systems are calledadaptable if the user can change the behavior of the sys­tem. An adaptive system is one that automatically changesits behavior based on information observed or inferred.An adaptation capability can be implemented by simplydisabling or enabling the firing of particular critic rules, byallowing the user to modify or add rules, and by makingthe critiquing strategy dependent on an explicit. dynami­cally maintained user model.

User modeling in critics (Fischer, Lemke & Schwab,1985) shares ideas and goals with student modeling in in­telligent tutoring systems (Clancey, 1986) and advicegiving natural language dialogue systems (Kobsa &Wahlster, 1989). Computer critics require dynamic, per­sistent user models that can change over time but are ac­cessible to the human user for inspection and modification.How to acquire and represent individual user models is atopic of ongoing research (Mastaglio, 1990).

Explanation CapabilityCritics have to be able to explain the reasons for their

interventions. This provides users with an opportunity toassess the critique and then to decide whether to accept it.Knowing why a product was critiqued helps users to learnthe underlying principles and avoid similar problems in thefuture. In a critiquing system, explanations can be focusedon the specific differences between the system's and theuser's solutions, or on violations of general guidelines.Critics can either give detailed explanations spontaneouslyor provide them on demand. When users can indicate theissues they are interested in, the system can provide en­hanced explanations on demand. One particular approach

uses argumentation as the fundamental structuringmechanism for explanations; this is illustrated in theJANUS-VIEWPOINTS system (Fischer, McCall & Morch,1989).

Advisory CapabilityAll critics detect suboptimal aspects of the user's

product (problem detection mode). Some critics requirethe user to determine how to improve the product bymaking changes to address the problems pointed out bythe critic. Other critics, however, are capable of suggest­ing alternatives to the user's solution. We call thesesolution-generating critics. In the JANUS system, a simpleproblem detecting critic points out that there is a stoveclose to a door. A solution-generating critic would, inaddition, suggest a better location.

Descriptions of CriticsThe purpose of this section is to provide an overview of

critiquing systems that have influenced the development ofthe paradigm or that illustrate an interesting aspect of it.We first describe in some detail two critic systemsdeveloped in our laboratory: LISP-CRITIC and FRAMER.After that, we survey systems developed by others.

LISP-CRITIC

LISP-CRITIC is a system designed to support program­mers (Fischer, 1987; Fischer & Mastaglio, 1989). It helpsits users to both improve the program they are creating andto acquire programming knowledge on demand. Program­mers ask LISP-CRITIC for suggestions on how to improvetheir code. The system then suggests transformations thatmake the code more cognitively efficient (i.e., easier toread and maintain) or more machine efficient (i.e., fasteror requiring less memory).

When LISP-CRITIC finds pieces of code that could beimproved, it shows the user its recommendation(Figure 7). Users can accept the critic's suggestion, rejectit or ask for an explanation to aid in making that decision.In Figure 7, LISP-CRITIC suggests that the user replace aconditional expression using cond with an expressionusing if. The.user can request an explanation of why if ispreferable to condo The system develops an appropriateexplanation, consulting a user model, and displays the ex­planation in hypertext form. The user can use the explana­tion to access more detailed information available aboutLISP in an on-line documentation system (the SymbolicsDocument Examiner). To adequately support a widerange of user expertise, LISP-CRITIC incorporates a usermodeling component (Mastaglio, 1990). LISP-CRmcuses the model to customize explanations so that theycover exactly what the user needs to know.

FRAMER

FRAMER (Lemke, 1989) is an innovative design en­vironment for the design of program frameworks, com­ponents of window-based user interfaces on Symbolics

Lisp-CRITIC

(car u) y»)

(cond «equal r 1) (Mapcar #'list s»(t (Mapcan #'(laMbda (x)

(Mapcar #'(laMbda (y) (cons x y» (perM (reMove x s) (sub1 r»»s»)

v»(car s)(power (cdr s»»)~

II

i i(defunlperM (s r)!! (cond «equal r 1) (Mapcar (function list) s»! ! (t (Mapcan (functionII (laMbda (x)I I (Mapcar (function (laMbda (y) (cons x y»)

II s»» (perM (reMove x s) (sub1 r»»)

II (defun cOMb (s r)i I (cond «= r 1) (Mapcar (function list) s»I I (t (Mapcon (function! ! (laMbda (u)II (cond « < (length u) r) ni 1)! ! (t (Mapcar (function (laMbda (y) (consi I (coMb (cdr u) (1- r»»»)i i s»»

Iliii subseqs 5 ri liii all consecutive subsequences of length rI I(defun subseqs (s r)I i (if « (length 5) r) nil! ! (cons (seq 5 r) (subseqs (cdr s) r»»II(defun seq (s r)!! (cond «= r e) nil)i I (t (cons (car s) (seq

i I(d(~~~ds(~~~~~r~~ ~~~~ 1) A«null sub) t) Ii(t (sub-search sub (cdr ===>

(if (equal r 1)(Mapcar »'list s)(Mapcan #'(laMbda (x)

(Mapcar #'(laMbda (y) (cons x y» (perM (reMove x s) (subl r»»s»

Explanation (Why-cond-to-if-else)

IF Is more readable than COND because It uses fewer parenthesesand because IF has a common English meaning.

Abort Explain New Code Show New CodeAccept Reject Show Original CodeAccept All Set Parameters IWhy Is IhIS Betterl

ZMacs (LISP Font-lock) power. lisp >brentr>zlc MUNCH: (2) * More above]Nove point

Figure 7: The User Interface of LISP-CRITIC

The large editor window shows a program that a user is working on. The LISP-CRITIC window on top of it displays a cond-to-iftransformation and an explanation of why LISP-CRITIC recommended changing the cond function to an if.

LISP machines (Figure 8). The purpose of the FRAMERdesign environment is to enable designers to make use of ahigh-level abstraction - program frameworks - with lit­tle prior training.

FRAMER contains a knowledge base of design rules forprogram frameworks. The rules evaluate the completenessand syntactic correctness of the design as well as its con­sistency with the interface style used on Symbolics Lispmachines. The critics are either mandatory or optional.Mandatory critics represent absolute constraints that mustbe satisfied for program frameworks to function properly.Optional critics inform the user of issues that typically aredealt with differently. The critics are active, and the sys­tem displays the messages relevant to the currentlyselected checklist item in the window entitled Things totake care of. Each message is accompanied by up to three

buttons: Explain, Reject, and Execute. The Explain buttondisplays an explanation of the reasons why the designershould consider this critic suggestion; it also describesways to achieve the desired effect. Optional suggestionshave a Reject or Unreject button depending on the state ofthe suggestion. The Execute button accesses the advisorycapability of FRAMER, which is available for issues thathave a reasonable default solution.

A previous version of FRAMER employed a passivecritiquing strategy. Experimental evidence (Lemke,1989) showed that users often invoked the critic too latewhen a major incorrect decision had already been made.The active strategy with continuous display of messagesused in the newest version of FRAMER solved thisproblem. FRAMER prevents its users from permanentlyignoring the critics by using the checklist. Checklist items

Frarner2 Version 5.0

Arrange the panes as desired in your prograM fraMework shown in the work area. Choose frOMthe following Mouse cOMnands.

-Move the title pane to the top of the fraMe. (Explain) (Reject) (Ex~ute)

-ReMOVe the overlap of DATA and TITLE. (Explain)(Requ.ired)

PaletteNouse Button Operation

Left Get pane of this type.Middle Describe this type.

-Fill the eMpty space inside the prograMfraMework. (Required)

hlngs to take care of:-Add a Menu bar.

hat you can do:Check list iteR: Rrrangeftent of panes

Work AreaNouse Button Operation

Left Move pane.Middle Resize pane.Right Menu of all possible operations.Shift-Left Edit pane options.Shift-Middle Delete pane.

t:jc:.:.:.::.;.:.::.:.:.;:....:.:..:.:.::.:.:.::.;.:.;:.;.:.::.:.:.::.:.;.;;.:.;.:;.;.:.:;.::.::.:.;.;;.;.;.::.;,;,;:,:,:,:;,;;,::':.:.:1

o (Code Generat ion)

IZJ (PrOgraM nane )

IZJ ( In it i 0 1 progrlllM frlllMework )

o (Invoking this prograM)

=>[] t Rrrangeftent of panes j

o (CoMMand loop funct ion)

o (Col'lI"land def ; n i ng nacro )

o (Types of input)

D~

o (CoMMand tab1es )

Check List

Work Area Palette

display-pane named DATA

title-pane named TITLE

I~tl=tle=-~pa=ne==:::-_--,I [listener-pane

display-pane .

lacoopt-valu.. -pano

Mouse-L: Select this item; Mouse-R: Menu.To see other' commands, pr'ess Shift, Control, Meta-Shift, or Super.[Fri 15 Sep 5:14:26] Screen Hardcopy CL USER: User Input

Figure 8: FRAMER

This figure shows a screen image of a session with FRAMER. The system has the following components. The checklistdescribes the elements of the task of designing a program framework. The What you can do window shows the detailed optionspertaining to a checklist item. The window entitled Things to take care ofdisplays the critic messages. The work area is theplace were frameworks are assembled in a direct manipulation interaction style. A palette contains title panes, display panes,and other primitive parts for constructing program frameworks. FRAMER also offers a catalog (not shown) for design bymodification.

cannot be checked off until all suggestions are eitherresolved or rejected.

Short Descriptions of CriticsWhat makes the critiquing approach attractive is that it

has generality across a wide range of domains. The ap­proach has been applied to the domains of medical diag­nosis and patient management, electronic circuit design,learning environments, support of education programs,writing, programming, and text editing. This section of­fers short descriptions of critiquing systems from thesedomains. Most critics have been developed as researchvehicles, but a few are successful commercial applications.We have tried to select those systems that have had sig-

nificant impact on the development of the CrItiquingparadigm and ones that have interesting features or addressunique applications. We begin this section with a discus­sion of the WEST system because it pioneered fundamentalideas that the critiquing paradigm incorporates.

WEST. WEST was an early effort to build a computercoach or critic (Burton & Brown, 1982). WEST teachesarithmetic skill in a gaming environment (a game called"How the West was won"). Burton and Brown's goalwas to augment an informal learning activity with a com­puter coach that would retain the engagement and excite­ment of a student directed activity. At the same time, thesystem was to provide context-sensitive advice on how toplay better so students wouldn't get stuck at suboptimal

levels of playing.Burton and Brown pioneered several important ideas in

WEST. The computer coach builds a bridge between openlearning environments and tutoring in order to supportguided discovery learning. To prevent the coach frombeing too intrusive, the system constructs a model of eachindividual user. The system has diagnostic modelingstrategies for inferring student problems from student be­havior. WEST determines the causes of suboptimal be­havior by comparing the concepts used in the solution of abuilt-in expert and those used in the user's solution. Ex­plicit intervention and tutoring strategies (the most impor­tant one being "tutoring by issue and example") are ex­plicitly represented in the system and operate based on theinformation contained in the model of the user. Theseknowledge structures enable the coach "to say the rightthing at the right time' , and to provide an overallcoherence to the coach's comments.

Although WEST provides an early demonstration of howto construct an intelligent learning environment, itsdevelopment pointed out certain limitations of the ap­proach. The WEST system was a success in demonstratingthe value of a computer coach in an informal learningactivity. But the domain chosen for the system has a num­ber of properties which do not hold for other domains inwhich critics are needed. The computer expert can play anoptimal game (i.e., there is a best solution), and it candetermine the complete range of alternative behaviors. InWEST one can speak of "bugs" whereas for many otherdomains one can only speak of "suboptimal" behavior.The metric to compute the best move is simple, whereasmetrics in domains such as kitchen or software design in­volve a potentially large number of controversial issues.The set of issues for the game is closed whereas it is open­ended in many other domains. The goal of the user isobvious in WEST - to win the game while obeying itsrules. This is another simplifying assumption which doesnot apply to many other domains. The explanationstrategy in WEST relies on the assumption that the advicegiven is self-explanatory because it contains a good il­lustrating example. The existence of a best solution andno need for modifying the rlies in the domain eliminatesthe need for an argumentation component such as the onefound in JANUS.

Medical applications of the critiquing approach.Researchers in the domain of medicine developed severalof the early critiquing systems. In general, these systemsare designed to aid the physician in diagnosis and planningof patient treatment. Miller and colleagues at Yale Medi­cal School have done a majority of the work in this area.Their systems assist a physician or nurse by analyzingplans for prescribing medication, managing the ad­ministration of medication, ventilator management, andadministration of anesthetics (Miller, 1986).

Miller's ATTENDING system (Miller, 1986) uses the dif­ferential critiquing approach. ATTENDING parses thephysician's plan into a hierarchical form. Starting fromthe top-level decisions, the system evaluates each step of

the physician's plan by trying to find alternatives as­sociated with lower or equal risks to the patient. Thismethod provides a more reasonable critique than one thatdiscards the physician's solution and proposes a com­pletely new solution developed by the system expert. Byworking from the physician's solution, the system's solu­tion is as close to the physician's solution as possible, andthe critique is more helpful and easier to understand.

The differential critiquing approach is also used in oneversion of ONCOCIN, an expert system for cancer therapy(Langlotz & Shortliffe, 1983). The critiquing approachwas chosen because it eliminates the need for thephysician to override the system solution when minordeviations in the therapy are desired for the convenienceof the patient.

The ROUNDSMAN system (Rennels, 1987; Rennels,Shortliffe, Stockdale & Miller, 1989) is a critic in thedomain of breast cancer treatment. ROUNDSMAN ex­plicitly bases its critique on studies from the medicalliterature. It is a passive critic with explicit goal specifica­tion. ROUNDSMAN automatically provides a detailed ex­planation of its reasoning and suggests improvements tothe physicians therapy proposal. It does not use a user ordialog model and, therefore, repeats similar explanations.

Circuit design. CRITTER (Kelly, 1985) is a design aidin the domain of digital circuit design. CRITTER requires aschematic diagram of the circuit and a set of specificationsthat the circuit must satisfy. Given this information, Crit­ter produces a report about the circuit, which can be usedin a subsequent design cycle to revise the design. CRITTERevaluates the circuit using various circuit analysis tech­niques and knowledge of the primitive components. Theresults of this evaluation include general information aboutwhether the circuit will work and by what margins, itsweaknesses, and performance limits.

NCR developed the Design Advisor (TM) (Steele,1988), a commercial expert system that provides advice onapplication-specific, integrated circuit designs. The sys­tem uses a logic-based rule mechanism (Hom clauses) in­cluding both forward and backward chaining rules with aframe based representation and a truth maintenance sys­tem. The Design Advisor analyzes the performance, tes­tability, manufacturability, and overall quality of CMOSsemi-custom VLSI designs. The knowledge it applies is ahierarchy of design attributes compiled by studying majorproblems from several years of commercial VLSI design.The designer submits a proposed design to the system foranalysis and critiquing using a batch type approach. Thesystem returns its analysis to the designer who is respon­sible for actually modifying the proposed design.

Discovery learning. A suite of three computer-basedcoaching systems for discovery learning developed atLRDC, University of Pittsburgh, are based on critics.These systems each address a different domain: Smith­town - microeconomics (Raghaven, Schultz, Glaser &Schauble), Voltaville - direct current electricity (Glaser,Raghavan & Schauble, 1988), and Refract - geometricaloptics (Reimann, Raghaven, GlaserI988). These dis-

covery environments are designed to build scientific in­quiry skills. Active critics judge the efficiency of theprocesses used to build scientific theory and inform usersabout errors that characteristically trap less successful stu­dents as well as guide them to effective strategies.

Decision making. The DecisionLab system from theEuropean Computer Industry Research Center (Schiff &Kandler, 1988) applies the critiquing approach to coachusers in managerial decision making. DecisionLabpromotes "learning while doing" by providing construc­tive feedback on a user developed management plan in asimulated management game. The system critiques deci­sions and informs users when they pursue a non optimalapproach. This system is of interest because it attempts tointegrate a critic with a simulation exercise in a computa­tional environment designed to support learning.

Another direction of research is investigating how toapply the critiquing approach to improve the performanceof decision makers, not through training, but in the contextof their actual work. Mili (1988) has proposed a systemcalled DECAD, which watches over the shoulder of thedecision maker, interjecting advice or a critique when ap­propriate. Critiquing is one of the approaches under inves­tigation for a class of knowledge-based systems called"active and symbiotic decision support systems" (Mili &Manheim, 1988).

Curriculum development. The Alberta ResearchCouncil (Canada) and a company called Computer BasedTraining Systems have developed a knowledge-based sys­tem which provides assistance to teachers who do cur­riculum and course development (Wipond & Jones, 1988).The system includes an Expert monitor module thatmonitors the curriculum and course development process,intervening when necessary or when the teacher asks forassistance. It provides a critique which the user can acceptor reject. The expert monitor is also capable of suggestingwhat the user should do next, where to look for relevantexamples or how to get more help. Computer BasedTraining Systems is now marketing the product as part oftheir Computer Managed Learning software package.

Writing. WANDAH (Friedman, 1987) is a system thatassists authors in all phases of writing. This system iscommercially available for personal computers as 'HBJWriter." WANDAH has heuristics to help the user designand prepare a document. Once a writer has created sometext (it need not be a completed document), it can be sub­jected to one of four sets of reviewing and revising aids.These aids go over the written work, provide feedback onstructural problems, and recommend revisions. Testing ofWANDAH showed that users find it easy to use and learn towrite better.

Text editing. ACTIVIST (Fischer, Lemke & Schwab,1985) is an active help system for a screen-oriented editor.ACTIVIST continuously monitors the editing actions of theuser. By doing this, it recognizes, using finite statemachines, sequences of actions that achieve some goalknown to the system. ACTIVIST understands twenty dif­ferent goals, such as deleting a word or moving the cursor

to the end of the current line. The system evaluates eachrecognized action sequence to update a user model.ACTIVIST uses the following critiquing strategy: Afterthree suboptimal executions of a task type (measured bythe number of keystrokes), ACTIVIST infonns the user of abetter procedure for the task. After a certain number ofcorrect executions, the plan will no longer be watched. Inorder to be less intrusive, ACTIVIST ceases to critique ac­tions when the user ignores its suggestions.

Operating system usage. WIZARD (Finin, 1983) is anactive help system for users of the VMS operating systemcommand language. Like ACTIVIST, WIZARD has torecognize sequences of commands that, taken together,form a plan to achieve a goal known to the system. Theexpectation-based parser used for this purpose allows non­contiguous command sequences that contain interspersedcommands from other goals. Metrics such as amount oftyping and use of system resources are implicit in therepresentations of the plans. Advice is given using texttemplates.

Programming. PROLOG Explaining (Coombs & Alty,1984) critiques a user's explanation of PROLOG code.The system uses the critiquing approach to guide the usertoward a better understanding of the PROLOG language.Users construct an explanation of what they believe thecode will do. The system's job is to critique that explana­tion. The user may request a critique at any point duringthe process of the explanation building. Also, the systemautomatically critiques the explanation at the end of aprogram run.

The GRACE Project at the NYNEX Artificial Intel­ligence Laboratory (Dews, 1989; Atwood, Gray, Burns &Morch, 1990) has developed an integrated learning en­vironment for COBOL programming. The GRACE sys­tem combines a tutor, a critic, and a hypertext system tosupport a spectrum of teaching methods ranging fromguided teaching by the tutor, to integrating working andlearning with the critic, and to exploratory browsing inhypertext. While the system is functioning as a critic, itcan decide to adopt the tutoring mode to give remedialproblems; conversely, while functioning as a tutor, the sys­tem may decide to let the student explore in the critiquingmode. In either case the system provides directly acces­sible hypermedia documentation with text, graphics, andother presentation media.

Software engineering. KATE (Fickas & Nagarajan,1988) critiques software specifications (for automatedlibrary systems) represented in an extended Petri net nota­tion. The knowledge of the critic is represented as"cases" that consist of a pattern describing a behavior in aspecification, links to one or more goals, simulationscenarios, and canned text descriptions. The criticevaluates the specification with respect to goals or policyvalues given by the user. The simulation scenarios backup the system's critique and are designed to approximatethe rich set of examples that software professionals havebeen found to use.

Mechanical design. STEAMER/Feedback Mini-Lab

(Forbus, 1984) is an environment in which simulateddevices, such as steam plant controllers, can be assembledand tested. A device is assembled from simple buildingblocks such as actuators and comparators. The Mini-Labis able to generate code from the building block specifica­tions to produce a simulation program for the device.After students have constructed their device, they can askfor a critique by the system. This critique identifies com­mon bugs and recognizes some instances of knowndevices.

ConclusionThe systems described in this paper show that critiquing

is an emerging paradigm for knowledge-based systems.Building a knowledge-based system is a major effort, andcritics are no exception. Realistic systems that providebroad functionality and support tools are needed to test theusefulness of critics in actual settings. Critics are oftenembedded systems; for example, they constitute only onepart of the JANUS and FRAMER environments.

The strengths of critics are that they support users whoare involved in their own work and that they integratelearning with that work. As noted in several recentresearch efforts (e.g., Schoen, 1983; Suchman, 1987; Bod­ker, Knudsen, Kyng, Ehn & Madsen, 1988; McCall, Fis­cher & Morch, 1989), professional practice in design isboth action and reflection. The basis for design is a com­bination of personal involvement and rational understand­ing, rather than detached reflection. Systems such asJANUS and FRAMER allow "the situation to talk back"through critics that point out breakdowns. By showingth~~ the artifact under construction has shortcomings,cnttcs cause users to pause for a moment, to reflect on thesituation, and to apply new knowledge to the problem aswell as to explore alternative designs. By serving as skill­enhancing tools, critics support the ' 'Scandinavian ap­proach to system design" (Bodker et al., 1988). Criticshelp inexperienced users to become lay designers; for ex­perienced users, they serve as reminders of the principlesof good design.

One of the features that contributes to the strengths ofcritics is at the same time a potential weakness. Support­i?g users in their own doing means that detailed assump­ttons about what a user might do cannot be built into thesystem. Our critic systems have only a limited under­standing of the goals that users pursue. This limitationre~tricts the amount of assistance and detailed goal­onented analysis that critics can provide, in contrast tosystems that have a deep understanding of a very small setof problems (for example, Johnson & Soloway, 1984).

Critics need inspectable knowledge structures so thatusers can understand, modify, and augment them (Fischer& Girgensohn, 1990). This modification should not re­quire users to possess detailed programming knowledge.Users should be able to deactivate and reactivate in­dividual critics according to their needs and their goals.With sufficient inference and user modeling capabilities,systems can adapt themselves dynamically (ACTIVIST con-

tains a mechanism to support this).Observing users of JANUS and FRAMER showed that

users do not always notice the critique generated by thesystem or that they ignore the advice. A more detailedanalysis of attention and intervention is required to devel­op critiquing strategies that insure that users do not missimportant information, but at the same time are not inter­rupted in situations where they should focus on otherissues.

Currently, most critics support only "one-shot dialogs"(Aaronson & Carroll, 1987). They respond to actionstaken by the user; they give suggestions and provide ex­planations and argumentation. But human critiquing is amore cooperative problem solving activity, during whichan increased understanding of the problem develops.

We have attempted to provide answers to some of theseissues by presenting the critiquing paradigm as an alter­native approach to using knowledge-based computer sys­tems to support human work and learning. Existingcritiquing systems were surveyed. Critics are not the onlysolution to building better knowledge-based systems, butwe believe that a growing number of them will contain acritiquing component. Some of these systems will haveelaborate problem understanding, but more commonlythey will have limited yet helpful capabilities. Critics arean important step towards the creation of more useful andmore usable computer systems for the future.

AcknowledgmentsMany people have contributed to the development of

our notion of the critiquing paradigm. The authors wouldlike to thank especially: the members of the Janus DesignProject (Ray McCall, Kumiyo Nakakoji, and JonathanOstwald), the members of the LISP-CRITIC project (Heinz­Dieter Boecker, Chris Morel, Brent Reeves, and JohnRieman), all the people who have participated in discus­sions about the general framework for critiquing (ThomasSchwab, Helga Nieper-Lemke, Curt Stevens, Tom DiPer­sio, and Hal Eden), and the HCC research group as awhole. This research was partially supported by grant No.IRI-8722792 from the National Science Foundation, grantNo. MDA903-86-C0143 from the Army Research In­stitute, and grants from the Intelligent Interfaces Group atNYNEX and from Software Research Associates (SRA),Tokyo.

ReferencesAaronson, A. & Carroll, J. M. (1987). Intelligent Help in

a One-Shot Dialog: A Protocol Study. Human Factorsin Computing Systems and Graphics Interface,CHI+GI'87 Conference Proceedings (Toronto,Canada), 163-168. New York: ACM.

Anderson, J. R. & Reiser, B. J. (1985). The LISP Tutor.BYTE, 10(4), 159-175.

Atwood, M. E., Gray, W. D., Bums, B., Morch, A. 1. &Radlinski, B. (1990). Cooperative Learning andCooperative Problem Solving: The Case of Grace.

Working Notes, 1990 AAAl Spring Symposium onKnowledge-Based Human-Computer Communication,6-10. Menlo Park, CA: AAAL

Bodker, S., Knudsen, J. L., Kyng, M., Ehn, P. & Madsen,K. H. (1988). Computer Support for CooperativeDesign. Proceedings of the Conference onComputer-Supported Cooperative Work (CSCW'88),377-394. New York: ACM.

Bond, A. H. & Gasser, L. (Eds.). (1988). Readings inDistributed Artificial Intelligence. San Mateo, CA:Morgan Kaufmann Publishers.

Burton, R. R. & Brown, J. S. (1982). An Investigation ofComputer Coaching for Informal Learning Activities:In Sleeman, D. H. & Brown, J. S. (Eds.), IntelligentTutoring Systems (pp. 79-98). London - New York:Academic Press.

Carroll, J. M. & McKendree, J. (1987). Interface DesignIssues for Advice-Giving Expert Systems.Communications of the ACM, 30(1), 14-31.

Carver, N. F., Lesser, V. R. & McCue, D. L. (1984).Focusing in Plan Recognition. Proceedings ofAAAl-84, Forth National Conference on ArtificialIntelligence (Austin, TX), 42-48. Los Altos, CA:William Kaufmann.

Clancey, W. J. (1986). Qualitative Student Models.Annual Review ofComputing Science, 1,381-450.

Coombs, M. J. & Alty, J. L. (1984). Expert Systems: AnAlternative Paradigm. International Journal ofMan-Machine Studies, 20.

Dews, S. (1989). Developing an ITS in a CorporateSetting. Proceedings of the 33rd Annual Meeting ofthe Human Factors Society, 1339-1342.

Draper, S. W. (1984). The Nature of Expertise in UNIX.Proceedings ofINTERACT'84, IFIP Conference onHuman-Computer Interaction, 182-186. Amsterdam:Elsevier Science Publishers.

Fickas, S. & Nagarajan, P. (1988). Critiquing SoftwareSpecifications. IEEE Software, 5(6),37-47.

Finin, T. W. (1983). Providing Help and Advice in TaskOriented Systems. Proceedings of the EighthInternational Joint Conference on ArtificialIntelligence, 176-178.

Fischer, G. (1987). A Critic for LISP. Proceedings of the10th International Joint Conference on ArtificialIntelligence (Milan, Italy), 177-184. Los Altos, CA:Morgan Kaufmann Publishers.

Fischer, G. (1990). Communications Requirements forCooperative Problem Solving Systems. TheInternational Journal ofInformation Systems (SpecialIssue on Knowledge Engineering).

Fischer, G. & Girgensohn, A. (1990). End-UserModifiability in Design Environments. HumanFactors in Computing Systems, CHI'90 ConferenceProceedings (Seattle, WA), 183-191. New York:ACM.

Fischer, G. & Lemke, A. C. (1988). Construction Kits andDesign Environments: Steps Toward HumanProblem-Domain Communication. Human-ComputerInteraction, 3(3), 179-222.

Fischer, G., Lemke, A. C. & Schwab, T. (1985).Knowledge-Based Help Systems. Human Factors inComputing Systems, CHI'85 Conference Proceedings(San Francisco, CA), 161-167. New York: ACM.

Fischer, G. & Mastaglio, T. (1989). Computer-BasedCritics. Proceedings of the 22nd Annual HawaiiConference on System Sciences, Vol. III: DecisionSupport and Knowledge Based Systems Track,427-436. IEEE Computer Society.

Fischer, G., McCall, R. & March, A. (l989a). DesignEnvironments for Constructive and ArgumentativeDesign. Human Factors in Computing Systems,CHI'89 Conference Proceedings (Austin, TX),269-275. New York: ACM.

Fischer, G., McCall, R. & Morch, A. (1989b). JANUS:Integrating Hypertext with a Knowledge-Based DesignEnvironment. Proceedings ofHypertext' 89, 105-117.New York: ACM.

Fischer, G. & Morch, A. (1988). CRACK: A CritiquingApproach to Cooperative Kitchen Design.Proceedings of the International Conference onIntelligent Tutoring Systems (Montreal, Canada),176-185. New York: ACM.

Forbus, K. (1984). An Interactive Laboratory forTeaching Control System Concepts (Report 5511).Cambridge, MA: BBN.

Friedman, M. P. (1987). WANDAH - A ComputerizedWriter's Aid: In Berger, D. E., Pezdek, K. & Banks,W. P. (Eds.), Applications ofCognitive Psychology,Problem Solving, Education and Computing (pp.219-225). Hillsdale, NJ: Lawrence ErlbaumAssociates.

Glaser, R., Raghavan, K. & Schauble, L. (1988).Voltaville: A Discovery Environment to Explore theLaws of DC Circuits. Proceedings of the InternationalConference on Intelligent Tutoring Systems (Montreal,Canada),61-66.

Greif, 1. (Ed.). (1988). Computer-Supported CooperativeWork: A Book ofReadings. San Mateo, CA: MorganKaufmann Publishers.

Hoppe, H. U. (1988). Task-Oriented Parsing: ADiagnostic Method to be Used by Adaptive Systems.Human Factors in Computing Systems, CHI' 88Conference Proceedings (Washington, DC), 241-247.New York: ACM.

Johnson, W. L. & Soloway, E. (1984). PROUST:Knowledge-Based Program Understanding.Proceedings of the 7th International Conference onSoftware Engineering (Orlando, FL), 369-380. LosAngeles, CA: IEEE Computer Society.

Jones, R. J. & Kapple, W. H. (1984). Kitchen PlanningPrinciples - Equipment - Appliances.

Urbana-Champaign, IL: Small Homes Council ­Building Research Council, University of Illinois.

Kelly, V. E. (1985). The CRITTER System: AutomatedCritiquing of Digital Circuit Designs. Proceedings ofthe 21 st Design Automation Conference, 419-425.

Kobsa, A. & Wahlster, W. (Eds.). (1989). User Models inDialog Systems. New York: Springer-Verlag.

Langlotz, C. P. & Shortliffe, E. H. (1983). Adapting aConsultation System to Critique User Plans. Int.J. Man-Machine Studies, 19, 479-496.

Lemke, A. C. (1989). Design EnvironmentsforHigh-Functionality Computer Systems. Unpublisheddoctoral dissertation, Boulder, CO: Department ofComputer Science, University of Colorado.

London, B. & Clancey, W. J. (1982). Plan RecognitionStrategies in Student Modeling: Prediction andDescription. Proceedings ofAAAI-82, SecondNational Conference on Artificial Intelligence(Pittsburgh, PA), 335-338.

Mastaglio, T. (1990). User Modelling in Computer-BasedCritics. Proceedings of the 23rd Hawaii InternationalConference on System Sciences, Vol III: DecisionSupport and Knowledge Based Systems Track,403-412. IEEE Computer Society.

McCall, R., Fischer, G. & Morch, A. (1989). SupportingReflection-in-Action in the Janus Design Environment.Proceedings of the CAAD Futures'89 Conference.Cambridge: Havard University.Pre-PublicationEdition.

Mili, F. (1988). A Framework for a Decision Critic andAdvisor. Proceedings of the 21 st Hawaii InternationalConference on System Sciences, 381-386.

Mili, F. & M:anheim, M. L. (1988). And What Did YourDSS Have to Say About That: Intoduction to the DSSMinitrack on Active and Symbiotic Systems.Proceedings of the 21st Hawaii InternationalConference on System Sciences, 1-2.

Miller, P. (1986). Expert Critiquing Systems:Practice-Based Medical Consultation by Computer.New York - Berlin: Springer-Verlag.

Papert, S. (1980). Mindstorms: Children, Computers andPowerful Ideas. New York: Basic Books.

Raghaven, K., Schultz, J., Glaser, R. & Schauble,L. (1990). A Computer Coachfor Inquiry Skills.Unpublished.draft submission to Intelligent LearningEnvironments Journal.

Rennels, G. D. (1987). A computational model ofreasoning from the clinical literature. Springer

Verlag.

Rennels, G. D., Shortliffe, E. H., Stockdale, F. E. &Miller, P. L. (1989). A computational model ofreasoning from the clinical literature. AI Magazine,10(1),49-56.

Riemann, P., Raghaven, K. & Glaser, R. (1988). Refract,a Discovery Environment for Geometrical Optics(Technical Report). Learning Research &Development Center, University of Pittsburgh.

Sacerdoti, E. D. (1975). A Structure for Plans andBehavior (Technical Note 109). Stanford, CA:Stanford Research Institiute.

Schiff, J. & Kandler, J. (1988). Decisionlab: A SystemDesigned for User Coaching in Managerial DecisionSupport. Proceedings of the International Conferenceon Intelligent Tutoring Systems (Montreal, Canada),154-161.

Schmidt, C. F., Sridharan, N. S. & Goodson, J. L. (1978).The Plan Recognition Problem: An Intersection ofPsychology and Artificial Intelligence. ArtificialIntelligence, 11,45-83.

Schoen, D. A. (1983). The Reflective Practitioner: HowProfessionals Think in Action. New York: BasicBooks.

Simon, H. A. (1986). Whether Software EngineeringNeeds to Be Artificially Intelligent. IEEETransactions on Software Engineering, SE-12(7),726-732.

Steele, R. L. (1988). Cell-Based VLSI Design AdviceUsing Default Reasoning. Proceedings of3rd AnnualRocky Mountain Conference on AI, 66-74. Denver,CO: Rocky Mountain Society for ArtificialIntelligence.

Stefik, M. J. (1986). The Next Knowledge Medium. AIMagazine, 7(1), 34-46.

Suchman, L. A. (1987). Plans and Situated Actions. NewYork: Cambridge University Press.

Sussman, G. J. (1975). A Computer Model ofSkillAcquisition. New York: American Elsevier.

Wenger, E. (1987). Artificial Intelligence and TutoringSystems. Los Altos, CA: Morgan KaufmannPublishers.

Wipond, K. & Jones, M. (1988). Curriculum andKnowledge Representation in a Knowledge-BasedSystem for Curriculum Development. Proceedings ofthe International Conference on Intelligent TutoringSystems (Montreal, Canada), 97-102.