The Role of Critiquing in Cooperative Problem Solving GERHARD FISCHER, ANDREAS and ANDERS 1. MORCH University
of Colorado,
C. LEMKE,
THOMAS
MASTAGLIO,
Boulder
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. Categories and Subject Descriptors: H. 1.2 [Models and Principles]: Ueer/Machine Systems–human factors; H.3.3 [Information Storage and Retrieval]: Information Search and Retrieval; J.6 [Computer Applications]: Computer-Aided Engineering–computer-aided design; K, 3.1 [Computers and Education]: Computer Uses in Education General
Terms: Design,
Human
Factors
Additional Key Words and Phrases: design environments, high-functionality
Cooperative computer
problem-solving systems, critics, critiquing, systems, intelligent support systems
1. INTRODUCTION
The critiquing approach is an effective way to use computer knowledge bases to aid users in their work and to support learning. Our experience with this approach consists of several years of innovative system building, integration This research was partially supported by grant NOO014-85-K-0842 from the Office of Naval Research, grants IRI-8722792 and IRI-9015441 from the National Science Foundation, grant MDA903-86-C0143 from the Army Research Institute, and grants from the Intelligent Interfaces Group at NYNEX and from Software Research Associates (SRA), Tokyo, Authors’ addresses: G. Fischer and A. C. Lemke, Department of Computer Science and Institute for Cognitive Science, University of Colorado at Boulder, Boulder, CO 80309 T. Mastaglio, U.S. Army TRADOC, P O. Box 298, Fort Monroe, VA 23651; A. 1, Morch, NYNEX Science and Technology, 500 Westchester Avenue, White Plains, NY 10604; email:
[email protected] .edu, andreas@cs .colorado. edu, mastaglt%rnonl @leavemh. army. roil, anders@nynexst .com. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. @ 1991 ACM 1046-8188/91/0400-0123 $01.50 ACM
Transactions
on Information
Systems,
Vol. 9, No. 3, April
1991, Pages 123-151.
124
.
G. Fischer et al.
of cognitive and design theories, empirical observations and evaluation of prototypes. In this paper, we discuss the role of critiquing in cooperative problem solving. By illustrating the approach with examples from our own work and critics developed by others, we develop a general characterization of the critiquing process. We conclude with a discussion of potential future research on the critiquing paradigm. 2. THE ROLE OF CRITIQUING
2.1 Cooperative
Problem
IN COOPERATIVE
PROBLEM
SOLVING
Solving
Cooperative problem solving [15, 41, 60, 63] in the context of this paper refers to cooperation between a human and a computer. To design successful cooperative problem-solving systems, issues such as what role each partner should play, when to take the initiative and how to communicate to the other partner must be resolved. These issues are shared with two related but Cooperative Work (C’SCW) [331, different research areas: Computer-Supported which describes the cooperation between humans mediated by a computer Artificial Intelligence [51, which refers to cooperation between and Distributed computer systems. Cooperative problem solving requires more from a system than having a nice user interface or supporting natural language dialogs. The design of cooperative problem-solving systems must be based on a theory of problem solving that describes the functions of shared representations, mixed-initiative dialogues, argumentation and management of trouble. Coopof the communicaerative problem-solving approaches exploit the asymmetry tion process. Humans use common sense, define the common goal, decompose problems into subproblems and so on. Computers provide external memory for the human, insure consistency, hide irrelevant information and summarize and visualize information. Cooperative problem-solving systems are examples of human-computer cognitive systems [661. They serve as cognitive amplifiers of the human. The goal of building such cooperative systems challenges the predominant goal of artificial intelligence: understanding and building autonomous, intelligent, thinking machines. Along with many other researchers [601, we believe that building cooperative problem-solving systems and interactive knowledge media is at least as important a goal as building autonomous thinking machines. The major difference between classical expert systems, such as MYCIN [61 and RI [451, and cooperative problem-solving systems involves the roles of the human and computer. Most expert systems ask the user for input, make all decisions and then return an answer. In a cooperative problem-solving system, the user is an active agent empowered by the system’s knowledge. In this paper, we review critiquing systems in which the human generates an artifact and the computer critiques it. This is not the only role we have explored for critiquing. Alternately, computers can propose solutions and the humans subsequently critique and modify them. Examples of this latter approach are discussed by Nieper-Lemke [481 for layout of graphs and by Fischer and Stevens [29] for filters that reduce large information spaces. In both examples, the systems have algorithms for creating a first approximaACM
TransactIons
on Information
Systems,
Vol
19, No. 2, April
1991
The Role of Critiquing in Cooperative Problem Solving
.
125
tion of the desired artifact, which the users can then critique and modify. To generate the first approximations, the systems collect information about the graphs and the information spaces that is not necessarily known to the users. The following aspects of cooperative problem solving are of special interest in this paper: –Breakdowns in cooperative problem-solving systems are not as detrimental or “design away” all of as in expert systems. One can never anticipate
the misunderstandings and problems that might arise in achieving a goal. System resources are needed to recognize and deal with the unexpected. A cooperative system needs to deal with open problems and know about the human problem solver’s intentions, which often change during problem solving. assumptions do not need to be fully articulated. Suchman [61] argues that background assumptions cannot be fully inventoried in any formal system. It is a strength of human experts that they know the larger problem context, which enables them to solve ill-defined problems and to learn while solving problems. This learning improves the conceptual structure of their knowledge. Experts can judge the relevance of design knowledge to design problems and they know when design rules should be broken. Expert performance degrades gracefully as they attempt to solve problems that are further removed from the core of their expertise. Current expert systems are limited in these capabilities.
–Background
system architectures are appropriate. Semiformal computer systems need not be capable of interpreting all information structures available to them. The systems deliver information to humans and humans read and interpret it. Semiformal systems can be used more extensively in cooperative systems than in expert systems and will play a large role in the design of effective joint human-computer systems.
–Semiformal
problem. Automating a task or delegating it to another person requires that the task be precisely described. Most tasks involve many background assumptions that delegators are incapable of describing. The cooperative approach eliminates the need to perfectly specify tasks. Instead, the cooperating agents incrementally evolve an understanding of the task.
—Delegation
Humans often enjoy the process enjoy “doing” and “deciding.” and not just the product; they want to take an active part. This is why they build model trains, why they plan their vacations, and why they design their own kitchens. Automation is a two-edged sword. At one extreme, it is a servant, relieving humans of the tedium of low-level operations and freeing them for higher cognitive functions. Many people do not enjoy checking documents for spelling errors, and welcome the automation provided by spelling checkers in word processors. At the other extreme, automation can reduce the status of humans to “button pushers” and strip their work of its meaning and satisfaction. People’s willingness to delegate tasks depends on the extent to which
–Humans
ACM
‘hansact,ons
on Information
Systems,
Vol.
19, No. 2, April
1991.
126
0
G. Fischer et al.
they trust they will receive satisfactory solutions. Critics allow—and indeed force—them to exercise a great deal of personal control over, and to take responsibility for, the design of the product. 2.2
The Critiquing
Approach
Critiquing is a major activity of a cooperative problem-solving system. Critiquing is the presentation of a reasoned opinion about a product or action (Figure 1).’ The product could be a computer program, a kitchen design or a medical treatment plan; the action could be a sequence of keystrokes that corrects a mistake in a word processor document or a sequence of operating system commands. An agent —human or machine— capable of critiquing in this sense is a critic. Critics are made up of a set of rules or procedural specialists for different aspects of a product; sometimes each individual rule or specialist is referred to as a critic. Critics do not necessarily solve problems for the user. The core task of critics is to recognize and communicate debatable issues concerning a product. Critics point out errors and suboptimal conditions that might otherwise remain undetected. Many critics also advise users on how to improve the product and explain their reasoning. Critics thus help users avoid problems and learn different views and opinions. Characterization of domains suited for critiquing. Critics are particularly well suited for design tasks in complex problem domains. Design problems are ill-defined [58] or wicked [53]. They do not have an optimal solution and the problem cannot be precisely specified before attempting a solution. Critics can function with only a partial understanding of the task. Even if the system knows only aspects of the general problem domain, it can provide support by applying generic design knowledge. Not all problems fit this description; there are problems in engineering design and operations research that can be precisely specified and for which optimal solutions can be found. Those types of problems yield more to algorithmic solutions and are not good candidates for the critiquing ap preach. Expert systems are inadequate in situations where it is difficult to capture Because they leave the human out of the sufficient domain knowledge. decision process and all “intelligent” decisions are made by the computer, autonomous expert systems require a comprehensive knowledge base covering all aspects of the tasks being performed. Some domains, such as user interface design and computer net work design, are not sufficiently under stood and creating a complete set of principles that adequately capture their domain knowledge is infeasible. Other domains, such as high-functionality computer systems [10, 39], are so vast that a tremendous effort is needed to acquire all relevant knowledge. Critics are better suited to these situations
— lIn the remainder of the paper the term “product” is often used in a generic sense, encompassing both product in a narrow sense as well as actions. ACM Transactions
on Information
Systems, Vol. 19, No 2, Aprd 1991
The Role of Critiquing in Cooperative Problem Solving
Goals
127
.
Model
User
)
[
Fig. 1. The critiquing approach. This figure shows that a critiquing system has two agents, a computer and a user, working in cooperation. Both agents contribute what they know about the domain to solving some problem. The human’s primary role is to generate and modify solutions; the computer’s role is to analyze those solutions and produce a critique for the human to apply in the next iteration of this process.
because they need not be complete domain experts. on only some aspects of the problem domain.
Critics
often are experts
History. The term “critic” has been used to describe several closely related yet different ideas. It was first used in planning systems to describe internal demons that check consistency during plan generation. For example, [621 discover errors in blocks-world programs. critics in the HACKER system When
a critic
edits
the
critics
that
specific
in
critics
tightly
conceptual
2.3
the
that
the
with
sense
frameworks,
Descriptions
the
notifies
the
critic.
The
and
interactions
internal paper
planner NOAH
modify
general
components interact
of
with
of ill-defined
the
the
of prototypical
and
evaluations.
which contains into
more
Critics
planning users.
development
of Our Critiquing
plans
human
the
[541
subgoals.
problems,
study
system
component, system
of multiple
the
frameworks
of Some
it the
problems the
of this
integrates
conceptual
by
planning consider
interact
critics
a problem,
as directed
recognize
ones
planners
ing
discovers
program
Our
work
development
systems
in
system; on of
instantiat-
Systems
In this section, we provide an overview of critiquing systems that have influenced the development of the paradigm or that illustrate an interesting aspect of it. We describe in some detail the critiquing systems developed in our own work as mentioned in Figure 2. Activist—Systems that volunteer information. Humans often learn by receiving answers to questions that they have never posed or were not able to pose. To ask a question, one must know how to ask it; one cannot ask ACM
Transactions
on Information
Systems,
Vol.
19, No. 2, April
1991.
128
G. Fischer et al.
.
“ active help systems
4CTIVIST
.ISP-CRITIC
‘RAMER
●
system volunteers
●
style
●
visual
●
minimalist
rules define
9 making
●
ways
of designing
artifacts
explanations construction the situation
“ signaling
JANUS
standard
explanations
“ extending
●
information
kits to design
environments
talk back
breakdowns
checklists integrating
construction
and
argumentation
to support
reflection-in-
action * relevancy ●
to the task at hand
multiple critics with different points of view
“ competent
blODIFiER
practitioners
of completely * tacit
knowledge
* critiquing
is triggered
knowledge
Fig. 2.
know
articulating
more
of our evolving
they
can
say
(impossibility
assumptions)
by situations,
is judgmental,
Features
than
background
by breakdowns
instable,
critiquing
and never
complete
systems
questions about something if one is not aware of its existence. ACTIVIST [23] is looks a critic in the form of an active help system for a text editor. ACTIVIST “over the shoulder” of a user and infers user goals from observed actions. The system then matches the user’s actions to plans in its knowledge base volunteers information at approprithat accomplish the same goals. ACTIVIST ate times based on a user model, After three suboptimal executions of a task ACTIVIST informs the user of a type (measured by the number of keystrokes), better
procedure
critique
actions
for when
the the
task, user
In
order
ignores
to be less its
intrusive,
ACTIVIST
ceases
to
suggestions.
LISP-CRITIC k a system LISP-CRITIC—Applying critics to programming. designed to support programmers [14, 24]. It helps programmers to both improve the programs they are creating and acquire programming knowlfor suggestions on how to edge on demand. Programmers ask LISP-CRITIC improve their code. The system suggests transformations that make the code more cognitively efficient (i. e., easier to read and maintain) or more machine suggestions require efficient (i. e., faster or smaller). Many of LISP-CRITIC’S user confirmation because they preserve program correctness only if certain ACM
TransactIons
on Information
Systems,
Vol.
19, No. 2, April
1991.
The Role of Critiquing in Cooperative Problem Solving
conditions are met that cannot be derived Figure 3 shows a screen image of LISP-CRITIC. LISP-CRITIC they
is a passive
desire
its
suggestions.
SYMBOLICS
LISP
which
cursor
the
be improved, the
is located.
system
When
the
user
and
In
scenario
the
is,
they
code alone.
to invoke
critic
have
analyzes
the
system
finds
the
its
users
can
ask
for
Figure
in the
ZMACS
pieces
editor that
accept
to aid
suggests
on
within
of code can
explanation
3, LISP-CRITIC
when
definition
Users
an
the
function
recommendation.
in
129
the program
is embedded
LISP-CRITIC
suggestion
decision.
that
The
machines.
it shows
critic’s
that
critic;
from
.
could
or reject in
that
making the
user
expression with an if expression. The user requests an explanation of why if is preferable to cond. The system develops an appropriate explanation based on a user model and displays the explanation in hypertext form. The user can use the explanation to access more detailed information available about LISP in an on-line documentation system (the Symbolics Document Examiner). This incremental unfolding of information spaces supports a minimalist explanation strategy [181. replace
a single
LISP-CRITIC wide
range
nent
[421,
knowledge
is an
effective expertise,
which
acquires goals
are
also
the
for
to
suitable
many
system
and
of each
explanations
models
system
of user
and
customize
cond
conditional
maintains
individual cover
for
users.
To
incorporates
adequately
a user
information
user.
exactly
the
the
subset
determining
about
LISP-CRITIC
what
support
modeling
uses
user
the
domain
these
needs
to
of rules
to
a
compo-
models know.
fire
to The
for
each
user.
FEA%mR—Extending 40]
is
a design
nents 4).
of window-based
The
using
purpose
FRAMER
design
as well
LISP
user
evaluate
as its
for
program
of issues
active
and
the
lected
checklist
the
frameworks
item
the
the
window
[3!3,
compo-
machines
as
(Figure
designers
either
messages entitled
in
program
in
frame-
correctness
style
used
on
mandatory
or
that
must
constraints
properly. with
for
syntactic
interface
system
dealt
rules
and
classified
are
LISP
is to support
design
the
to function
displays in
of
with is
FRAMER
frameworks,
frameworks.
base
absolute
typically
system
SYMBOLICS
completeness
critic
represent
that
on
environments.
of program
environment
program
consistency
Each
critics
to design
design
design
a knowledge
rules
machines.
Mandatory
kits the
interfaces
FRAMER
abstraction:
contains
The
for
user
of the
a high-level
works.
fied
construction
environment
Optional
critics
another
way.
relevant
to
The the
of the
SYMBOLICS optional. be
satis-
inform
the
critics
are
currently
se-
Things
to take care of. buttons: Explain, Reject,
Each message is accompanied by up to three and The Explain button displays an explanation of the reasons the designer should consider this critic suggestion; it also describes ways to achieve the desired effect. Optional suggestions have a Reject or Unreject button depending on the state of the suggestion. The Execute button accesses which is available for issues that have a the advisory capability of FRAMER, reasonable default solution. employed a passive critiquing strategy. A previous version of FRAMER Experiments [39] showed that users often invoked the critic too late, after a
Execute.
ACM
Transactions
on Information
Systems,
Vol.
19, No. 2, April
1991
(t defm (cmd
(cons(car
sub-search (sub ((null 1) .{1) ((..11 sub) t) (t ( sub-sea~ch
s)
(Seq
LIsP-CRITIC
(
(cond ((equal r 1) (n.pc.r (t (nWJC.n ilP(lanbda
1)
( cd,
---
(equal (.apcar (napcm
~ort, xept zcept Font
-1ock)
pouer.
lisp
(Y)
(..”s
x
y))
(PC?.
(rem.=
x
,)
(aubl
(subl
r))))
r))))
>
and
point
U’(lambda
s))) F
1) U, list s) W‘ ( 1 anbda (napcar 5))
Explanation IF is more
c, (LI.5P
s))
(.)
(nap..? sub
(if
.
U,list
because
Explain Reject All
Set
(x) tl’(lmbda
(Y)
(..”s
x
Y))
(pem
(remove
x
uses
fewer
parentheses
(Why -cond-to-lf-else) readable IF
New
Parameters
has
Code
than
COND
a common
Show
New
Show v
because English
Is
it
meaning,
Code
Original
Code
h)s
Bet,t,etj .: .,.3,,:.
=.kr>rlc
s)
,:, ,.,
, ,,.: .,.,.,,,
..
.
~ L .. . . .. . .
.
... ,. .,,, .. . . .
... . ,..
.. I
)
Fig. 3. The user interface of LISP-CRITIC. The large editor shows the .“ m-omam on which a user is working. The LI~P-CRITIC window on top of it displays a ‘‘ cond-to-if ’ transformation and an explanation of why LISP-CRITIC recommended changing the cond to an if expression.
Framer2 >heck
t Wh at
List
“ml
IIWork Rriwnse the fol
Pmg.-am
. . . .
Invok>ng
th{s
can
Vers}on
the panes as ales{ red Ioui na mouse co..a.ds.
i n your
progra.
f ranewo.k
Ilrrange”e”t Connand
❑
of Imp
Palette flome Left
Get
Middle
R..
{ ze
pane.
Middle
Describe
Right
fle.
u of
.11
Shift-Left
Ed{t
de, ,.,.,
nacro
)
y
❑
B.eto.
~ Sh+Ft-M+ddle
(Connand Qypcs
of
in..t
)
r:”?::’Ings .Rdd -Mow
~ork
Area
Gmerati.m~
I
pane .
pane
Delete
possible
the
.F411 the framuwk.
title
pane
cwerlap
●mpty
space (Rewired)
Button
Operat
Choose
area.
rr.n
im pa. e of this
this
type.
type,
.aDeration=.
ovtic.ns.
pane.
‘-::. :.:.::.’.::. “5.:; ‘-.:::’.,:::::::.::::::: to take care of: a . . . . bar.
TRe. oue the (Rewired)
~ ( Code ——
work
Move
1
function
the
in
Operation
House
pa.,,
shwn
Left
Area
DPOS+Pan
50
do:
to of
.,”::,::
--GEEI
the
top
of
DRTR
and
T IT LE.
{ns{de
the
.?”:,. :.>
the
frame.
-EE3= -
progt-m
-
=
alett.s !i,,, -pa”.
‘,,,-
‘m ,“,.,,..,.,
-,...
~’ ~ m.”.
-,..,
I Fig. 4. FRAMER, This figure shows a screen image of a session with FRAMER. The checklist describes the elements shows the detailed options pertaining of the task of designing a program framework. The What yo u can do window Things to take care of displays the critic messages. The work area is the to a checklist item. The window entitled place were frameworks are assembled in a direct manipulation interaction style. A palette contains title panes, FRAMER also offers a catalog (not display panes, and other primitive parts for constructing program frameworks. shown) for design by rnodiflcation.
132
.
G. Fischer et al
major
incorrect decision had already been made. The newest version of addresses this problem by continuously displaying messages. FRAMER prevents its users from permanently ignoring the critics through its checklist. Each item in the checklist describes one subactivity of designing program frameworks, and the user checks off those subactivities that have been completed. Checklist items cannot be checked off until all critic suggestions associated with a subactivity are either resolved or explicitly rejected. FRAMER
JANus—Integrating environment construct tems:
construction
based
on
residential
the
kitchens
[25,
JANUS-CONSTRUCTION
JANUS-CONSTRUCTION
about
a
JANUS codes,
contains
safety
edge
to signal
displays
is
a
and
breakdowns
messages
5) and
with
integrated
a
set
hypertext
with
to
subsys(Figure
of
critics
system
knowledge
preferences.
to link the
two
a design
designers
6). and
containing
of design.
component
explaining
is
allows
JANUS-ARGUMENTATION kit
functional and
JANUS
that
contains
argumentative
principles
critiquing
standards
JANUS
construction an
general
argumentation. approach
26].
(Figure
is
JANUS-ARGUMENTATION information
and
critiquing
JANUS
construction
nature
of the
about uses
building
this
knowl
to argumentation. breakdowns
in
the
-
JANUS
Messages
window. Clicking with the mouse on a message activates JANUS-ARGUMENTATION in the context that discusses the associated breakdown. In Figure 5, the critic points out that the circumference of the work triangle (i.e., sink, refrigerator and stove) is greater than 23 feet. Designers who are unaware of the work triangle rule do not perceive a breakdown if (Figure that rule is violated. The associated section of JANUS-ARGUMENTATION 6) explains the rationale for this rule including any exceptions. The Catawindow of JANUS-ARGUMENTATION shows an example from the loging Example catalog
illustrating
implemented design
as
a
way
to
satisfy
condition-action
the
rules,
work
which
triangle are
triggered
rule.
Critics whenever
are the
is changed.
situation fits exMomFmR-Making critics user-extensible. No practical actly into a preconceived knowledge framework. Application domains and user requirements are constantly changing. These changing environments require design environments that designers can adapt to fit unanticipated needs. Initial domain knowledge in our design environments is represented in seeds [19]. The seeds consist of objects in the palette, examples in a catalog, critics and argumentation. The evolution of design environments will be severely limited if the domain experts are unable to incorporate new knowledge themselves. But domain experts are in most cases unwilling to acquire detailed knowledge about programming and knowledge engineering—therefore mechanisms supare required [211. End-user modifiability is of porting end-user modifiability crucial importance in design environments for the following reasons: (1) competent practitioners usually know more than they can say; (2) tacit knowledge is triggered by situations and by breakdowns; (3) background assumptions cannot be completely articulated; (4) situations of practice are complex, unique, uncertain, conflicted and unstable; and (5) initial moves ACM
TransactIons
on Information
Systems,
Vol.
19, No. 2, Aprd
1991.
P.4/ette
.4pp//affie
CrWiqua
clear work ha Load [atalcg
Janus-Construction
%4
In
fill C*bd09
kdlt
blobal Select
Uescrlptlons Context
Work .4r0a
wall,
I
I+,
\-
1
L--”u window,
sinks
131m stove,
EHZIEI Messages
Iii’h e length
of
the
work
u
Fig.
(Double-Bowl-Sink-f, Four-El ement-Stov e-l , ) IS greater than 23 feet. ~ is not near Four-E lement-Stove-1 .
triangle
Sln91e-Door-Ref rlaerator-l .Slngl e-Door-Refrigerator-l
l-in 5,
B;ilding
JANUS-CONSTRUCTION: blocks
(design
units)
The work are selected
triangle fro;
critic, the
JANUS-CONSTRUCTION is the construction
Palette
and
Designers can reuse and redesign complete floor plans from messages automatically after each design change that triggers activates JANUS-ARGUMENTATION and displays the argumentation
moved
to desired
locations
inside
part tie
of JANUS. Work
Area.
the Catalog. The Messages pane displays critic a critic. Clicking with the mouse on a message related to that message (see Figure 6).
Janus-Arguments Answer The
(Refrigerator,
distance
should
be
Sink,
between less
sink,
than
23
Ca ta log
tion
Exan@e
Stove)
stove
and
refrigerator,
the
wcfk
triamide,
feet. O.e-Wal
l-Kitchen
~
The
length
of
Refrigerator,
4,d2+d3
10:
the
work is
triangle less
Visited Nodes . Fins.w (Refrigerator,
< 27 feet
Figure
the Sink)
work
(Stove,
than
23
Sink,
feet,
St.”e)
Section
triangle [
Argument
(Walking
Distance)
The work triangle Is an Important work trla”gle denotes the center three
main
appliances:
should
be
less
ensure
an
efficient
Argument In small /iewer:
Defwtt
than
(Small kitchens
sink,
stove
23 feet work
concept In kitchen design. The front distance between the
to
flow
and
refrigerator.
avoid 1“ the
unnecessary
This
length
walldng
and
to
kltchenl
Room] where
the
work
trianale
is
less
than
16
feet.
I
Viewer
~!!! ;ommands b ho. E.a.plc: Shou Ex.PI,D2.
➤1
—.
llg.
6.
this
( Rcfriscrator, (R. frig.r,ator,
JANUS-ARGUMENTATION:
hypertext concept
‘Rnswer R.sue.
system
based
and arguments
answer
generated
Sink, Sink,
Stove) Stov. )
-,.
Katlonale
on the PHI method for and against by the
Show OULI ine Search For Topics Show Argumentation Show ContUXt
“
.
.
.
.
.
.
answer.
The
Resume Show
sh.w%%%%%e
.
for the work triangle rule. JANUS-ARGUMENTATION [431. The Viewer pane shows a diagram illustrating
the work
ARGUMENTATION
triangle
ILLUSTRATOR.
The
top right
Visited
Nodes
pane pane
Construction Construction
shows lists
m an argumentative the
work
an example in sequential
triangle
illustrating order
the
previously visited argumentation topics. By clicking with the mouse on one of these items, or on any bold or italicized item in the argumentation text itself, the user can navigate to related issues, answers, and arguments. features are inherited from the SYMBOLICS DOCUMENT EXAMINER. Hypertext access and navigation
The Role of Critiquing in Cooperative Problem Solving
.
135
must be reframed, as the changed situation most often deviates from the initial appreciation. The breakdowns are not experienced by the knowledge engineers, but by the domain experts using the system. In order to support evolution on a continual basis, the people experiencing the breakdowns are in the best position to do something about it. End-user modifiability is not a luxury but a necessity in cases where systems do not fit a task, a style of working or a personal sense of aesthetics. MODIFIER that
(Figure
support
ances
the
(e.g.,
“the
definitions
2.4
Making
kits
JANUS
using
the
without
ment
are
and,
“if
back
talk”
down But
skill
and
work
triangle
(see
Figures
trigger many
JANUS mal
solutions
relevant
2.5
use
ACTIVIST
integrated JANUS,
they
work
to form often
will
not
6).
Critics
early
that
knowledge constructed in
in Integrated
and LISP-CRITIC with a larger FRAMER,
and
in
in
appreciations
enhance
make
design
As
and
phase
repair designer,
to and
representadesigner
has
that of the
the
(2) provide
rule
arti
is
violated they
has
made
as those
critique
access
-
of the
situation,
such
and
the
unaware
designer
Critics
detect
while
before are
if talk
expensive.
principles
the
of
perceive
understandings
who
before
production
passive
breakdowns
back
a breakaction.
designers
unless
a breakdown the
when
the
create,
situation’s
to continue
back
designers
argumentative
Design
apparent
to
experi-
they
on the
help
but
support
consequences.
situations
lead
experience
experience
the
the
constructing.
new
kits
and
do not
talk
when
quickly,
Designers
become
do not
example,
by the
paths
in
subopti to the
space.
Environments
operate
design with
are
problemDesigners
accomplishment
is unable
area
of design the
in
kits
human blocks.
Construction
themselves
do not For
rule
information
Critics
composite
something
reflect-in-action
designer
artifact
commitments
(1)
not
of
implications
meanings the
Construction
5 and
breakdowns
will
do
use.
sense
meanings they
49].
in
support
to construct
their
kits
Designers put
(e. g.,
(3) adding
creating
reflection-in-action.
[22,
in the
a
discover
is, when
knowledge
is actually
(4)
appli-
rules
system,
building
of computers.
unexpected
of an
constructions
JANUS)
them
unexpected
that
and
[561 calls
and
designers,
These
artifacts
constructing.
too
find
good
shortcomings
tions,
fact
Schoen
shapes
construction
interesting
and
new
critic
with Critics
experienced
knowledge
[65],
new
to the
domain-oriented
detailed
to
[571.
with
it enabled
are
occurs
“between”)
Back”
they
that
likely they
(e.g.,
components
introducing
(2) adding
refrigerator”)
because
various
palette,
as FRAMER [22]
that
process
with
They
the
said
needing
a design
the
“Talk
(such
system
(1)
center”).
communication
using
knowledge-based
to the
relationships
the Situation
Construction domain
the
be next
a “cleanup
with
of modifications:
into
should
of new (e. g.,
JANUS
types
a “microwave”)
microwave
objects
7) [211 extends following
in a stand-alone mode and are not tightly environment. We have demonstrated with
Schoen’s
theory
ACM ‘h-ansact,ons on Information
of
reflection-in-action Systems, Vol. 19, No. 2, April
that 1991
-
Clear Work Area Load Catalog
danus-Construction lpp/iaffie
Palette
Edit
Critique All Saue In Catalog
Global Select
Descriptions Context.
Area
W&
walls Help
for
You
New
are
be, na
Class
ED
asked
to
enter
sw
Class
Iwe...
f.
the
p.lett.:
‘f.,
M.
t.tii”g
set
of
de,
am
the
possible
design
,gn
“
