Exhibit 1017 – Part 3
`
`Exhibit 1017 — Part 3
`
`

`
`
`
`140 ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`
`
`they construct for achieving the goal and subsequent subgoals. The
`procedures represented at this level of the TKS provide a description of
`the rules task performers would expect to follow, and the alternative
`procedures they would follow under particular conditions. A task
`performer’s plan at this level of representation is related to our notion
`of task structuring where certain task components precede, prime or
`follow one another. Task structuring determines the sequence or
`ordering of procedures necessary for successful task execution. This
`information provides the system designer with a view as to how people
`structure their tasks under certain circumstances: it also allows the
`
`system designer to decide how the user will expect to make use of the
`objects and actions (functions) and identifies the most frequent or
`preferred procedure for achieving a subgoal. This information can be
`used to set up default modes of operation in the program design.
`Finally, at the object and action level, the taxonomic substructure
`identifies the representative actions and objects within the domain and
`the features of those task elements. The work on concept and object
`knowledge of Rosch and her colleagues (Rosch et al., 1976) leads to the
`suggestion that if the designer chooses to support this task and provide
`a visible representation of the objects and the actions that can be carried
`out on those objects, then the taxonomic substructure provides an
`informative and detailed description of the features a person will expect
`to associate with those objects. Additionally, the degree of
`representativeness of task objects and/or actions, and the centrality of
`the procedures containing those components (actions and objects),
`provides the designer with an indication of which are deemed to be
`typical and necessary for successful task completion. The consequences
`of overlooking both central and representative task components in
`system and user-interface design are likely to have severe consequences
`for the ultimate usability of the system.
`
`5.6.2 Empirical support for TKSs
`
`Empirical evidence for the improvement in usability afforded by
`modelling TKSs is provided by Davis (1988) in a pilot study of graph
`and table drawing. The first part of the study identified representative
`objects and actions, central procedures and sequencing of task
`procedures for the above 2 tasks across a population of 12 subjects. An
`experiment was then carried out in which 3 further groups of subjects
`were required to undertake graph and table drawing tasks using 1 of 3
`different interfaces with the same underlying functions.
`One interface was structured so that it positively supported
`representative and central task components, and task sequencing
`identified by the TKS modelling stage. The second interface was
`unstructured; representative and central task components were
`supported but representative objects were not identified with their
`
`SKYHAWKE EX. 1017, page 79
`
`SKYHAWKE Ex. 1017, page 79
`
`

`
`
`
`KNOWLEDGE ANALYSIS OF TASKS
`
`141
`
`associated actions and the sequencing of task procedures was not
`supported. A further control group had an interface which contained
`neither central nor representative task components, and which had no
`explicit task structure.
`The results of the pilot study showed that subjects found the
`structured interface easier to use, and also this interface had a higher
`preference value from subjects. Additionally, the structured interface
`resulted in quicker task execution, and the resulting graph and table
`drawings were better quality in that they were more complete. Also, the
`unstructured but central and representative interface design produced
`better performance than the control group interface, but less than the
`structured interface group. The findings thus support the theoretical
`view that TKSS provide important information about users which can
`be used to design improved user interfaces.
`
`5.7 Relating KAT to design practices
`
`Software systems design occurs in many different ways, resulting in a
`certain reluctance on the part of academics and industrialists alike to
`speak of an ideal design process. However, it is becoming increasingly
`clear that task analysis has a part to play in current and future design
`practices.
`In this section, the contribution KAT might make to current design
`practices is briefly considered. It is not, however, the intention to argue
`for the use of KAT in specific design methodologies, structured or
`otherwise, since KAT is potentially appropriate to many current design
`methodologies and practices.
`The traditional system development life cycle described in Chapter I
`typically involves the following stages. First, a feasibility study is carried
`out to establish whether it would be possible to build a system to
`support users’ tasks, and if there is a market for such a product. After
`the feasibility study has been completed, a requirements specification
`would be prepared, followed by the design of the system. The system
`design, determined by the nature and the content of the requirements set
`out in the requirements definition, is then implemented, the
`implementation is tested and the system subsequently released. After a
`period of time in use by the customer the system is updated and
`maintained.
`We can envisage a scenario where task knowledge requirements
`identified by KAT could augment existing user requirements in the
`software (and/or hardware) design life cycle. First, we would expect
`user requirements to be taken into account in any feasibility study. This
`would involve a small-scale task analysis. Using KAT at this stage
`identifies commonalities across tasks through within-role relations and
`also by the identification of generic task elements. At the requirements
`
`SKYHAWKE Ex. 1017, page 80
`
`SKYHAWKE Ex. 1017, page 80
`
`

`
`142
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`|
`,
`
`definition stage a full-scale task analysis using the KAT methodology
`would be carried out to establish and document user task requirements
`in terms of users’ plans, goals, subgoals, strategies, procedures and
`representative and central actions and objects.
`The results of a TKS model can be easily decomposed into general,
`specific and interface design models, as shown by Johnson et al., (1988),
`where the KAT methodology was used to produce frame-based
`representations of a messaging system, the virtual interface to that
`system and the dialogue structure.
`KAT may also play a role in usability and learnability evaluation,
`before and/or after the construction of a prototype or full
`implementation. The use of KAT in evaluation relates to whether
`aspects of a person’s task knowledge, identified by KAT, have been
`carried over into the designed, prototyped or fully implemented system.
`This specifically involves finding out whether all appropriate tasks have
`been supported; whether generic task elements have been taken into
`account; whether representative and central task actions and objects
`have been represented; whether sequencing of task procedures have
`been supported rather than violated; and finally, whether defaults have
`been correctly specified and supported.
`If these factors are taken into account the user will be expected to be
`in a position to transfer appropriate extant knowledge to the newly
`created environment and as a result the system designed will be easier to
`use and learn. Furthermore, predictions can be made as to where this
`transfer will be unsupported, whether interference is likely to occur, and
`in which areas training might be necessary.
`
`5.8 Conclusions
`
`In this chapter we have described a theory and method of modelling the
`knowledge people possess about tasks and roles in a given domain,
`known as knowledge analysis of tasks (KAT). The information
`contained within the task models constructed within the KAT
`
`methodology is very rich and can be used as an information source to
`which designers can be given access; it prevents the designer having to
`rely on his or her own intuitions about peoples’ task knowledge.
`Empirical evidence suggests that the TKS models identify important
`features of knowledge that can influence the usability of systems when
`the design recommendations arising from a TKS are followed. Finally,
`the contribution made by KAT and TKS models to current design
`practices is considered.
`
`SKYHAWKE EX. 1017, page 81
`
`SKYHAWKE Ex. 1017, page 81
`
`

`
`-
`
`KNOWLEDGE ANALYSIS OF TASKS
`
`143
`
`Acknowledgement
`
`The research described in this chapter was developed as part of an
`ICL-funded University Research Contract research project on ‘The
`development of task analysis as a design tool’.
`
`References
`
`Annett, J. and K. D. Duncan (1967) ‘Task analysis and training design’, Journal
`of Occupational Psychology, 41, 211-221.
`Card, S. K., T. P. Moran and A. Newell (1983) ‘The Psychology of Human
`Computer Interaction’, Lawrence Erlbaum Associates, Hillsdale, New
`Jersey.
`Davis, S. (1988) ‘Knowledge structures in the human computer interface’.
`Unpublished manuscript, Queen Mary College, University of London.
`Diaper, D. and P. Johnson (1989) ‘Task analysis for knowledge descriptions:
`theory and application in training’, in Cognitive Ergonomics, J. B. Long and
`A. Whitefield (eds), Cambridge University Press, Cambridge.
`Fleishman E. A. and M. K. Quaintance (1984). Taxonomies of Human
`Performance, Academic Press, New York.
`Galambos, J. A. (1986) ‘Knowledge structures for common activities’, in
`Knowledge Structures, J. A. Galambos, R. P. Abelson and J. B. Black (eds),
`Lawrence Erlbaum Associates, Hillsdale, NJ.
`Graesser, A. C. and L. F. Clark (1985) Structures and Procedures of Implicit
`Knowledge, Ablex Publishing, Norwood, NJ.
`Johnson, P. (1985) ‘Towards a task model of messaging’, in People and
`Computers: Designing the User Interface, P. Johnson and S. Cook (eds),
`Cambridge University Press, Cambridge.
`Johnson, P., D. Diaper and J. Long (1984) ‘Tasks, skill and knowledge; task
`analysis for knowledge based descriptions’, in Human—Computer
`Interaction—INTERA C T ’84, B. Shackel (ed.) North-Holland, London.
`Johnson, P., H. Johnson and F. Russell (1988) ‘Collecting and generalizing
`knowledge descriptions from task analysis data’, ICL Technical Journal, 6,
`137-155.
`
`Johnson, P., J. Johnson, R. Waddington and A. Shouls (1988) ‘Task related
`knowledge structures: analysis, modelling and application’, in People and
`Computers: from Research to Implementation, D. M. Jones and R. Winder
`(eds), Cambridge University Press, Cambridge.
`Keane. M. and Johnson, P. (1987) ‘Preliminary analysis for design’ in People
`and Computers, D. Diaper and R. Winder (eds), Cambridge University
`Press, Cambridge.
`Kieras, D. and P. Polson ( 1985) ‘An approach to the formal analysis of user
`complexity’, International Journal of Man-Machine Studies, 22, 365-394.
`Kelly, G. A. (1955) The Psychology of Personal Constructs, Norton, New York.
`Leddo, J. and R. P. Abelson (1986) ‘The nature of explanations’, in Knowledge
`Structures, J. A. Galambos, R. P. Abelson and J. B. Black (eds), Lawrence
`Erlbaum Associates, Hillsdale, NJ.
`Olson, J. R. (1987) ‘Cognitive analysis of people’s use of software’, in
`Interfacing Thought: Cognitive Aspects of HCI, J. M. Carroll (ed.), MIT
`Press; Cambridge Mass.
`Payne, S. J. and T. R. G. Green (1986) ‘Task-action grammars: a model of the
`mental representation of task languages’, Human Computer Interaction, 2,
`93—133.
`
`1
`
`,
`:.
`
`‘
`l
`
`l
`"
`
`SKYHAWKE EX. 1017, page 82
`
`SKYHAWKE Ex. 1017, page 82
`
`

`
`
`
`144 ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`Rosch. E. ( 1978) ‘Principles of categorization’. Cognition and Categorization, E.
`Rosch and B. Lloyd (eds). Lawrence Erlbaum Associates. Hillsdale. NJ.
`Rosch, E. (1985) ‘Prototype classification and logical classification: the two
`systems‘, in New Trends in Conceptual Representation: Challenges to
`Piaget's Tlzeoryfi’. E. K. Scholnick (ed.), Lawrence Erlbaum Associates,
`Hillsdale, NJ.
`Rosch, E., C. Mervis, W. Gray, D. Johnson and P. Boyes-Braem (1976) ‘Basic
`objects in natural categories’, Cognitive Psychology. 8. 382-439.
`Schank, R. C. (1982) Dynamir memory: A Theory of Reminding and Learning in
`Computers and People, Cambridge University Press. New York.
`Welbank. M. (1983) A Review of Knowledge Acquisition Techniquexfor Expert
`Systems, Martlesham Consultancy Services, British Telecom Research
`Laboratories, Ipswich.
`
`SKYHAWKE EX. 1017, page 83
`
`SKYHAWKE Ex. 1017, page 83
`
`

`
`T“ .
`
`7 Dialogue delivery
`systems: example
`research systems
`
`PETER JONES
`
`
`
`7.1 Introduction to dialogue delivery
`
`systems
`In Chapter 4, part of the discussion was based on the idea of classifying
`dialogue styles. The main styles identified were command language, menu
`selection, form-filling, natural language and direct manipulation. In
`Chapter 6, an abstract model for a dialogue system was developed.
`Systems that implement the model are referred to as user interface
`management systems (UIMS). This chapter examines several dialogue
`delivery systems chosen to illustrate important aspects of these styles,
`which in reality may overlap.
`In addition to being exemplars of the styles, the systems were also
`chosen to demonstrate a variety of approaches to the specification of
`the dialogue component of interaction. Command language is covered
`only briefly as it is assumed that most readers will be familiar with such
`interfaces. However, some recent work on extending command language
`interfaces is described. Next the ZOG menu- and frame-based system is
`described; then a form-filling metaphor is illustrated with C0 USIN. The
`use of transition networks to specify a dialogue is shown in Rapidl USE
`and CONNECT. Natural language is introduced through some early
`work by Weizenbaum on the application of natural language to
`man—machine communication. Then its use both in medical interviewing
`and the Mycin expert system is described, leading on to the
`natural-language help system used in the UNIX Consultant.
`The systems, which come mainly from the research environment, have
`been chosen to illustrate how actual implementations differ from the
`abstract model presented in Chapter 6. In general, the discussion is not
`detailed, but instead concentrates on bringing out what is seen as the
`important ideas embodied in the implementation. However, further
`details can be found in the references.
`
`SKYHAWKE Ex. 1017, page 84
`
`SKYHAWKE Ex. 1017, page 84
`
`

`
`164
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`A> DIR
`
`Prompt
`
`Command
`
`Figure 7.1
`
`A CP/M prompt with a command
`
`7.2 Command languages
`
`Command languages are exemplified by the user interface to most
`operating systems (Beech, 1986). In the early days of computing,
`designers of such systems knew that the users were likely to be highly
`motivated experts and therefore concentrated on delivering the
`maximum functionality. Many early operating systems operated purely
`in batch mode, where the user presented a complete task with
`commands and data. Any feedback to the user was provided much later
`in the form of a hard-copy listing showing the progress of the
`commands, the data used and the output produced. Later operating
`systems allowed for more interaction with the user in order to control
`and monitor what was going on.
`
`7.2.1 Digital Research CP/M
`
`With the advent of the minicomputer in the rnid-1960s and the
`microcomputer in the 1970s, more users began using computers
`interactively. From the user’s point of view, the CP/ M operating
`system from Digital Research was of great importance as the first
`general-purpose operating system to be widely used on
`microcomputers, and hence by the novice user. Its technical success
`stemmed from the fact that it was designed to be largely independent
`of the particular hardware on which it ran. and thus it established a
`large base of users and application software. Nevertheless, it had many
`awkward features (in common with many other command language
`systems): the prompts were rather cryptic, error messages were barely
`intelligible, there was an almost complete lack of help, and a crude
`command syntax with position-dependent arguments were used. For
`example. the prompt merely shows the currently selected disk drive,
`(Figure 7.1), while on switching to a subsystem, for example a text
`editor, the prompt changes, but with very little other feedback to the
`user (Figure 7.2).
`
`SKYHAWKE Ex. 1017, page 85
`
`SKYHAWKE Ex. 1017, page 85
`
`

`
`DIALOGUE DELIVERY SYSTEMS: EXAMPLE RESEARCH SYSTEMS
`
`165
`
`A> ED HCI.TXT
`.1
`
`/
`
`New prompt
`
`Figure 7.2 Change of prompt in the editor
`
`This style of interface was very poorly suited to the new and
`inexperienced computer users who were attracted to microcomputer
`systems by their low cost compared with previous generations of mini-
`and mainframe computers. Fortunately, the support provided for CP/M
`application programmers in the form of system calls and access to the
`file system made it possible for applications to provide their own,
`completely independent, support for common operating system
`functions. Thus successful end-user CP/M applications such as
`Wordstar (Figure 7.3) entirely replaced the basic CP/M command
`language with menu-based command selection and a form-filling
`mechanism for specifying filenames.
`
`7.2.2 Dialogue Development System (DDS)
`More recently, other approaches have been taken to increase flexibility
`in command language dialogues. At the University of Bradford, UK, a
`multilevel adaptable system, Dialogue Development System (DDS). was
`proposed for use with Ada (Robinson and Burns, 1985). As well as
`
`E
`X
`
`!\|!\ 3 Pfimfifl
`EXIT tn Stlstea
`
`I
`
`
`
`Figure 7.3 Wordstar mam menu
`
`SKYHAWKE Ex. 1017, page 86
`
`SKYHAWKE Ex. 1017, page 86
`
`

`
`166
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`__d__ _ — -
`
`/“
`
`Feedback
`'“~-.
`
`Applications
`
`software
`
`
`
`
`Dialogue
`development
`system
`
`
`
`Figure 7.4 Proposed DDS system
`
`emphasizing the adaptiveness required, this provided a separate
`high-level specification of the interface in order to relieve the
`application programmer’s task of dealing with the interaction. A user
`interface specification language (UISL) was proposed to encourage this
`separation. Another key objective was" to automate aspects of providing
`user feedback: for example, the type of an object could automatically
`provide for user feedback on erroneous input.
`DDS is a range of tools that includes a dialogue manager (DM),
`which interprets the UISL, provides feedback, and controls the
`adaptation. A terminal database provides a virtual terminal that is
`device- and machine-independent. A validator is interposed between the
`application software and the DM to check the interface. As can be seen
`from Figure 7.4, the user interface system is run as a separate Ada task
`communicating with the other tasks forming the application. A screen
`formatter is provided to allow the construction of non-textual dialogues
`such as menus. Finally, a system monitor is used to provide a constant
`analysis of the system’s performance and how this affects users.
`Although a command-style interface is used, DDS provides for a
`mixed initiative interaction, for example prompting when arguments are
`missing. An example would be the issuing of a ‘file copy’ command
`when the user is in control (shown by the prompt of ‘ > > ’):—
`
`>> COPY
`
`DDS then realizes that the arguments are missing and takes control to
`ask for them,
`
`from file> FRED
`
`and then,
`
`to file> JOHN
`
`with the prompt of ‘ > ’ to show that control is now with DDS.
`
`file copied.
`>>
`
`and control is returned to the user.
`
`SKYHAWKE EX. 1017, page 87
`
`SKYHAWKE Ex. 1017, page 87
`
`

`
`
`DIALOGUE DELIVERY SYSTEMS: EXAMPLE RESEARCH SYSTEMS
`
`167
`
`7.3 Menu selection: ZOG
`
`Menu systems are straightforward to implement. All that is needed is to
`list the options available and then to ask the user to choose from among
`them. For example, several commercially available communication
`packages for connecting personal computers have a scripting language
`that can readily be used to generate menu systems without the need for
`any expertise in programming. It is more interesting, however, to
`investigate systems that provide a generalized notation for the
`specification of menu systems.
`ZOG (Robertson et al., 1981) is a rapid-response, large—network,
`menu selection system. Work on ZOG began originally in 1972 and
`restarted in 1975 at Carnegie-Mellon University, Pittsburgh, USA. The
`later work was inspired by the interface style used in the PROMIS
`(Walton et al., 1979) medical information system at the University of
`Vermont. The name ZOG was chosen as a short arbitrary name and is
`not an acronym.
`In the period 1975—80 ZOG was developed on Digital Equipment
`Corporation’s PDP-10s and Vaxes. Subsequent development moved
`ZOG to a personal workstation, a PERQ, with high-resolution graphics
`and a pointing device. In the early 1980s the PERQ version was used as
`a computer-assisted management system on the aircraft carrier USS
`Carl Vinson (Akscyn and McCracken, 1984). Most recently,
`development has resulted in a distributed hypermedia system called
`knowledge management systems (KMS) (Akscyn et al., 1988b), which is a
`commercial version of ZOG available on Sun and Apollo workstations.
`ZOG has been used as an interface for a command language system, a
`database retrieval system, a CAI system, a guidance system, an
`interrogation system and a question—answering system. It is based on a
`hierarchy of subnets. Each subnet is a tree of frames in the form of a
`database. The system displays the frames to the user; a self-descriptive
`version is shown in Figure 7.5.
`The frame has a title and a unique number. Then comes some context
`information, which could, for example, indicate how the user came to
`
`Context information
`
`Frame title
`
`Frame #
`
`\.
`
`Some explanatory text
`
`
`
`Menu selections —<-D
`
`1 Option 1
`2 Option 2
`3 .
`.
`.
`
`Global pads ————>
`
`Edit Help Back Next Mark
`Return Goto .
`.
`.
`
`Figure 7.5 An outline ot a ZOG frame
`
`SKYHAWKE EX. 1017, page 88
`
`SKYHAWKE Ex. 1017, page 88
`
`

`
`163
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`this particular frame. Below that can be several lines of descriptive text
`followed by columns of menu selections, shown as options in Figure 7.5.
`At the bottom is a line of global pads, or menu choices, that appear on
`all frames. For example the user could choose goto and proceed directly
`to a known frame.
`
`The user traverses these frames by making selections. Additionally, a
`selection can evoke an action to accomplish a task. The selection can be
`made either by using touch-sensitive pads overlaying the selection or by
`entering a single character from the keyboard. The user therefore
`navigates through a structured set of subnetworks of interconnected
`frames, gathering information on the way. As an aid to navigation the
`user can see a list of frames visited, or a list of frames marked (i.e.,
`anchor points) and can search for a particular frame.
`The frames are built using a frame editor, ZED. This can be used at
`any time by the developer, including when using the system. A user
`might also use the editor for a limited amount of personalization.
`The internal structure of a frame contains not only the visible
`information as seen by the user but also additional features. For
`example, there is a maintenance field that contains, among other items,
`the name of the owner of the frame and access privileges indicating
`whether it may be modified or viewed by others. The frame builder has
`the responsibility of providing guidance, on-line documentation and
`help.
`Selections and frames may include action text. This text is sent to the
`communications multiplexer, which arranges for it to be sent to the
`correct destination. The frames also have an external format. This
`
`supports portability to other ZOG implementations as well as allowing
`for external maintenance manipulation.
`ZOG is really a hierarchical menu system together with a generalized
`mechanism for the display of information and triggering of actions. As
`with any menu hierarchy, users can get lost, but are provided with some
`significant features that aid navigation. The limited display area places a
`heavy load on short~term memory; even so, evaluation revealed
`evidence that users failed to read the information in frames. The
`researchers also investigated the impact of different response times and
`provide some evidence for it to be less than 0.5 seconds. The later KMS
`
`system overcomes many of these problems, for example by always
`showing two frames so that the user can see the previous frame too.
`
`7.4 Form-filling: COUSIN
`
`COoperative USer INterface was designed by Phil Hayes at
`Carnegie-Mellon University (Hayes and Szekely, 1982). It is aimed at
`typical command—level interaction, for example interacting with an
`operating system, and not the more fine-grained interactions within, say,
`
`SKYHAWKE Ex. 1017, page 89
`
`SKYHAWKE Ex. 1017, page 89
`
`

`
` e
`
`
`
`DIALOGUE DELIVERY SYSTEMS: EXAMPLE RESEARCH SYSTEMS 169
`
`_ l XI
`Print
`
`Copies: :|
`
`Font: :|
`
`Number of columns
`
`1: E 2: [:1
`
`Long lines
`
`wrap: lj
`
`truncate: E]
`
`Figure 7.6 A COUSIN form
`
`an editor. COUSIN aimed to present a consistent interface for all
`applications and to provide the benefit of reduced implementation time.
`COUSIN uses a form-filling metaphor. This provides a single
`interface to several applications. The form-filling has intelligent support,
`mainly from the type information held in each field.
`The (simplified) example in Figure 7.6 shows a command (print) and
`a set of arguments which must be supplied. Fields for the arguments can
`have default values that may be overtyped by the user. Each field has a
`data type and an attribute indicating whether the field is optional.
`Three modes of operation are supported. A non-interactive mode is
`used for batch applications: COUSIN ensures correct command
`arguments are supplied before calling the application. In the interactive
`mode the application is started and can then prompt the user, when
`needed, for further information. Finally, in the command loop mode the
`user is in control and can issue commands with arguments and observe
`the feedback from the system.
`Several variants of COUSIN were produced, but the main application
`reported is an interface to the UNIX operating system. In this
`application, the user typed a command, then COUSIN loaded an
`appropriate form and assisted the user in filling it in. Once completed,
`the command and arguments were parsed with COUSIN helping the
`user to remove errors. The user could save the form for later use, for
`
`example, the form could be partly filled in with the user’s particular
`default settings.
`The form-filling approach makes good use of bit—map displays, allows
`arguments to be filled in out of order and permits fields to have defaults.
`However, applications need modifying before they can be used with
`COUSIN. Although providing COUSIN as a front-end interface halved
`the speed of UNIX, this did not seem to be a problem with the
`experimental users.
`
`SKYHAWKE EX. 1017, page 90
`
`SKYHAWKE Ex. 1017, page 90
`
`

`
`170
`
`ENGINEERING THE HUMAN-COMPUTER INTERFACE
`
`7.5 Transition networks
`
`7.5.1 Rapid/USE
`
`»
`
`Rapid/USE (Wasserman et al., 1986) has been developed at the Medical
`Information Science Centre at the University of California since 1975. It
`is based on graphical specification of the required dialogue using
`families of state-transition nets and subnets and can rapidly produce
`either a menu or a form-filling dialogue. Diagrams are created using a
`graphical Transition Diagram Editor (TDE) on Sun workstations, or
`textually by using a special language entered with an ordinary text
`editor.
`
`The diagram is a representation of a transition network. Each
`diagram is given a name, a start node and an exit node together with a
`network of interior nodes and arcs. A node definition is a description of
`what to do with the screen, for example screen control, display of text
`and contents of variables. An arc definition describes the structure of the
`diagram. It is labelled with the transition conditions and can have
`actions, including links to a relational database (TROLL).
`Input can be a single key or a fixed-length reply. and can include a
`default to handle errors. Additionally a time-out can be included. The
`actions can be routines written in C, FORTRAN or Pascal or can be
`commands to operate on the relational database. A simple method for
`calling a single procedure with an integer parameter is also provided.
`Figure 7.7 shows a typical transition diagram created using the TDE.
`A text file such as that shown can then be compiled from the
`transition diagram, or alternatively the text file can be created directly
`using a conventional text editor.
`
`
`
`Figure 7.7 A Rapid/USE transition diagram
`
`
`
`SKYHAWKE Ex. 1017, page 91
`
`SKYHAWKE Ex. 1017, page 91
`
`

`
`
`
`DIALOGUE DELIVERY SYSTEMS: EXAMPLE RESEARCH SYSTEMS
`
`171
`
`diagram library entry Start exit Exit
`
`node Start
`cs,rl,c_ ’University Library System’
`r+2,clO ’Do you need help (y/n)?’
`
`arc Start
`on ’n’
`on ’y’
`
`to Topmenu
`to Help
`
`arc Topmenu
`on '1’ to <book-loan>
`on '2’ to <book—return>
`
`arc <book-loan) skip to Topmenu
`
`A transition diagram interpreter (TDI) can be used immediately on
`this text file in order to demonstrate and evaluate the menu system. As
`an aid to evaluation, Rapid/USE can also record two logs of the raw
`input and the transitions occuring within the system (time, diagram,
`node, action, input).
`
`7.5.2 The CONNECT system
`
`The CONNECT system (Alty, 1984a) was developed at the University
`of Strathclyde from 1983 onwards. It is a front-end to the CP/M and
`MS-DOS operating systems and is based on transition networks
`together with a production rule system. This latter feature enables the
`network connectivity to be altered to provide an adaptable interface.
`At any time the network is dealing with one node. It then determines
`which node to move to in response to input from the user. A node can
`be either a connector to communicate with the user, a task to invoke a
`task, a subnet for structuring or an assistor to help routing as well as
`playing a role in adaptivity.
`Transitions along arcs are determined by parsing the user’s input, and
`can occur on detection of identical text, text somewhere in input, or
`numerically equal. Actions that are possible when the transition is
`chosen are null, do a task, show screen, assign to a global, call a subnet,
`or prompt the user. Display updates work on parts of the screen in the
`form of non-overlapping panes. Global variables are used to provide
`communication between the application and the user.
`
`Production rule system
`
`For every network the designer can provide a production rule system as
`a set of statements of the form:
`
`if .
`
`.
`
`.
`
`then <action—rules>
`
`SKYHAWKE EX. 1017, page 92
`
`SKYHAWKE Ex. 1017, page 92
`
`

`
`172
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`Each time a node is reached the production rule system is invoked.
`The if parts of the rules access a database and the actions can then
`modify global variables. Exit arcs from nodes that are labelled with
`these variables can then have their action modified in the light of the
`production rules. This provides a level of adaptability, which allows
`different interfaces to be presented according to the different network
`paths traversed. The designer or the user (by using function keys) can
`adapt the dialogue according to user characteristics.
`CONNECT comes with a family of tools to help build the system:
`
`0 BUILDNET, an interactive network constructor;
`O BUILDSCR, to construct screens;
`0 VIEWNET, to examine nets and screens;
`EXECNET, to execute the net;
`BUILDTSK, to construct tasks;
`TESTSCR, to test a single screen;
`0 PERFNET, to examine net statistics.
`
`A support system based on Path Algebras (Alty, 1984b) has also been
`developed. This allows the designer to analyze the net for consistency
`and to examine the net behaviour. Using this system, it would, for
`example, be possible to determine what would be on the screen at any
`particular point in the dialogue.
`
`7.6 Grammar-based systems: SYNICS
`
`Grammar-based notations such as Backus—Naur Form (BNF) are also
`often referred to as ‘production rule’ systems in that the application of
`the rules can be viewed as ‘producing sentences (programs) in the
`language’. For use as a notation for a dialogue system the grammar
`defines the input language and sometimes the output too (Shneiderman,
`1981). The terminals of the grammar correspond to the user’s input
`tokens (mouse clicks, keyboard characters) and the non-terminals are
`related to the higher-level structure of the dialogue.
`The user interface is thus (as far as input is concerned) a parser for
`this grammar. In order to act on the user input, actions are attache