� � PRINCIPLES FOR THE DESIGN OF MANUALS : A N foundation for PAC is the distinction promoted b y some theoretical models between the semantic an d EMPIRICAL STUDY AND PRODUCTION RUL E the lexical aspects of the human-compute r ANALYSI S interaction [Foley 82, Norman 84, Shneiderma n RICHARD CATRAMBON E 87] . However, PAC stresses the fact that thes e notions do not form strict monolithic layers bu t Research on manual design often does not speak to th e instead, are distributed across various levels o f needs of manual writers . One reason for this state o f abstraction . affairs is that researchers typically do not explain why a principle works or how to implement it in variou s This article describes PAC and illustrates it s contexts . They do not provide a cognitive model t o application through a couple of examples . The justify the principles . A model of how people acquir e next section concerns the definition of the mode l procedural skills would enable writers to appl y per se. Section 3 concentrates on the interest of documentation principles more effectively in a variety o f PAC and shows how this model can provide th e contexts . Unfortunately, research that could provide usefu l foundations for supporting some of the element s models tends not to use realistic tasks . Thus, it is no t essential to the quality of a user interface : context , clear that the tested principles would work for a rea l concurrency and adaptability . manual . The goal of the proposed research is to us e realistic tasks to examine individual principles for manua l 2 . PAC, an Implementation Mode l design . In addition, a production rule formalism based o n a model of the user's cognition will be used to generat e As shown in figure 1, PAC structures a n predictions about the success of the documentatio n interactive application in three parts : Presentation , produced according to various principles . An example o f Abstraction and Control . such a prediction would be : instructions which translat e • the Presentation defines the concrete synta x to fewer productions and which require the user to do les s of the application, i .e . the input and outpu t inferencing (i .e ., creating new productions from old ones ) behaviour of the application as perceive d will be easier to follow . If the predictions are accurat e by the user . then the formalism can be used as an additional tool fo r evaluating documentation principles and guiding thei r • the Abstraction part corresponds to th e implementation . semantics of the application . It implement s the functions that the application is able t o Richard Catrambon e perform .These functions are supposed t o result from a thorough task analysis . Richard Catrambone is a graduate student in Experimenta l Psychology at the University of Michigan . His interest s the Control part, maintains the mappin g include problem solving and the design of documentation . and the consistency between the abstrac t The abstract above is based on his proposed dissertation . entities involved in the interaction an d Richard's address is : University of Michigan, Departmen t implemented in the Abstract part, and thei r of Psychology, Human Performance Center, 330 Packard , presentation to the user . It embodies th e Ann Arbor, MI 48104 . boundary between semantics and syntax . I t is intended to hold the context of th e overall interaction between the user and th e application . . — Interactive Applicatio n PAC : AN OBJECT ORIENTED MODEL FO R IMPLEMENTING USER INTERFACE S JOELLE COUTA Z 1 . Introductio n PAC is an implementation model that attempt s to bridge the gap between the abstract sphere of Figure 1 : PAC structures an application into thre e theoretical models such as GOMS [Card 83], an d components : Presentation, Abstraction and Control . the practical affairs of building user interfaces . The SIGCHI Bulletin 37 October 1987 Volume 19 Number 2
� � This constitutes a first level of description o f Control of the application through invocation o f an interactive application . We need now to refin e the appropriate methods . The Control of the pip e the Presentation part . signals changes to the pipe Presentation and, if necessary, to its subobjects . The subobjects of th e The Presentation of an application is made of a pipe will be discussed further . For now, let' s set of entities called interactive objects . As fo r carry on with the description of the pipe level . applications, an interactive object is organize d according to the PAC model : it has a Presentation , For output, the pipe Presentation i s an Abstraction and a Control part . An interactiv e responsible for drawing the shape of a pipe (i .e a object may be elementary or may result from th e rectangular area of some size, a set o f composition of other PAC entities . There is n o subrectangular areas of some size, a bend at som e restriction on the granularity of a PAC entity . location and some colors) . The pipe Presentatio n Consider for example the object pipe represente d does not know anything about pipes and fluids . in figure 2 . For output, it is simply concerned with drawing a picture according to some parameters set by th e Pi p e pipe Control . For example, if the fluid is col d water, the Pipe Control would set the .value of th e parameter color of the Presentation to blue an d would switch progressively to red as the simulato r would signal heat increase . For input, the Presentation would accep t mouse clicks . For example, the user would click a t some place in the picture of the pipe . This clic k would be interpreted by the pipe Presentation as a "show me the subrectangular area denoted by m y click" . The feedback provided by the pip e Presentation would be something like a revers e video of the subarea . Now, if the use r "double-clicks" a subarea, the Presentation woul d perform the same feedback but, in addition, woul d notify the pipe Control that "this subarea has bee n Figure 2 : a Pipe object structured as a PAC entity and selected" . This event would be interpreted by th e composed of two PAC sub-objects : a gauge and a pipe Control as a "show me more details about thi s pipe-element . section" and the user would get a zoom of th e section . Let's see how . The object pipe is supposed to be a componen t of the Presentation of an application whos e As shown in figure 2, the interactive objec t Abstract part would be, for example, the simulato r pipe has subobjects : a set of pipe-elements and a gauge . A pipe-element describes in detail what i s of a plant. The user of the simulator would b e interested in having a global view of the behavio r currently happening in a particular section of th e pipe . The Abstraction of the gauge is an intege r of the pipe as well as, in certain circumstances , value set within a given range ; for output, it s obtaining detailed information about a particula r Presentation is mainly in charge of drawing a section of the pipe . The simulator would generat e numerical values corresponding to an abstrac t needle and a circle of a given size at some location ; representation of the pipe (say a Pascal record) an d for input, it interprets mouse events related to th e needle as modifications of the abstract value . pass this information to the Control of th e application . The Control, which maintains th e Both the gauge and the pipe-elements ar e mapping between abstract application-dependen t supervised by the Control of the pipe who decide s entities and presentation user-dependent interactiv e which abstract information they present . Thus , objects, would translate the information produce d when the Control of the pipe receives the reques t by the simulator into the appropriate messages fo r the interactive pipe object . "show me more details about this section", i t generally creates an instance of the clas s pipe-element, sends it the appropriate abstrac t The Abstract part of the pipe is comprised o f numerical values (e .g . pressure, temperature, size , values and asks it to show itself . If the pip e element already exists, but is not currentl y type of the fluid) that can be accessed by the SIGCHI Bulletin 38 October 1987 Volume 19 Number 2
Recommend
More recommend
