iNTERFACE SYSTEMS

I •I II

II

I,

Q,A'IIf'IUllII'd lR~ie''iI,AN' University of Colorado at Boulder

Software engineering is a design activity.Most design problems are ill-structured1

andelimination, considered the

spent the lastknowledge-based systems, lmnr,",""'"

human-eomputer interaction, anding the nature of design processes, my col­

and I are convinced that currentIme-CVClle models of software englrleennlgare inadequate for most of today's comput­ing problems. I They are inadequate be­cause they rest on the assumption that prob­lem requirements can be stated precisely atthe beginning of a project and that com­plete specifications and an Impl(~mentation

can be derived from them through formal

good software for human­computer interaction is a majorchalllen:ge. This very new field is

Powerfulbitm"lp(led screens and

devices the new techno-logical base. Innovative applications havedrawn attention to the interac-tive, rather than capabili-ties. The of today's software hasmade better communication techniques a

not aGood HeI is important for the products

that the software designs and im­plements for users, but it is equally impor­tant for software themselves.

to design, understand, and main­tain cornplex artifacL<; that are opaque andvery difficult to deal with. Software engi­neers and programmers have a stake in im-proving environments.

44 0704-7459/R9/OOO1/0044/$OI.OO © 19X9 iEEE IEEE Software

\

Explicit channel. Large bitmappedscreens with windows, menus, pointingdevices, and speech outputand input havewidened the explicit channel between theuser and computer dramatically. Thesetechnologies are necessary but by nomeans guarantee good HCI.

Exploiting these technologies to benefitthe user requires a deeper understandingof psychological principles - for ex­ample, the difference between recall andrecognition memory, by which menu sys-

1. Architecture for knowledge­based human-computer interaction.

.::t _

Explicitcommunication

channel

Knowledge about:• problem domain• communication processes• communication partner• problems of the user

and tutorial intervention

Knowledge-based fad Ii ties haveelaborate, interactive graphical interfacessupported by specialized viewers and in­formation-management systems.

To support these systems, we have devel­oped a model, illustrated in Figure I. Oursystem architecture reflects two major de­partures from traditional approaches:The use ofwindows, menus, and pointingdevices widens the explicit communi­cation channel, and shared knowledge es­tablishes an implicit communicationchannel.

Kno,ud.:lWrld,

Our research has three dimensions:theory development, engineering con­struction, and empirical studies. The goalof theory development is to understandhow human cognition and design capa­bilities result from an interplay betweenmental processes and external computa­tional and memory aids. The purpose ofengineering construction is to design anddevelop the desired artifacts. The empiri­cal research examines how people per­form tasks using the artifacts in a naturalsetting.

The primary application ofour researchhas been the creation ofknowledge-basedHCI software to run on high-functionalitysystems in support ofcooperative problemsolving.

• Humans are moving targets, not staticobjects. They start as novices and may re­main in this class, but they may also be­come casual or expert users.

HCI software design must start with thehuman as a fix point. Humans do not havethree hands, and our designs must takethis into account- users cannot keep twohands on a keyboard and one on a mouse.HCI software should acknowledge humanweaknesses (limited short-term memoryand execution errors) and exploit humanstrengths (a powerful information-pro­cessing and visual system).

Architecture. Effective HeI is more thancreating attractive displays: You must givethe computer a considerable body ofknowledge about the world, users, andcommunication processes.

However, the use of knowledge-basedsystems today is limited severely by thecommunication bottleneck in the narrowchannel between the user and the system.A good user interface is vital to i knowl­edge-based system, but it has little use ifitssophisticated graphical facilities lack rich,supporting information structures.

all scientific activity by the philosopherKarl Popper.3 This is especially true forHCI software: There are no complete HCItheories. The problem is ill-structured,and so many of the methods and tools de­veloped for traditional software-engi­neering problems are of little use for HCIsoftware.

Ill-structured problems are also charac­terized by design instabilities and the needfor frequent redesign. The main goal ofHCI software is not to develop a correctimplementation of given specificationsbut to develop an effective solution thatcorresponds to real needs. Specificationcorrectness in this context is not a mean­ingful concept because it implies a precisespecification of intent, which is seldomavailable.

Unless we match our paradigms andmethods to ill-structured problems, theimplementation disasters of the I960s willbe succeeded by the design disasters oftheI980s. We need effective exploratory pro­gramming environments and rapid-proto­typing tools that support iterative, evolu­tionary design.

The best paradigm for creating HCI soft­ware is a communication model I and arapid-prototyping approach that supportsthe coevolution of specification and im­plementation.4 Communication betweencustomers, designers, and implementersand between humans and the knowledgebase that describes the emerging productis crucial.

Our work at the University of Coloradoat Boulder centers on knowledge-basedsystems that enhance and support com­munication. When we write HCI software,we define what the computer will do andwhat humans will and can do. We alsomake assumptions aboutwhat they wan t todo. It is this human element that distin­guishes HCI software:

• Humans are individuals with differenttalents, goals, knowledge, andences.

January 1989 45

terns should be evaluated. We must alsotake into account the nature of differenttasks and the user's abilities.

The design space of the explicit channelis huge, largely unstructured, poorly un­derstood, and inadequately supported bytools. It should therefore come as no sur­prise that even with improved technicalcapabilities many HCI systems are stillmodeled on teletype interaction.

Implicit channel. When communicationis based on shared knowledge structures, itis not necessary to exchange all informa­tion between the user and system expli­citly. Figure 1 lists four knowledgedomains necessary for implicit communi­cation:

1. Problem domain. Intelligent be­havior builds on large amoun ts of knowl­edge about specific domains. This knowl­edge constrains the number of possibleactions and describes reasonable goalsand operations. We can infer the user'sgoals and intentions if we understand thecorrespondence between the system'sprimitive operations and the concepts ofthe task domain. If the computer has amodel of the problem domain's abstrac­tions, communication between thehuman and the problem domain isfeasible.

2. Communication processes. The in­formation structures that control commu­nication should be made explicit so theuser can manipulate them. Safe, explora­tory environments should be supported(for example, with undos, redos, and his­tory lists). User and computer shouldcommunicate by writing on a shared dis­play or by referring to something alreadyon the display. This interreferential, I/Omodel (for example, as supported by theSymbolics presentation system) supportsdialogue rather than issuing isolated mes­sages.

3. Communication partner. The user ofa system does not exist; there are manykinds of users, and an individual's require­ments change with experience. Adaptivesystems change their behavior accordingto the needs of different users. Unless thesystem has a model of the user, it is im­possible for it to relate descriptions of newsystems to the existing knowledge of in­dividual users.

46

4. Common problems and in­structional strategies. If the system is to bea good coach or teacher and notjust an ex­pert, it must incorporate instructionalstrategies based on pedagogical theoriesand exploit the knowledge contained in itsmodel of the user. For the same reason, anintelligent support system should knowwhen to interrupt a user.

Object-oriented architectures. Our sys­tems use an object-oriented architecture,which has been shown to be well-suited tointerface construction. In this model, theuser communicates with the system, whichis represented on the screen as a worldcomposed of active objects. Each screenobject has its visual representation (whichdefines its appearance and its relation toother screen objects) and a functional role(which governs its behavior).

The principles ofobject-oriented design- inheritance, flexibility, extensibility,and modularity - support new program-

TIle principle ofhuman problem-domain

communication abstractsthe domain's operationsand objects and builds

them into the computingenvironment.

ming methodologies that encourage de­signing for reusability and redesign, suchas differential programming and pro­gramming by specialization and analogy.Object-oriented architectures providesubstantial support for interface design.

Domain communication. Most users areexperts in some problem domain,whether it be physics or music. The com­puter is a generalist; its generality means itcan support all knowledge workers. Butdomain experts '!ore not interested inlearning the computer's languages; theysimply want to use it to solve problems andaccomplish tasks.

To shape the computer into a truly use­ful medium, we have to make it invisibleand let users work directly on their prob-

lems and their tasks. To do this we must"teach" the computer the experts' lan­guages by endowing it with the abstrac­tions of different application domains.

The principle of human problem-domaincommunicati~ abstracts the importantoperations and objects of a domain andbuilds them into the computing environ­ment. This lets the user operate with per­sonally meaningful abstractions. It is im­portant not to lose the semantics of thedomain by reducing it to oversimplifieddata structures.

WLisp, our user-interface toolkit,6 andtwo systems called Framer and Crack sup­port human problem-domain communi­cation in the areas ofinterface and kitchendesign. People can use these systems to doprogramming by constructing artifacts inthe domain instead ofwriting statementsin a programming language. Our experi­ments have shown that people who usethese environments had a sense ofaccom­plishment because they created their ownimpressive version of something thatworks but was not difficult to build.

Framer and Crack, described in the boxon pp. 48-49 are design environments(with embedded construction kits): Theyprovide a set ofbuilding blocks that modela problem domain. The building blocksdefine a design space (the set ofall designsthat can be created by combining theseblocks) and a design vocabulary. Theadvantage of design environments is thatthey eliminate several prerequisite skills,thus letting users spend much more timeworking in their area ofinterest.

The disadvantage is that these design en­vironments are effective in only one area.But this limitation affects all knowledge­based systems, and human expertise is alsorestricted to specific domains. The chal­lenge for c()1!1p:uter systems is to createthese design spaces for many domains andto organize this huge set so users can findthe abstractions they need.

Reuse and redesign. Software environ­ments must support design method­ologies whose main activity is not only thegeneration of new programs but also themaintenance, integration, modification,and explanation of existing ones.

A construction kit with many generalbuilding blocks supports reuse and rede-

IEEE Software

sign by providing stable abstractions. Theuser-interface tools of Smalltalk, the Lispmachines, and WLisp have undergone along evolutionary development. They arebased on abstractions about the domain ofinterface design and constitute atheory of one class of user interfaces.evolutionary development of suchtheory, driven by tests of the abstractions'validity in several applications, is a prereq­uisite for the development ofa system thatsupports reuse and redesign.

However, standard programming lan­guages offer only a few primitives for HCI(read, write, and format). These primi­tives are conceptually based on a linearstream, not a two-dimensional screen. So itis a huge effort to build the HCI part of anapplication because the designer has tobuild itfrom low-level components.

On the other hand, functionally rich en­vironments offer hundreds and thou­sands of abstractions,6 substrates for HCI(different classes of windows, support forinterreferential I/O), and screen-layouttools. Such systems reduce the size of theapplication system substantially. Themajor cost of such systems is that the de­signer must learn and understand the ab­stractions, but this cost is incurred onlyonce per designer.

Intelligent support systems. High-func­tionality systems are not without prob­lems, however. Our informal empiricalstudies have shown that:

• Users do not know that tools exist. It isvery difficult for a novice or casual user tobuild a mental model of the capabilities ofa high-functionality system. Without sucha model, users are unaware of tools thatmight be relevant to their tasks. A passivehelp system is no help in this, because toask a question the user must know enoughto know what is not known! Active help sys­tems, critics, and browsing tools6let usersexplore a system and point out useful in­formation.

• Users do not know how to access tools.Knowing that something exists does notguarantee that you know how to find it.

• Users do not know when to use tools.vVhile each system feature may have a sen­sible design rationale from the systemengineer's viewpoint, this rationale is fre­quently beyond the user's grasp. Users do

January 1989

not understand which commands arebasic and which are advanced, nor do theyunderstand that the options representdifferent, generalized interaction styles.

• Users do not understand the resultsthat tools produce. Visualization tools andexplanation components address thisproblem.

• Users cannot combine, adapt, andmodify tools according to their needs.Even after all the other problems are over­come, in many cases the tool does not doexactly what the user wants. The user

\ needs system support to carry out con­strained design processes at the user's

. operational level.We have constructed design environ­

ments5•6 to support the modification andconstruction of new systems from sets ofpredefined components. In contrast tosimple construction kits, our design en­vironments incorporate knowledge aboutwhich components fit together and howthey do so, and they supply critics that rec-

The success ofnewcompute, systems Is

judged less 011 processingspeedand memory sizeandmore on the qualityof tllei,communication

capabilites.

ognize errors and inefficient or uselessstructures. Our environments can dealwith multiple representations of the de­sign.

Lessons learnedThe success of new computer systems

(the Macintosh may be the best example)isjudged less and less on processing speedand memory size and more and more onthe quality ofcommunication capabilities.We have learned that, to be successful,HCI software must:

• Take advantage of technology. Mod­ern workstations provide new technologi­cal possibilities. Yet many current user in­terfaces are stilt teletype-oriented. Itrequires a design and imple­mentation effort to reconceptualize all

software to take advantage of the newpossibilities.

• Use user-interface construction kits.User-interface management systems? pro­vide graphical primitives and tools tospecify dialogue structures, but they limitinformation exchange and separate theuser interface from the application. This isa reasonable approach for some prob­lems. However, for the kinds of problemswe try to solve, such as intelligent supportfor human problem.:ctomain communi­cation, a strong separation between inter­face and application is not feasible. Inthese systems, the user interface must haveextensive access to the state and actions ofthe application system. For problems ofthis kind, user-interface construction kitsare more appropriate.

User-interface construction kits can pro­vide powerful environments for rapid pro­totyping ofa large class of interfaces. Theyprovide many building blocks for con­structing high-quality interfaces at a rela­tively low cost, and object-oriented archi­tectures can supply uniformity,extensibility, and incremental develop­ment.

User-interface construction kits comeclose (within their scope) to our notion ofhuman problem-domain communi­cation. Users familiar with· problemdomains but inexperienced with comput­ers have few problems using these systems,while computer experts unfamiliar withthe problem domains could not exploittheir power.

The major shortcoming of large con­struction kits is that they do not help thedesigner construct interesting and usefulartifacts in the application domain. InCrack, for example, it is not enough toprovide design units - kitchen design ismore than placing appliances. Design en­vironments and critics are needed to helpusers construct truly interesting artifacts;they surpass construction kits in that theyincorporate useful, general knowledgeabout design.

• Provide exploratory environments.Users do not know what they want, and de­signers do not understand what usersneed or will accept. The only viablestrategy for HCI software is incremental,evolutionary development. Initial systemsmust be built to give users something con-

47

Framer and CrackFramer and Crack are design environments. Framer supports the

construction of window-based user interfaces and Crack supportscooperative kitchen design. Both systems incorporate and illustrate theresearch issues outlined in this article.

The basic building blocks are application-dependent abstractionsthat support human problem-domain communication. Framer andCrack incorporate intelligent support systems and offerdifferentdesignstrategies such as design with basic building blocks and redesign ofprototypical examples.

Framer. Figure A shows a screen from Framer, an enhanced ver­sion of the Symbolics Frame-Up tool. Framer offers the user a paletteof domain-oriented building blocks, and supports direct-manipulationinteraction in the work area. This visual interaction style is especiallyappropriate in a domain in which visual objects are designed fromvisual parts.

In addition to serving as an application-oriented construction k~,

Framer has a small rule base with design knowledge about relevantaspects of window-based user interfaces. The Praise command tells auser the positive aspects of adesign; the Suggest Improvementscom­mand criticizes the design; the Explain option gives some rationale forthe suggested improvement.

Framer includes acatalog, which contains several prototypical de­signs that can be praised and critiqued. When brought into the workarea, the user can modify them and use them as astarting point for re­design. Prototypical solutions that can be changed and refined throughredesign are important enrichments fordesigners and enlarge their de-.sign possibil~ies. Users can store their designs in the catalog.

Without Framer, the user would have to write the program in FigureBto generate the screen layout in Figure A. Framergenerates this codeautomatically. An experienced user can then modify the code.

Crack. Critics are another type of intelligent support system. Criticslet users pursue their own goals, intervening only if they discover thesolution is, according to their knowledge, inferior.

Empirical observations indicatethat usersareoften unwilling to leammore about asystem than they need to solve their current problem. Tocope w~h new problems as they arise, a critic must generate advicethat is tailored to the user's needs and the currer.tt s~uation. This re­moves from users the burden of having to learn new things in neutralsettings when they do not know if they will ever use them.

Figure C shows a screen from Crack,1 a cr~ic system that helpsusers design Mchens. Similar to Framer. it provides a set of domain­specific building blocks and has knowledge about how to combinethem into useful designs. It "looks over the shoulder" of users as theydesign. If ~ discovers a shortcoming in the design, it offers criticism,suggestions, and explanations and helps users improve the designsthrough cooperative problem solving. Crack's objective is to blend thedesignerand the computer into aproblem-solving team toprodUce bet­ter designs than either of them could working alone.

User control. Critics in Crack are state-driven condition-action rulesthat are triggered when nonsatisfying partial designs are detected.These rules are activated after each state change. State changes areall instance creations of design units and of any design-unit manipula­tion (like move, rotate, and scale). An unsatisfactory solution is an ar­rangement of design units that violates one or more of the relationsbetween them.

Crack is not an expert system that dominates the design process bygenerating new designs from high-level goals or resolving design con­flicts automatically. Userscontrol the system's behaviorat all times andcan modify its knowledge base if they disagree with the criticism.

Crack lets the user control the firing of critics at three levels: All cri­tiquing can be turned on or off. individual critics can be enabled or dis­abled, and specific relations in acritic can be modified. When critiquingis turned off (the default), Crack acts like aconstruction k~ with no de­sign knowledge. When cr~iquing is enabled, all critics are active. An in­dividual cr~ic can be disabled if a user does not like its criticism or if itsknowledge has been assimilated and is no longer needed. At thelowest level, the different relational tests within acritic can be replaced.

Palette

I:]IlllM

or......

Work Area

Framer

,... .. .. ,. · ... r

"""""""""""'r

48

Catalog Add To CetaloQ Dent! Preis.

ra~=:ii••iliiililiiliili.~,1 CI .... DieloQ Window H.lp Sho", Cod<CI.e' 1410'"" Aru Install O.finition SUQ~ul Imp,ov.m"nls

tM"I,.AY·,\ ~ C)tI'I.AY·C

F"'Met' COf'Wll..nd: Pr.1 •• FRAI'1£-6There 10 I U.tenel or inleraclor pane,The pane. do nol overlip.Ther. I. no emply .pace in lhe frame.

FroMer cOrw'lench SVS9.U't. It'lprove ....ent.. FRRI"lE-6Add I menu bar. eft.- ..... wnrHBNV-l.u)Remov. all bUI one of lhe dialol pane. (. Ii.lenar 01 in\;lrlclor pane.). (_ ....

ONLYooONI-OULOO ..PI.WI)

Add I tiUe pane. 1- ......n:D-Tm..-......)Ff'M.,.. co"".nd:

~.,' , , ,'., ,

······""..··,,·····,,······D

FI..,. A-. Ascreen from Framer, adesign environment for window-based interfaces.

lEEESoftware

For example, if a user doesn't want to have the sink in front of a win­dow, the in-front-of relation can be replaced with another relation, suchas no-relation or close-to.

Appropriate applications. The critiquing approach is best suited forill-defined problem areas where the goal is to satisfy, rather than op­timize, asolution. Kitchen design (as an area of architectural design) isstill an ill-defined problem despite the existence of some well-estab­lished design principles. Architects do not try to find optimal solutionsto design problems but rather make trade-ofts within a solution spacethat is bounded by external constraints.

Critics can be classified as:• Active or passive. Critics can activate themselveswhen theydetect

an unsatisfactory design or they can be passive and wait until the userasks for an evaluation. Active criticism early in the design makes usersaware of their unsatisfactory design when the mistake is easier to cor­rect. But users may find it a nuisance to have someone continuouslycritique them without giving them a chance to develop their own work.A passive critic lets the user request an evaluation when they havecompleted a partial design. Active critics seem to be suited for guidingnovice users; passive critics seem to be more appropriate for interme­diate users.

• Reactive orproactive. Crack's critics are reactive: They make com­ments about what the user has done. Aproactive critic plays the role ofan adviser by suggestingwhat the user might do or proposing criteriawhich the user should consider. For example, aproactivecritic in Crackcould highlight the area where a new design unit could be located in apartially completed design.

• Positive or negative. Critics can either praise a superior design orcomplain about an inferior design. Critics in Crack are negative: Theycomplain only about unsatisfactory configurations and do not praiseespecially useful or interesting configurations. Human critics are bothpositive and negative.

• Local or global. A critic's granularity determines whether it isoriented toward local aspects of a partial design or global aspects ofthe total design. Asink critic is a local critic because it is concemed witha low-level design unit: a sink. Awork-triangle critic (the work triangle is

(DW:DEFINE-PROGRAM-FRAMEWORK EXAMPLE-1:COMMAND-DEFINER T:COMMAND-TABLE(:INHERIT-FROM '("colon full command" "standard arguments"

"input editor compatibility"):KBD-ACCELERATOR-P 'NIL)

:STATE-VARIABLES NIL

:PANES((PANE-1 :DISPLAY(PANE-5 :DISPLAY)(PANE-4 :DISPLAY)(TITLE :TITLE HEIGHT-IN-L1NES 1:REDISPLAY-AFTER-COMMANDS NIL)

(Imenu bart :COMMAND-MENU MENU-LEVEL:TOP-LEVEL)

(PANE-3 :DISPLAY))

:CONFIGURATIONS'( (DW:MAIN

(:LAYOUT (DW::MAIN :COLUMN ROW-1 TITLE[menu barl PANE-3)

(ROW-1 :ROW PANE-1 PANE-5 PANE-4))(:SIZES(DW::MAIN (TITLE 1 :L1NES)

(Imenu barl :ASK-WINDOW SELF:SIZE-FOR-PANE Irnenu barD

:THEN (ROW-1 :EVEN )(PANE-3 :EVEN))(ROW-1 (PANE-1 :EVEN) (PANE-5 :EVEN) (PANE-4 :EVEN))))))

FI..,. B. The Usp program for the screen layout in Figure A.

the center-front distance between the sink, range, and refrigerator) isa more global critic because it is concerned with a larger portion of thedesign: several appliances. A kitchen critic is a global critic: It is con­cemed with the look of the entire kitchen.

Reference1. G. Fischer and A. Morch, "Crack: ACritiquing Approach to Cooperative

Kitchen Design t" Proc. Int'I Cont. Intelligent Tutoring Systems, ACM, NewYork, 1988, pp.176-185.

p D rFfFilI.!::::::!...!: L

B !IF~ rLIJ td).-.-

~ []~

S [§)

DrawDirectlon

we!),Os 0

DU palette

Scale: 1/4" • 1'-0"

tN

i,i'l,iWH'Ui,twm_i,IHi&W'.l22U''',1c -IHi;!·!-

Actual LMgth

75inch••

De81gn State

west-wa.ll·lnorth-wall· Ie..,t~wI11 .. 1JOu\h-wtl)·1door-troom· 1Wtndow·lplumblnl-lplumbinc·2equipment-arM·llink·1

SUGGESTION

]

'ink should be INSIDE equfpftent-.reasink should be lESS-THAN 24 tn. fro" plu"bfng

'?fY'Zt!I~leeHq"}t'b'!lf~twt~*er .J51 nk shou I d be HERR a ,.angesink should MOT be NEXT-TO the range

.. 'ink should be HERR. refriee,..t.o,.

Critique CRITIC WINDOW

CriUUl 'tiI.\e; ch6nce : SlNK-<:JUTIC l.tluereQ.

SlNK·l not. lnsiOe equipment-afurtNK-l nM 10£$ than 24 in. trom pJuw.binCSINK· 1 not. in t'toM ot .. window,

RU: beep

Flgur. C. Ascreen from Crack, a critic system for kitchen design.

January 198949

crete to react to. This strategy must be sup­ported by exploratory programming sys­tems that support the coevolution ofspeci­fications and implementations.

Prototypes replace anticipation (howwill the system behave?) with analysis (howdoes it actually behave?), which is muchC4;1.sier to work with. Most major computingsystems have been developed with exten­sive feedback from their actual use. In thisway improvements are made in responseto discrepancies between a system's actualand desired states.

We know that writers with access to edi­tors and formatting tools are increasinglywilling to modify their work. Intelligentsupport tools in exploratory program­ming environments will lower the cost ofmaking changes, so designers will alsostart to experiment- thereby gaining ex­perience and insight leading to better de­signs.

Exploratory environments also supportreuse and redesign. But anyone whothinks that reuse and redesign comes forfree is wrong. If reuse and redesign aregreat ideas and if they are easy to master,why have they had limited success so far insoftware development? Observation ofde­signers dealing with complex software sys­tems has revealed one reason: Thesemethodologies are not adequately sup­ported. It is too expensive to change a sys­tem or explore design alternatives in mostsoftware production em~ronments.

• Use prototypes. Static specificationlanguages have little use in HeI softwaredesign. First, detailed specifications do notexist. Second, the interaction between asystem and its user is highly dynamic andaesthetic, aspect,; that are difficult, if notimpossible, to describe with a static lan­guage. Successful HCI systems should letusers play with the prototype systems anddiscuss their design rationale. A prototypemakes it much easier and productive fordesigners and users to cooperate becauseusers do not have to rely on written specifi­cations, which do not indicate an inter­face's qualities.

• Promote natural communication. Nat­ural communication is more than the abil­ity to communicate in natural language; itis the ability to engage in a dialoguf. Whenhuman nO\~cescommunicatewithhumanexperts, much more goes on thanjust a re-

50

quest for factual information. Novicesmay not be able to articulate their ques­tions without the experts' help; the ex­perts' advice may not be understood with­out further explanation; each mayhypothesize that the other misunder­stood; experts may provide informationthey were not explicitly asked for.

Natural communication needs a properuser interface to support it, but it is not re­stricted to the user interface. The underly­ing knowledge base must contain theneeded knowledge, and it must be struc­tured correctly.

• Help the user make intelligent choices.Communication can be described interms of the speaker and the listener roles.The speaker presents information, per­haps in the form of a question or as a re­quest for action, which the listener tries tounderstand. In general, the listener must

Concem for the humanmust equal concem forthe computer. A theory

ofhum.. cognitiveprocesses should drivethe new communication

developments.

be the more intelligent agent because hemust not only understand a situation assuch but also understand how the speakerpresents it.

In HCI, the user is the more intelligentagent. Therefore, gi\~ng the user the ap­propriate cues is the essence of most HCIdesigns: The context provided by win­dows, menus, spreadsheets, propertysheets, and form systems lets the userchoose the appropriate next step.

Because humans and computers are notalike, designing HCI software is a problemnot only of simulating human-to-humancommunication but of engineering alter­natives in the domain of interaction-re­lated properties. Humans do not have amenu on their forehead of the commandsthey can execute in a certain context.

• Extend the design knowledge base.Why hasn't someone like Donald Knuthwritten a oook with prescriptions for build-

ing good HeI software? Because the basisof such a oook has yet to be created bycognitive science. We have to extend theexisting knowledge base for HCI. Card,Moran, and Newell8 have provided somemethodologies and principles for the de­sign ofsystems that support routine cogni­tive skills whose time spans fall within sec­onds. But these quantitative designmethods are not relevant to complex sys­tems, which may take months and years tolearn and understand.

An interdisciplinaryapproach is neededto increase our HCr knowledge base. Con­cern for the human must equal concernfor the computer. A theory of humancognitive processes should drive the devel­opment of new communication capabili­ties. We need design principles for com­prehensible systems that are not restrictedto the evaluation and assessment of ex­isting HCr systems. If humans are the fixpoint of future HCI systems, the designsmust be based on cognitive principlesright from the beginning.

Challenges aheadUser-centered designs, comprehensible

systems, intelligent support systems, andpowerful tools to augment human intel­ligence are the main goals of HCI design.The software design community has ac­cepted these goals as relevant, and con­siderable progress has been made over thelast few years. But big challenges lie ahead:

• Focus on innovation. Part of our re­search effort should be directed towarddemonstrating which current systems aregood or bad because this gives us insightinto the design criteria for future systems.But the main challenge lies in developingnew, innovative systems.

Restricting our effort to evolutionaryimprovement of current systems ignoresthe history of HCI over the last decades,during which Hcr has made revolutionarysteps forward. If the cost of developingHCI software is to be reduced, more com­puter support must be supplied to the de­velopment process. Current developmentoccurs not in the computer but in people'sheads; it is not documented and thereforecannot be analyzed.

• Perform real evaluations. If the pri­mary approach to HCI is incremental andevolutionary, evaluation of existing sys-

IEEE Software

terns is an important activity. The chal­lenge here is not to restrict our evaluationsto laboratory experiments but to test realusers doing real tasks in real settings. Ulti­mate criteria are usefulness and usabilityfor real-world purposes and thereforemust be tested in the real world. Validationand verification methods from other soft­ware domains have limi ted use in HeI.Formal correctness is crucial, but itis by nomeans a sufficient measure of the effec­tiveness and success of an Hel system.

• Accept change. We have to accept theempirical truth that for many systems re­quirements cannot be stated fully in ad­vance. 2 In many cases, they cannot even bestated in principle because neither design­ers nor users know them in advance. Thedevelopment process itself changes thedesigners' and users' perceptions of whatis possible and increases their insight.... Wehave to accept changing requirements as afact of life and not condemn them as aproduct of sloppy thinking. We needmethodologies and tools that support andcoordinate the process of change.

• Tailor software. One crucial shortcom­ings of computers is that they don't sup­port the notion ofaccomplishing a task orpurpose that the user chooses. To do sowould require software that is truly soft,which means that the beha\;or of a systemcan be changed \\;thout major reprogram­ming and without specialist.... This require­ment is critical because predesigned svs­tems are too rigid for problems whosenature and specifications change andevohe,

Thisgoal does not impl\'transferring theresponsibility ofgood system design to theuser. It is probably safe to assume that nor­mal users will ne\'er build tools of the qual­itya professional designer can achieve. Buta question for future research is: Shouldwe design the HCI part of a system com­pletelv or should \\'e develop metasvstemsthat let users alter the HCI according totheir needs~Should systems be adaptive­should they change their beha\'ior basedon a model of the user and the task (theidea behind our cri tic systems) - orshould systems be adaptable by the user(as they must be to support reuse and rede­sign)~

• Prm'ide a \\indow into the knowledgebase. It is insufficient for intelligent sup-

January 1989

pon systems tojust solve a problem or pro­vide information. The user must be able tounderstand and question their criticism.We assume that users will not ask a pro­gram for advice if its expertise cannot beexamined. Designers must pro\ide win­dows into the knowledge base and reason­ing processes of these systemsata level thata user can understand, The users shouldbe able to query the computer for sugges­tions and explanations, and they shouldbe able to modify and augment the critic'sknowledge.

An evaluation of Crack demonstratesthe relevance of this approach. Crack wasused by an architectural designer who con­sidered the cooperative, user-dominatedapproach to be its most important feature.He felt that this feature set Crack apartfrom expert-system design tools that oftenreduce users to spectators, In the current

We have to acceptchangingrequirementsas a fact of life andnot

condemn them as aproduct ofsloppy

thinking. Tools shouldsupport change.

version of Crack, we have deliberatelya\Oided equipping the system with it... owndesign capabilitjes, \t\1w? Because users in­crease their knowledge and indepen­dence bv working with systems that do notdo the work for them but that enable themto do it themselves, Too much assistanceand too mam automatic procedures canreduce users' motivation.

• Improve cooperative problem-solvingsystems. Current intelligent support sys­tems like Framer and Crack are one-shotaffairs. Thev give ad\ice, but that achice isnot a startjng point for cooperative prob­lem sohing, Human advisory dialogues'}are judged successful when the\' allowshared control of the dialogue, Our sys­tems should be designed to manage errorsand trouble. No system can be designed tobe totally foolproof. The problem in HCIis not simplv that difficulties in communi­cating arise that do not occur in human-to-

human communication but that, whenthe inevitable troubles do arise, the sameresources are not available for their detec­tion and repair. Errors should not cause abreakdown of the interaction; they shouldbe regarded as an integral part of theprocess of accomplishing a task. The goalof a cooperative endeavor is not to findfault or to assess blame but to get the taskdone.

• Recognize design conflicL". As is truefor most real-world design tasks, there isno optimal solution for HCI, only trade­offs. A challenge for the future is to resolvethese design conflicts. In our research ef­forts, we \\ill concentrate on the followingtrade-offs:

• How do we balance the effort and thelarge training costs necessary for learninga complex interface with the power of ex­tensive functionality? It is important thatwe explore techniques that reduce thecognitive costs (such as learning ondemand and human-problem communi­cation) ,

• How do we make computer systemsuseful and usable at the same time? Usefulcomputers must be complex and have richfunctionality because they must model theabstractions of many domains, but it ishard to make complex systems usable. In­telligent support systems promise to par­tially resolve this design conflict.

• How do we achieve high speed andconvenience of use (power) for the expe­rienced user and at the same time achie\(:>ease oflearning and usc for the nO\;ce andthe casual user? Adaptive and adaptablesystems will more closelY accommodatethe needs of the indi\;dual user,

• How do we separate dialogue manage­ment from the application (to enhance re­usability and unil<mllity) and yet retainapplication-specific semantics? L'ser-inter­face toolkits, UIMSs, and human problem­domain communication provide differ­ent answers to this question.

• How do we ensure the quality of HCIsoftware and minimize the costs of its de­velopment? Reuse and redesign will be anabsolute necessity for dealing with this de­sign conflict.

• How do we fit new systems comfortablvinto people's lives and at the same timedramaticallv change the way they live andwork? Incremental learning needs to be

51

Address questions to Fischer at Computer Science Dept., L'niYersit\ of Colorado, Campus I)ox430, Boulder, CO H0309: CSnet gerhard@;boulder.colorado.edu

enhanced to expose users to systems thathave a low threshold (it is easy to getstarted) and a high ceiling (the limitationsof the systems do not show up immedi-ately). .

New. formalisms and new tools havehelped us augment human intel­ligence. Computers used in the

right way are a unique opportunity to takeanother big step forward, createcooperative systems in which humans canachieve more than if they were workingalone. HC:l software is needed to explc)itthis potentiaL

Creating better HeI software will have amajor effect on software engineers them­selves because their main activity is design­ing for mostly ill-structured problems. In­telligent computer-support systems andgood interfaces are crucial for imprO\~ngthe productivity of the software engineerand for increasing the quality of the soft­ware product. The cost of hardware andsoftware in future systems will be smallcompared \\1:th the cognitive costs occur­ring in the development, comprehension,and use ofcomplex systems. .:.

AcknowledgmentsI thank my former colleagues and students

on the Inform project at the University ofStull­gart and my curren t colleagues and studen ts atthe UniversitvofColorado, especially AndreasLemke and Charles Hair, who designed anddeveloped Framer; Anders Morch, who de­signed and developed Crack; RaymondMcCall, who contributed to the evaluation ofCrack and who critiqued an earlier version ofthis article;Janet Grassia and Francesca Iovine,who helped edit the article; and Heinz-DieterBoecker, Hal Eden, Franz Fabian, ThomasMastaglio, Helga ~ieper-Lemke,ChristianRathke, and Curt Stevens, who all have mademajor contributions to the research describedhere.

This research was supported in part by Arm}Research Institute grant MDA903-86-COI43,US West Advanced Technologies grant0487.12.0389B, and a Software Research Asso­ciates (Japan) gran t.

ReferencesI. G. Fischer and M. Schneider, "Knowledge­

Based Communication Processes in Soft­ware Engineering," Pror. Sf'1Jf!1/h In/'! Con!So/tworfFng., (:S Press, I,osAlamitos, Calif.,1984, pp. 358-368.

2. H.A. Simon, T'heSrienrPlo//hpArti[irial, MITPress, Cambridge, Mass., 1981.

3. K.R. Popper, Thf Logir ofScien/ifir Disrovery,Harper & Row, ~ew York, 1968.

4. W.R. Swartout and R. Balzer, "On the Ine\i­table Intertwining of Specification and Im­plementation," Comm. ACiH,July 1982, pp.438-439.

5. G. Fischer and AC. Lemke, "ConstructionKits and Design Environments: StepsToward Human Problem-Domain Com­mun ication," Hzunrtn-Crml/m/N In/nor/ion,1\'0.3,1988, pp. 179-222.

6. G. Fischer, "Cogniti\'e View of Reuse andRedesign," 1I]~1~' Sojiwm'f,J uly 1987, pp. 60­72.

7, B. Betts et aI., "Goals and Objectives forL'ser-lnterf~Ke Software," Com/m/n Gm/)h­irs, April 1987, pp. 73-78,

8. S.K. Card, TP. 1\10ran, and A 1\'ewell, '1lIePlydw!oi.,')' oj Human-Com/m/n In/pror/ion,Lawrence Erlbaum Assoc., Hillsdale, :\J,1983.

9..J.1\1. Carrol and.J. 1\1cKendree, "lnteJi~Ke­

Design Issues for A(hice-Gi\ing Expert Svs­tems," (;0111111. ACA1,Jan. 1987, pp. 14-31.

Gerhard Fischer is professor of computelscience and a member of the Institute ofCognitiYe Science at the l.'ni\ersitv ofColorado at Boulder. Fischer directs the uni­yersitv's Knowledge-Based Systems <11](1

Human-(;omputer Communication Rese;llc)1Group.

His research interests include artificial intel­ligence, human-computer communicatioll,cognitin' science, and software engineering:he is especiallv interested ill bringing these re­search disciplines together to build coopera­tive problem-soh'ing sYstems.

Fischer recei\'ed a PhD in computer sciencefrom the l.'niYersit\' of lIamiHlrg.

52 Copyright © 1989 The Institute of Electrical and Electronics Engineers, Inc.Reprinted with permission from IEEE SOFTWARE,

10662 Los Vaqueros Circle, Los Alamitos, CA 90720