- Email: [email protected]
Trillium: an interface design prototyping tool
applications Trillium: an interface design prototyping tool by RONALD EASTERBY
Abstract: Trillium was originally developed at Xerox Parc. A UK company has undertaken a number o f so[tware refinements. This paper looks at the history ~[ the design tool and how it can be used in today's environment. Keywords : so[tware techniques, man-machine interlace, software
directly by referring to them by name, by working with their representations on a graphics screen, and observing and modifying the behaviour and interactions of the associated interface elements.
Interface exploration and design tool requirements
mana gement.
n the early development of ergonomic practice, the traditional methods of interface design were derived from engineering drawing office practice. This was accompanied by painstaking drawing of displays and controls of machines with little opportunity for evaluation or exploration of the interfaces usability. The interface in most cases was perceived as an extension of the machine, its features largely determined by the technology and its current limitations. The advent of computer systems encouraged their use in the design of interfaces through the process of interface simulations. These simulations enabled the interface's characteristics to be examined in advance of its actual building and facilitated exploration and empirical study of user interaction and user performance. The difficulty with this approach lay in the long time taken to encode the interface into the programming language of the target computer system chosen for the interface simulations. This paper examines one design tool called Trillium originally developed at Xerox Parc in the USA 1. Trillium attempts to circumvent difficulties of user interaction to a significant extent by allowing the user to deal with manmachine interface design constructs directly, these constructs being derived from the language of interface design. With Trillium, the designer is able to manipulate a representation of an interface's constituent components
I
Artificial Intelligence Ltd, Intelligence House, Merton Road, Watford, Herts WDI 7BY, UK
vol 29 n o 4 m a y 1987
The primary function of an interface is to provide the end user of a machine system with a 'map' of the tasks he/she is expected to perform when using the system. Good interfaces establish coherent and easily perceivable models of the system under control. The system user is always trying to build cognitive models of both the process/system he/she is controlling and to develop notions about the structure of the particular task in hand. If badly designed interfaces are implemented, they inhibit the development of these cognitive processes and, as a consequence, yield poor performance, give rise to errors and increase the possibility of system failure. Typically, the designer of a man-machine interface is confronted with these issues which must be resolved within a given set of technical constraints as well as within the usual limits of time, design resources and cost of implementation. To satisfy the needs of a designer or human factors oriented specialist, a man-machine interface design tool should attempt to accommodate the expertise at their level rather than involve him/her in the acquisition of a range of new supporting skills and abilities, such as writing computer programs. In summary, the top level requirements of a good manmachine interface (MMI) prototyping environment are that it should facilitate a rapid design cycle time to allow explorations through iterative design. MMI should not require the user to engage in programming. The interface design should be representable in terms which a designer understands rather than terms which a programmer understands. MMI should represent the dynamics of the interface. A good design tool should give both surface and
0950-5849/87/040207-07503.00 6") 1987 Butterworth & Co (Publishers) Ltd.
207
behavioural representations of the interface. This requirement is essential because many human factors issues are conditioned by how the interface elements behave and interact with one another as well as by their actual surface appearance.
vehicles, consumer products and process control systems. Its flexibility is such that is can create interface representations for both hardware components of interfaces as well as software generated displays - text, graphics, windows and menus.
Development of Trillium
Some relevant abstractions
Xerox Parc
To satisfy the requirements of a good MMI prototyping tool, directing the functionality at the design process means that certain related abstractions must be encompassed and for the class of interface that Trillium is primarily concerned with there is a particular set of abstractions which is used to develop and represent interfaces.
At Xerox, the increasing complexity of product ranges, occasioned by new technology and increasing sophistication of the controls and displays meant that machine operability became a live issue. The problem was how to develop user interfaces which could be evaluated in terms of their operability in advance of a prototype or completed product. Means had to be found to develop the interfaces so that there could be a number of iterations of the design cycle, involving designers, system developers and users in the design appraisal process. At Xerox Parc, Henderson 1 initiated the concept of prototyping using functioning Frame interfaces which resulted in Trillium being developed as a design tool. This exploited the power and flexibility of a powerful personal workstation supported by bitmapped graphics, mouse and window facilities. The early versions of Trillium were released into the Xerox design environment in 1983 and, since then, a community of users on key sites in the USA and also in the UK have been active in the use of Trillium as a design development tool. Currently the Trillium software runs on a Xerox 1186 workstation with 1NTERLISP-Das the supporting environment, with a configuration requirement of 3.7Mbyte of memory with virtual memory capacity up to 16Mbyte being utilized.
Current software The prototype Trillium system has been supported from within the Xerox community with progressive enhancements and releases such that it is making a significant contribution to product design implementation within Xerox. The more general availability of Trillium which has been undertaken by Artificial Intelligence Limited has involved some refinements to the software, documentation at the users and support level.
Range of applications Trillium encompasses both traditional hardware implemented interfaces and software driven screen display interfaces. The domains in which it can be usefully applied are interfaces for instrument systems, military systems,
208
Interfaces The notion of an interface derives from the historical traditions of human factors whereby both the information displayed and the information acquired by the system through interaction in the man-machine loop is considered separate from the machine system under control. The separation has been driven by the concept that only in this way can the abilities and limitations of the user be taken into account. This separateness endorses the notion that interface design is governed by a different set of constraints to those appertaining to the actual system or process itself. Parenthetically, the advent of computer based systems and the detailed study of human computer interaction has introduced the notion of a dialogue 2'3. This notion of dialogue is sometimes substituted for the concept of the interface. Screen based interfaces being window and menu based are more ephemeral than hard interfaces comprising knobs, buttons and dials. They are therefore probably well described by the term dialogue. But in effect, any man-machine interaction is in the form of a dialogue by way of information exchange between man and machine. The term interface is probably the best abstraction to represent the nature of the man-machine links. The term dialogue might perhaps better be reserved for the representation of the actual set of exchanges which take place across the interface.
Frames A single physical manifestation of the interface is not sufficient for representing interfaces of any substance or utility. Multiple representations of an interface are often desirable and for this purpose the abstraction of a functioning frame is used. In Trillium, any interface comprises a collection of functioning frames which can represent interface func-
information and software technology
applications tionality required to set up, operate and maintain the target machine system at which the interface design is directed. Frames may have the capability of being presented in a screen window one at a time i.e. in serial fashion, or be presented simultaneously i.e. in parallel. In developing an interface, the designer must create a suitable frame structure to represent the manner in which the virtual machine system will be operated upon and controlled by the interface. Thus, the functioning frames give alternative perspectives of the machine control in different state conditions.
Items Each frame contains a set of constituent elements which are the representations required for the user/system interaction to take place. The constituent elements of a frame are termed 'items' and it is the items in a frame with which the user interacts by either assimilating information (display items) or providing information (control items). Further items are also required to give the interface appropriate dynamic behaviour.
Item types To create an item, a repertoire of items, styled 'itemtypes', is required. These are prototypes for the items themselves and incorporate a specific set of characteristics for any given item. An item is therefore an instantiation of an item-type, with designated values for its particular characteristics.
Kinds qf item O'pes The repertoire of item types requires differentiation into different 'kinds' in order to be able to express different design features. The kinds of item required are: • artwork to represent graphic appearance, • displayers to present dynamic information, • sensors to assimilate operator control action. These three basic kinds give explicit representation of the interface. At another level, three further kinds of item types are required to represent behaviour: • initializations to set the initial state of the interface, • inhibitions to constrain the behaviour, • implications to propagate changes throughout the interface and machine representations. These kinds constitute the working set of primitives in Trillium.
vol 29 no 4 may 1987
Item characteristics and values Each item is endowed with a set of'characteristics' which uniquely identify it as a particular type of item and the characteristics in turn have values which distinguish one item from other similar items.
Functions of Trillium The set of item types in Trillium comprise the primitives and compositions of those primitives from which the interface and its associated machine representations are constructed through the instantiation of an appropriate set of items. At the bottom level, all the functioning of the interface representation is displayed entirely through the functional code of the Trillium primitives. Each frame before it is run for the first time is analysed down to the constituent primitives of all the items in the frame. This analysis is then saved and used on each subsequent occasion when the frame is run in a given loaded interface. Maintaining the coherence of all the primitives is 'the Trillium machine' which runs the interface through the process of analysis and subsequent interpretation. The structure which links this analysis and interpretation process to the interface specification (using the item type and frame abstractions) is the state representation which is based on a series of cells. Each cell contains a value pertinent either to an interface element state or to one of a set of state variables representing the machine that the interface is controlling. As well as maintaining and monitoring this state representation, the Trillium machine also maintains a frame stack which chronicles the transitions from one frame to another as the interface is run by the operator or the designer. Continuous monitoring of the state variables represented by cell values enables the Trillium machine to detect state changes and then, through its knowledge derived from its analysis of the interface and its constituent frames, it is able to propagate all the consequential changes. In doing so it takes into account the constraints, initializations and the characteristics of the individual items specified by the designer of the interface.
Scenarios In use, Trillium acknowledges different types of user who will interact with the software. In support of the design operations, it acknowledges a set of protocols which are available to explore the design through manipulation at the item, frame and interface level. These protocols are by way of either support protocols or major design protocols.
209
Trillium users Different individuals with different skills are potential users of the Trillium environment and different styles of interaction are required to enable these different types of user to interact appropriately. Four different types of user interaction can be identified. Enduser interaction. This is the interaction mode where, the interface design having been completed, a typical set of end users interact with the interface to test its operability. All the functionality required for the final interface to the system is available to the end user, but there is no way in which he/she can modify the characteristics of the interface as such, the user can only interact with the interface in its running operational mode. Designer mode interaction. In this mode, the environment is used to explore the design to develop a particular interface. The designer may be a design engineer, an industrial designer or a human factors specialist. The necessary capability at this level is provided to set up, change, edit, modify, extend, save, restore and create all of the objects necessary to build an interface representation: interfaces, frames and items. Programmer (supporter) mode. In this mode, the concern is not only with developing the interface but with the specification and implementation of the entities used to build up interfaces, most particularly item-type creation enhancement and extension. The use of the environment at this level is not program independent; some detailed knowledge is required of the programming language (INTERLISP-D)in which the environment is implemented. System developer mode. This level of interaction is not strictly a user mode. It is the development and modification of the environment itself as opposed to the previous mode where it is the manipulation of the entities which is involved in the user interaction. Interactions at this level involve fundamental changes in the way in which the Trillium environment is configured and the way in which it operates, deals with and runs interfaces.
Prototypical use o / the environment Typical use of the environment involves a set of principle design protocols for manipulating the interface design at the item, frame and interface level. These principle design protocols are supplemented by a set of complimentary supporting protocols. These enable the designer to specify his/her working style and manage his/her work through saving, retrieving and sharing designs in successive design sessions. Supporting protocols are available for preliminary operations such as creating, naming, saving and retrieving interfaces. They can set up the interaction style of the
210
environment in terms of such features as user mode, editing style, menu structure and display/redisplay protocols. Supporting protocols are also available for saving and retrieving all the objects such as interfaces, frames and items from a design session. Finally, supporting protocols are available for utilities used within a frame to save, retrieve and transfer individual items and groups of items within the interfaces being manipulated in the current design session. Such operations are capable of being freely interspersed with other current design activities.
Design session scenario Typically, a design session scenario for creating and evaluating an interface consists of a series of interactions with the environment, involving some preliminary operations, the generation of basic surface representation, refining of the surface representation, setting up the behaviour representation and evaluating and running the interface. An activity cycle for such a design session might be as follows: ,~ Task 1: preliminary operations • designating an interface name, • opening a display window for the interface, • locating and sizing a screen window, • creating an initial frame for the interface. These operations are enabled through the use of the top-level menu of the environment (See Figure 1). (~ Task 2: generating basic surface representation • selecting items from a library of item types, • modifying the appearance of the items by editing their characteristic values. These activities involve the use of a menu to invoke selections from a classified set of all the differing items available (around 100 in the basic system) and the use of characteristic value editor. This enables all the values to be modified, regardless of whether the data type is numeric, symbolic, text or pictorial, by automatically invoking a suitable value editor (see Figure 2). ~ Task 3: refining the surface representation • reshaping and sizing the interface items, • relocating and aligning interface items. A series of utility functions, again invoked by menu selection, enables the currently displayed frame items to be reshaped and resized, alignments can also be made along any specified reference points or edges or items to be
~
information and software technology
applications Open I n t e r f a c e
0
Window
330
Create New Object Copy O b j e c t
30
300
I
Delete O b j e c t Add O b j e c t s to I n t e r f a c e Remove Objects from Interface S h o w O b j e c t s on I n t e r f a c e
270
Edit Item T y p e s Edit User Profile
240
Loading and Saving Files
matched in terms of their basic bounding dimensions of width and height. In addition, for precise determinations, pixel based dimensions can be derived for element sizes and separations. At this phase the designer has a simple surface representation of the interface which is essentially static in nature (Figure 3). The subsequent steps introduce behaviour into the interface. o Task 4: setting up behaviour representations • designating a set of systems state variables, • associating display elements with appropriate system state variables, • associating control elements with appropriate system state variables, • setting up initial values of system state variables, • implementing constraints between state variables, • defining the behaviour of active items in terms of actions to be propagated dependent on the actual and changed system state variables. For this phase of the design there must be a clear statement of the required interface representation in terms of some system state analysis. The presumption is that good design practice has been followed through a task analysis and a functional analysis of the interface being designed. The data from such analysis is then captured in a behavioural representation of the interface.
vol 29 no 4 may 1987
.
210
120 150
180
Exit Lisp
F~ure 1. Top level access menu to Trillium
90
,
End Session
Toggle Billboard Display
60
em editor: D I A L
MAKE.CHANGE~
I TEt,1. T Y P E D I#,L F' L ,~ I-: E I',1E N T ( 4 L-14 4. E; 5 ) F: ~, D I U :-: 4O F 0 NT ( L-q6 C H ~ i:; ~',r,lE D I U r,1 [5 F: I_1:~:H, :-.:H ,~ P E F: FI U N 13 ,°,RI_I :--:H , ,-,° I '-"E K T I F:_K F' N_,.:,"-' I N :-: I Il E :-: H rl,,,,J, L #',F',E L 2 "?E 2 :-_:H i-i,,,,, ,-' I F:.F:L E ","E::: :-: H fi ,,,,,. T I i-: K :[: '.,.'F :-: :-:t,1#, L L T I F:,'.;:S ':T I I[: K L E N 13T H 9 F:ELL T.F.L~E T. Et,E~F: [ Ni[-; :-]:F: ~ L E '-' 0 t,11 t',l E1 -
r,1A ::'::. ~ T . T U r N F E D L E ',',' [ F'i Y H :.~:T ~ F: T,~ N f-; L E :~.:Y I-I g'~, i"l i.~L E
(!
i
-,
t',lIl '-9 :-',~' 0
Figure 2. An item instance and its associated item characteristic value editor
The state variables are stored in cells which can be associated with display or control entities. The cell values are used as arguments in initialization procedures, inhibition procedures or implication procedures. The procedures are invoked through the use of
211
E l (:~ii l : . [ , I] ~
Tar!]let
Detection
Remaining Targets ~@. ~
-:40
0
!:20
20
I FIL4CEMEIIT
', Z; 4 [_,
] CELL
MAN I F'LIL~TI}F: :-:T;~TE
::00
~
Ilil[ilii
2;:F~
140
:z : - 0
Select Target
,
3o~,*'
--' 1, I--' 2 ~ I
~)
.":::F~
::ii~......ii~!~
~ I',I :.4a l l ~ ; F±N~ [ d ai,
IMF'L!C;~TION "UtL-r, ame,:] l m p ] q , : a r
(if
Target~ Oetected
I • I "J I [~F_'II I1[ e l ~
I I'rEM.T',"PE N~I,1E
. . . .
at'i I1 [.a 0]l-
[o|i [:)':'loli:.l,-$1['I;
(EQ NEW, ',,'~LI_E i: QIJIjTE I~F';4B :, :, then ::H~NGE ;:ELL TmF:GET-: DETECTED , ~DD£ (CELL ',,~LUE T~F:RET:-: DETECTED ) )) CHANGE, CELL NIJI,1BEF:, OF, TnF:q3ET::: (:::I_IB1 (CELL,',,'~LIIE NIIt,IBER,OF T4F:GET:[: 'i I :t I
± f't-,:, r E;ef,Dr'e
E' elmt,:. ~imr7,10i :m '2: ,,. I ,~F t-i ()
( ) ,7H It I II-i,ll,:,
Firld ',vO F:' U-: ~ r:' r'ir-~t -
Range
Edit
........ .............................: :.::.....
E i-tit,_- ,Z,t r-i E:r'eo~
E ai E it
• :: ::~:::~.2~.i:.~g -~ :::i:i:~::~,&;,S.~.~:~.,.;
:::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::
Figure 3. A frame with a set o f instantiated items suitably arranged and aligned
behavioural item types: initializers, inhibitors and implicators. The functioning of these procedures can be changed and modified such that they can test for system state conditions by referencing cell values, perform conditional operations and computations or invoke the further activity of other items and frames within the interface. In addition to these specific behavioural item types, active item types (such as those whose composition includes one or other of the various item type sensors) can invoke further additional procedures through the use of embedded procedural code in the primitives or functions defined in the compositions. A large number of the active item types have their behaviour determined in this way by the particular specification features e.g. push-buttons, rotating knobs etc. Finally, all active item types have a tailorable behaviour, whereby modification by the designer of a characteristic called its action form can generate alternative behaviour representation. It is at this level of specifying behaviour that the environment is most powerful and flexible (See Figure 4). o Task 5: appraising interface performance • testing the individual items to verify their behaviour, • examining the links between items and frames and their behavioural components for initialization, constraint, propogation and action. At this stage, the designer is attempting to verify the
212
Figure 4. An implicit item type." implication showing its characteristic value and its associated action form editor
performance of his/her interface to ensure the representation is correct. A variety of tools are at the designer's disposal to provide graphic representations of the following (See Figure 5): inter-frame and inter-item relations, • enumerations of frames, • selective display of frames,
•
I | (:1 i i i d . j Z 1 o] i l l l ; ' l ]
b i l L - -
i i : ] i i [ : - i l II:];,r, |:-I ( I ml~i (':T~ q[~] d
T~Rn-4ET, BEnF:INF4
L I N F . FJF, TE:,::T LINF,
OF, TEXT
I NEt [ C , ~ T O R - -
TnF:~3ET,F:nNGE
INDICnTEF'
GEt.IE;I~L. BUTTON
F'F: I N T. F:E I~ [ I-~N
NIJMBEF:. OF. T;~F:L-qET:_:
:-: I r,lF'LE P F:FIP i-i F~~ T i i R - = - - - -
_-- T;~RI}E T. SELEL-:TED ~NIIMBER !
t
F'R I N T . F:EG I ON B L O C K . OF. TEXT ] r,1p L I C ~ T [ Fj N
I ~tl ,I2L-
I
, ,_,I.-L~.-I-'
FIF T;~R~qET:-_ I L.L.'
{TnF:GET. :::ELECTEOJ
B L O C K . OF. TE:':T - - T~F:ISE T, F:;4.JG E
P F: I N T. F'E ;_41ij N LINE OF.TEXT I t,1F'L l *-:~ T I FlN F' F: [ N T. R E G l L-tN B L 1_-tF_:h . 0 F T E :': T
-
t,l~N
IPUL~TIZIF:. :[:TZ~TE
T;~F:GE T:[:. D E T E C T E D
FF:¢MF. LO;HPEF:
Figure 5. Working tool in Trillium." a graph of the item structure in a j~'ame
information and software technology
applications • enumeration of items currently in use in a frame, • enumeration of current characteristic values of items, • trace facilities to show the dynamics of a running interface frame, • display of current system state variables and their values. ~ Task 6: completing the design session • assign objects, interfaces frames and items, to a filing system separate from the current environment, • cleaning up the environment to dispose of unwanted objects and the filing of objects to a suitable file structure for future use and retrieval. The environment deals with the different constituent parts interfaces, frames and items, as objects. The supporting filing system enables all these objects to be selectively allocated and filed in a file structure determined by the working style of a designer or collaborative group of designers.
enabling alternative or successive iterations of the design to be appraised by clients, by systems designers, by human factors specialists and by the end user of the interface itself. Such appraisals and iterations are all desirable steps in enhancing the design of a man-machine interface.
Acknowledgements This outline of Trillium is directly derived from the work of its originator, Austin Henderson of Xerox Parc. Due recognition is made of this original work together with grateful acknowledgement for many fruitful discussions with him during the process of developing Trillium into a supportable and marketable software tool for new interface development. Other designers and programmers actively using Trillium in the Xerox community have also greatly facilitated the authors understanding: for their contribution the author is also grateful.
References Conclusion The Trillium environment provides a means of interactively designing user interfaces through the exploitation of some key abstractions from the language of interface design and using the notion of functioning frames as the basic representational style. Its power lies in the virtual machine representation and its interface which facilitates easy and rapid changes to both the surface and the behavioural representation. Such a representation medium facilitates design prototyping by
vol 29 no 4 may 1987
1 Henderson, D A 'The Trillium user interface design environment' Proc. CHI '86 (April 1986) pp 221 227 2 Hopgood, F R A and Duee, D A 'A production system approach to interactive graphic program design' Methodology of Interaction (Eds Guedj, R A et al) North-Holland, The Netherlands pp 247-263 (1980) 3 Waterman, D A 'Exemplary programming in RITA' Pattern Directed Inference Systems (Eds Hayes-Roth, D and Waterman, D A) Academic Press pp 261--279 (1978) []
213
Abstract: Trillium was originally developed at Xerox Parc. A UK company has undertaken a number o f so[tware refinements. This paper looks at the history ~[ the design tool and how it can be used in today's environment. Keywords : so[tware techniques, man-machine interlace, software
directly by referring to them by name, by working with their representations on a graphics screen, and observing and modifying the behaviour and interactions of the associated interface elements.
Interface exploration and design tool requirements
mana gement.
n the early development of ergonomic practice, the traditional methods of interface design were derived from engineering drawing office practice. This was accompanied by painstaking drawing of displays and controls of machines with little opportunity for evaluation or exploration of the interfaces usability. The interface in most cases was perceived as an extension of the machine, its features largely determined by the technology and its current limitations. The advent of computer systems encouraged their use in the design of interfaces through the process of interface simulations. These simulations enabled the interface's characteristics to be examined in advance of its actual building and facilitated exploration and empirical study of user interaction and user performance. The difficulty with this approach lay in the long time taken to encode the interface into the programming language of the target computer system chosen for the interface simulations. This paper examines one design tool called Trillium originally developed at Xerox Parc in the USA 1. Trillium attempts to circumvent difficulties of user interaction to a significant extent by allowing the user to deal with manmachine interface design constructs directly, these constructs being derived from the language of interface design. With Trillium, the designer is able to manipulate a representation of an interface's constituent components
I
Artificial Intelligence Ltd, Intelligence House, Merton Road, Watford, Herts WDI 7BY, UK
vol 29 n o 4 m a y 1987
The primary function of an interface is to provide the end user of a machine system with a 'map' of the tasks he/she is expected to perform when using the system. Good interfaces establish coherent and easily perceivable models of the system under control. The system user is always trying to build cognitive models of both the process/system he/she is controlling and to develop notions about the structure of the particular task in hand. If badly designed interfaces are implemented, they inhibit the development of these cognitive processes and, as a consequence, yield poor performance, give rise to errors and increase the possibility of system failure. Typically, the designer of a man-machine interface is confronted with these issues which must be resolved within a given set of technical constraints as well as within the usual limits of time, design resources and cost of implementation. To satisfy the needs of a designer or human factors oriented specialist, a man-machine interface design tool should attempt to accommodate the expertise at their level rather than involve him/her in the acquisition of a range of new supporting skills and abilities, such as writing computer programs. In summary, the top level requirements of a good manmachine interface (MMI) prototyping environment are that it should facilitate a rapid design cycle time to allow explorations through iterative design. MMI should not require the user to engage in programming. The interface design should be representable in terms which a designer understands rather than terms which a programmer understands. MMI should represent the dynamics of the interface. A good design tool should give both surface and
0950-5849/87/040207-07503.00 6") 1987 Butterworth & Co (Publishers) Ltd.
207
behavioural representations of the interface. This requirement is essential because many human factors issues are conditioned by how the interface elements behave and interact with one another as well as by their actual surface appearance.
vehicles, consumer products and process control systems. Its flexibility is such that is can create interface representations for both hardware components of interfaces as well as software generated displays - text, graphics, windows and menus.
Development of Trillium
Some relevant abstractions
Xerox Parc
To satisfy the requirements of a good MMI prototyping tool, directing the functionality at the design process means that certain related abstractions must be encompassed and for the class of interface that Trillium is primarily concerned with there is a particular set of abstractions which is used to develop and represent interfaces.
At Xerox, the increasing complexity of product ranges, occasioned by new technology and increasing sophistication of the controls and displays meant that machine operability became a live issue. The problem was how to develop user interfaces which could be evaluated in terms of their operability in advance of a prototype or completed product. Means had to be found to develop the interfaces so that there could be a number of iterations of the design cycle, involving designers, system developers and users in the design appraisal process. At Xerox Parc, Henderson 1 initiated the concept of prototyping using functioning Frame interfaces which resulted in Trillium being developed as a design tool. This exploited the power and flexibility of a powerful personal workstation supported by bitmapped graphics, mouse and window facilities. The early versions of Trillium were released into the Xerox design environment in 1983 and, since then, a community of users on key sites in the USA and also in the UK have been active in the use of Trillium as a design development tool. Currently the Trillium software runs on a Xerox 1186 workstation with 1NTERLISP-Das the supporting environment, with a configuration requirement of 3.7Mbyte of memory with virtual memory capacity up to 16Mbyte being utilized.
Current software The prototype Trillium system has been supported from within the Xerox community with progressive enhancements and releases such that it is making a significant contribution to product design implementation within Xerox. The more general availability of Trillium which has been undertaken by Artificial Intelligence Limited has involved some refinements to the software, documentation at the users and support level.
Range of applications Trillium encompasses both traditional hardware implemented interfaces and software driven screen display interfaces. The domains in which it can be usefully applied are interfaces for instrument systems, military systems,
208
Interfaces The notion of an interface derives from the historical traditions of human factors whereby both the information displayed and the information acquired by the system through interaction in the man-machine loop is considered separate from the machine system under control. The separation has been driven by the concept that only in this way can the abilities and limitations of the user be taken into account. This separateness endorses the notion that interface design is governed by a different set of constraints to those appertaining to the actual system or process itself. Parenthetically, the advent of computer based systems and the detailed study of human computer interaction has introduced the notion of a dialogue 2'3. This notion of dialogue is sometimes substituted for the concept of the interface. Screen based interfaces being window and menu based are more ephemeral than hard interfaces comprising knobs, buttons and dials. They are therefore probably well described by the term dialogue. But in effect, any man-machine interaction is in the form of a dialogue by way of information exchange between man and machine. The term interface is probably the best abstraction to represent the nature of the man-machine links. The term dialogue might perhaps better be reserved for the representation of the actual set of exchanges which take place across the interface.
Frames A single physical manifestation of the interface is not sufficient for representing interfaces of any substance or utility. Multiple representations of an interface are often desirable and for this purpose the abstraction of a functioning frame is used. In Trillium, any interface comprises a collection of functioning frames which can represent interface func-
information and software technology
applications tionality required to set up, operate and maintain the target machine system at which the interface design is directed. Frames may have the capability of being presented in a screen window one at a time i.e. in serial fashion, or be presented simultaneously i.e. in parallel. In developing an interface, the designer must create a suitable frame structure to represent the manner in which the virtual machine system will be operated upon and controlled by the interface. Thus, the functioning frames give alternative perspectives of the machine control in different state conditions.
Items Each frame contains a set of constituent elements which are the representations required for the user/system interaction to take place. The constituent elements of a frame are termed 'items' and it is the items in a frame with which the user interacts by either assimilating information (display items) or providing information (control items). Further items are also required to give the interface appropriate dynamic behaviour.
Item types To create an item, a repertoire of items, styled 'itemtypes', is required. These are prototypes for the items themselves and incorporate a specific set of characteristics for any given item. An item is therefore an instantiation of an item-type, with designated values for its particular characteristics.
Kinds qf item O'pes The repertoire of item types requires differentiation into different 'kinds' in order to be able to express different design features. The kinds of item required are: • artwork to represent graphic appearance, • displayers to present dynamic information, • sensors to assimilate operator control action. These three basic kinds give explicit representation of the interface. At another level, three further kinds of item types are required to represent behaviour: • initializations to set the initial state of the interface, • inhibitions to constrain the behaviour, • implications to propagate changes throughout the interface and machine representations. These kinds constitute the working set of primitives in Trillium.
vol 29 no 4 may 1987
Item characteristics and values Each item is endowed with a set of'characteristics' which uniquely identify it as a particular type of item and the characteristics in turn have values which distinguish one item from other similar items.
Functions of Trillium The set of item types in Trillium comprise the primitives and compositions of those primitives from which the interface and its associated machine representations are constructed through the instantiation of an appropriate set of items. At the bottom level, all the functioning of the interface representation is displayed entirely through the functional code of the Trillium primitives. Each frame before it is run for the first time is analysed down to the constituent primitives of all the items in the frame. This analysis is then saved and used on each subsequent occasion when the frame is run in a given loaded interface. Maintaining the coherence of all the primitives is 'the Trillium machine' which runs the interface through the process of analysis and subsequent interpretation. The structure which links this analysis and interpretation process to the interface specification (using the item type and frame abstractions) is the state representation which is based on a series of cells. Each cell contains a value pertinent either to an interface element state or to one of a set of state variables representing the machine that the interface is controlling. As well as maintaining and monitoring this state representation, the Trillium machine also maintains a frame stack which chronicles the transitions from one frame to another as the interface is run by the operator or the designer. Continuous monitoring of the state variables represented by cell values enables the Trillium machine to detect state changes and then, through its knowledge derived from its analysis of the interface and its constituent frames, it is able to propagate all the consequential changes. In doing so it takes into account the constraints, initializations and the characteristics of the individual items specified by the designer of the interface.
Scenarios In use, Trillium acknowledges different types of user who will interact with the software. In support of the design operations, it acknowledges a set of protocols which are available to explore the design through manipulation at the item, frame and interface level. These protocols are by way of either support protocols or major design protocols.
209
Trillium users Different individuals with different skills are potential users of the Trillium environment and different styles of interaction are required to enable these different types of user to interact appropriately. Four different types of user interaction can be identified. Enduser interaction. This is the interaction mode where, the interface design having been completed, a typical set of end users interact with the interface to test its operability. All the functionality required for the final interface to the system is available to the end user, but there is no way in which he/she can modify the characteristics of the interface as such, the user can only interact with the interface in its running operational mode. Designer mode interaction. In this mode, the environment is used to explore the design to develop a particular interface. The designer may be a design engineer, an industrial designer or a human factors specialist. The necessary capability at this level is provided to set up, change, edit, modify, extend, save, restore and create all of the objects necessary to build an interface representation: interfaces, frames and items. Programmer (supporter) mode. In this mode, the concern is not only with developing the interface but with the specification and implementation of the entities used to build up interfaces, most particularly item-type creation enhancement and extension. The use of the environment at this level is not program independent; some detailed knowledge is required of the programming language (INTERLISP-D)in which the environment is implemented. System developer mode. This level of interaction is not strictly a user mode. It is the development and modification of the environment itself as opposed to the previous mode where it is the manipulation of the entities which is involved in the user interaction. Interactions at this level involve fundamental changes in the way in which the Trillium environment is configured and the way in which it operates, deals with and runs interfaces.
Prototypical use o / the environment Typical use of the environment involves a set of principle design protocols for manipulating the interface design at the item, frame and interface level. These principle design protocols are supplemented by a set of complimentary supporting protocols. These enable the designer to specify his/her working style and manage his/her work through saving, retrieving and sharing designs in successive design sessions. Supporting protocols are available for preliminary operations such as creating, naming, saving and retrieving interfaces. They can set up the interaction style of the
210
environment in terms of such features as user mode, editing style, menu structure and display/redisplay protocols. Supporting protocols are also available for saving and retrieving all the objects such as interfaces, frames and items from a design session. Finally, supporting protocols are available for utilities used within a frame to save, retrieve and transfer individual items and groups of items within the interfaces being manipulated in the current design session. Such operations are capable of being freely interspersed with other current design activities.
Design session scenario Typically, a design session scenario for creating and evaluating an interface consists of a series of interactions with the environment, involving some preliminary operations, the generation of basic surface representation, refining of the surface representation, setting up the behaviour representation and evaluating and running the interface. An activity cycle for such a design session might be as follows: ,~ Task 1: preliminary operations • designating an interface name, • opening a display window for the interface, • locating and sizing a screen window, • creating an initial frame for the interface. These operations are enabled through the use of the top-level menu of the environment (See Figure 1). (~ Task 2: generating basic surface representation • selecting items from a library of item types, • modifying the appearance of the items by editing their characteristic values. These activities involve the use of a menu to invoke selections from a classified set of all the differing items available (around 100 in the basic system) and the use of characteristic value editor. This enables all the values to be modified, regardless of whether the data type is numeric, symbolic, text or pictorial, by automatically invoking a suitable value editor (see Figure 2). ~ Task 3: refining the surface representation • reshaping and sizing the interface items, • relocating and aligning interface items. A series of utility functions, again invoked by menu selection, enables the currently displayed frame items to be reshaped and resized, alignments can also be made along any specified reference points or edges or items to be
~
information and software technology
applications Open I n t e r f a c e
0
Window
330
Create New Object Copy O b j e c t
30
300
I
Delete O b j e c t Add O b j e c t s to I n t e r f a c e Remove Objects from Interface S h o w O b j e c t s on I n t e r f a c e
270
Edit Item T y p e s Edit User Profile
240
Loading and Saving Files
matched in terms of their basic bounding dimensions of width and height. In addition, for precise determinations, pixel based dimensions can be derived for element sizes and separations. At this phase the designer has a simple surface representation of the interface which is essentially static in nature (Figure 3). The subsequent steps introduce behaviour into the interface. o Task 4: setting up behaviour representations • designating a set of systems state variables, • associating display elements with appropriate system state variables, • associating control elements with appropriate system state variables, • setting up initial values of system state variables, • implementing constraints between state variables, • defining the behaviour of active items in terms of actions to be propagated dependent on the actual and changed system state variables. For this phase of the design there must be a clear statement of the required interface representation in terms of some system state analysis. The presumption is that good design practice has been followed through a task analysis and a functional analysis of the interface being designed. The data from such analysis is then captured in a behavioural representation of the interface.
vol 29 no 4 may 1987
.
210
120 150
180
Exit Lisp
F~ure 1. Top level access menu to Trillium
90
,
End Session
Toggle Billboard Display
60
em editor: D I A L
MAKE.CHANGE~
I TEt,1. T Y P E D I#,L F' L ,~ I-: E I',1E N T ( 4 L-14 4. E; 5 ) F: ~, D I U :-: 4O F 0 NT ( L-q6 C H ~ i:; ~',r,lE D I U r,1 [5 F: I_1:~:H, :-.:H ,~ P E F: FI U N 13 ,°,RI_I :--:H , ,-,° I '-"E K T I F:_K F' N_,.:,"-' I N :-: I Il E :-: H rl,,,,J, L #',F',E L 2 "?E 2 :-_:H i-i,,,,, ,-' I F:.F:L E ","E::: :-: H fi ,,,,,. T I i-: K :[: '.,.'F :-: :-:t,1#, L L T I F:,'.;:S ':T I I[: K L E N 13T H 9 F:ELL T.F.L~E T. Et,E~F: [ Ni[-; :-]:F: ~ L E '-' 0 t,11 t',l E1 -
r,1A ::'::. ~ T . T U r N F E D L E ',',' [ F'i Y H :.~:T ~ F: T,~ N f-; L E :~.:Y I-I g'~, i"l i.~L E
(!
i
-,
t',lIl '-9 :-',~' 0
Figure 2. An item instance and its associated item characteristic value editor
The state variables are stored in cells which can be associated with display or control entities. The cell values are used as arguments in initialization procedures, inhibition procedures or implication procedures. The procedures are invoked through the use of
211
E l (:~ii l : . [ , I] ~
Tar!]let
Detection
Remaining Targets ~@. ~
-:40
0
!:20
20
I FIL4CEMEIIT
', Z; 4 [_,
] CELL
MAN I F'LIL~TI}F: :-:T;~TE
::00
~
Ilil[ilii
2;:F~
140
:z : - 0
Select Target
,
3o~,*'
--' 1, I--' 2 ~ I
~)
.":::F~
::ii~......ii~!~
~ I',I :.4a l l ~ ; F±N~ [ d ai,
IMF'L!C;~TION "UtL-r, ame,:] l m p ] q , : a r
(if
Target~ Oetected
I • I "J I [~F_'II I1[ e l ~
I I'rEM.T',"PE N~I,1E
. . . .
at'i I1 [.a 0]l-
[o|i [:)':'loli:.l,-$1['I;
(EQ NEW, ',,'~LI_E i: QIJIjTE I~F';4B :, :, then ::H~NGE ;:ELL TmF:GET-: DETECTED , ~DD£ (CELL ',,~LUE T~F:RET:-: DETECTED ) )) CHANGE, CELL NIJI,1BEF:, OF, TnF:q3ET::: (:::I_IB1 (CELL,',,'~LIIE NIIt,IBER,OF T4F:GET:[: 'i I :t I
± f't-,:, r E;ef,Dr'e
E' elmt,:. ~imr7,10i :m '2: ,,. I ,~F t-i ()
( ) ,7H It I II-i,ll,:,
Firld ',vO F:' U-: ~ r:' r'ir-~t -
Range
Edit
........ .............................: :.::.....
E i-tit,_- ,Z,t r-i E:r'eo~
E ai E it
• :: ::~:::~.2~.i:.~g -~ :::i:i:~::~,&;,S.~.~:~.,.;
:::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::
Figure 3. A frame with a set o f instantiated items suitably arranged and aligned
behavioural item types: initializers, inhibitors and implicators. The functioning of these procedures can be changed and modified such that they can test for system state conditions by referencing cell values, perform conditional operations and computations or invoke the further activity of other items and frames within the interface. In addition to these specific behavioural item types, active item types (such as those whose composition includes one or other of the various item type sensors) can invoke further additional procedures through the use of embedded procedural code in the primitives or functions defined in the compositions. A large number of the active item types have their behaviour determined in this way by the particular specification features e.g. push-buttons, rotating knobs etc. Finally, all active item types have a tailorable behaviour, whereby modification by the designer of a characteristic called its action form can generate alternative behaviour representation. It is at this level of specifying behaviour that the environment is most powerful and flexible (See Figure 4). o Task 5: appraising interface performance • testing the individual items to verify their behaviour, • examining the links between items and frames and their behavioural components for initialization, constraint, propogation and action. At this stage, the designer is attempting to verify the
212
Figure 4. An implicit item type." implication showing its characteristic value and its associated action form editor
performance of his/her interface to ensure the representation is correct. A variety of tools are at the designer's disposal to provide graphic representations of the following (See Figure 5): inter-frame and inter-item relations, • enumerations of frames, • selective display of frames,
•
I | (:1 i i i d . j Z 1 o] i l l l ; ' l ]
b i l L - -
i i : ] i i [ : - i l II:];,r, |:-I ( I ml~i (':T~ q[~] d
T~Rn-4ET, BEnF:INF4
L I N F . FJF, TE:,::T LINF,
OF, TEXT
I NEt [ C , ~ T O R - -
TnF:~3ET,F:nNGE
INDICnTEF'
GEt.IE;I~L. BUTTON
F'F: I N T. F:E I~ [ I-~N
NIJMBEF:. OF. T;~F:L-qET:_:
:-: I r,lF'LE P F:FIP i-i F~~ T i i R - = - - - -
_-- T;~RI}E T. SELEL-:TED ~NIIMBER !
t
F'R I N T . F:EG I ON B L O C K . OF. TEXT ] r,1p L I C ~ T [ Fj N
I ~tl ,I2L-
I
, ,_,I.-L~.-I-'
FIF T;~R~qET:-_ I L.L.'
{TnF:GET. :::ELECTEOJ
B L O C K . OF. TE:':T - - T~F:ISE T, F:;4.JG E
P F: I N T. F'E ;_41ij N LINE OF.TEXT I t,1F'L l *-:~ T I FlN F' F: [ N T. R E G l L-tN B L 1_-tF_:h . 0 F T E :': T
-
t,l~N
IPUL~TIZIF:. :[:TZ~TE
T;~F:GE T:[:. D E T E C T E D
FF:¢MF. LO;HPEF:
Figure 5. Working tool in Trillium." a graph of the item structure in a j~'ame
information and software technology
applications • enumeration of items currently in use in a frame, • enumeration of current characteristic values of items, • trace facilities to show the dynamics of a running interface frame, • display of current system state variables and their values. ~ Task 6: completing the design session • assign objects, interfaces frames and items, to a filing system separate from the current environment, • cleaning up the environment to dispose of unwanted objects and the filing of objects to a suitable file structure for future use and retrieval. The environment deals with the different constituent parts interfaces, frames and items, as objects. The supporting filing system enables all these objects to be selectively allocated and filed in a file structure determined by the working style of a designer or collaborative group of designers.
enabling alternative or successive iterations of the design to be appraised by clients, by systems designers, by human factors specialists and by the end user of the interface itself. Such appraisals and iterations are all desirable steps in enhancing the design of a man-machine interface.
Acknowledgements This outline of Trillium is directly derived from the work of its originator, Austin Henderson of Xerox Parc. Due recognition is made of this original work together with grateful acknowledgement for many fruitful discussions with him during the process of developing Trillium into a supportable and marketable software tool for new interface development. Other designers and programmers actively using Trillium in the Xerox community have also greatly facilitated the authors understanding: for their contribution the author is also grateful.
References Conclusion The Trillium environment provides a means of interactively designing user interfaces through the exploitation of some key abstractions from the language of interface design and using the notion of functioning frames as the basic representational style. Its power lies in the virtual machine representation and its interface which facilitates easy and rapid changes to both the surface and the behavioural representation. Such a representation medium facilitates design prototyping by
vol 29 no 4 may 1987
1 Henderson, D A 'The Trillium user interface design environment' Proc. CHI '86 (April 1986) pp 221 227 2 Hopgood, F R A and Duee, D A 'A production system approach to interactive graphic program design' Methodology of Interaction (Eds Guedj, R A et al) North-Holland, The Netherlands pp 247-263 (1980) 3 Waterman, D A 'Exemplary programming in RITA' Pattern Directed Inference Systems (Eds Hayes-Roth, D and Waterman, D A) Academic Press pp 261--279 (1978) []
213