Transcript
Page 1: An interface prototyping system based on Lean Cuisine

An interface prototyping system based on Lean Cuisine

P S Anderson* and M D Apperleyt

Lean Cuisine, an interface design notation derived from a study of the behaviour of menu systems is examined as the basis for a prototyping environment for direct manipulation interfaces. By using the Seeheim model for user interface management systems to categorize the model information that can be extracted from a Lean Cuisine specification, it is shown that a description of both the action and control layers can be derived. The direct implementation of these layers from a Lean Cuisine specification is described.

Keywords: Interface design tools, interface design techniques, rapid simulation, prototyping

Prototyping has long been recognized as an essential requirement in the development of interfaces (Jones, 1970). For direct manipulation (DM) inter-

faces, with their high degree of interaction, it is suggested that the requirement

for prototyping tools is even more important. Basic to such a development approach is a design notation independent of the implementation and capable of describing all the component parts of the interface. The Seeheim model (Green, 1985; 1986) for user interface management systems (UIMS) recognizes three distinct layers within interfaces:

l the action layer, responsible for interaction at the lexical level 0 the control layer, responsible for implementing the syntax of the interface

dialogue l the application layer, through which application routines are invoked and

interact with the interface; the semantic level

A number of design notations have been described in the literature, but an examination within the context of the above model indicates various shortcom- ings. Some notations deal with only one layer; user action notation (Siochi and

Department of Computer Science, Massey University, Private Bag, Palmerston North, New Zealand, YTel: (063) 69499 Ext.7441. E-mail: Internet: P. Anderson @massey.ac.nz Janet: [email protected] tTelephone: (063) 69-099 Ext.8021. E-mail: Internet: M. [email protected] Janet: M. [email protected]

0953~5438/90/010217-10 0 1990 Butterworth-Heinemann Ltd 217

Page 2: An interface prototyping system based on Lean Cuisine

Hartson, 1989) is an example. Other notations deal with just two layers; Mickey (Olsen, 1989) describes only the action and application layers, without mention of the control layer. Prototyping environments, for example the Macintosh Prototyper* also fall into this category. Other notations including transition networks and their more compact variants such as Statecharts (Harel, 1987; Wellner, 1989) have also been applied, but these have been developed to deal with event-driven systems in general, rather than direct manipulation inter- faces in particular, and lack facilities to describe the inherent asynchronous nature of the latter.

In contrast to these techniques that have been ‘imported’ into the HCI area, Lean Cuisine (Apperley and Spence, 1989) is a notation derived from a study of the behaviour of menu systems. It offers a clear, concise and compact notation, which in its present form can be used to describe both the action and control layers of hierarchical menu systems. It has been suggested that its use could be extended to describe other dialogue types within DM environments. With this in mind, the Lean Cuisine notation has been used as the basis for an interface prototyping evironment, in order better to assess its applicabili~ and extension to other dialogue forms. This paper describes the notation, and development of this prototyping environment which provides for the direct implementation of the action and control layers from a Lean Cuisine description.

Lean Cuisine notation

Lean Cuisine has been deveIoped as a means of describing the behaviour of hierarchical menu systems (Apperley and Spence, 1989). A menu can be modelled as a list of Boolean choices called ‘menemes’. Each meneme has an associated event corresponding to its selection by the user. They generally exhibit bistable behaviour, in that their selection causes them to be toggled between two states, set and cleared. Menus or submenus form one of two basic types; choices can be one-from-many, a mutually exclusive (ME) set, or many-from-many, a mutually compatible (MC) set. Each menu has a header or parent meneme, allowing hierarchies of interconnected menus to be con- structed. With its notion of interlinked sets of named menemes, each set having either ME or MC behaviour, Lean Cuisine can be readily represented in graphical form as a tree. The branches of the tree represent the meneme sets, and the form of these branches represents their behaviour; vertical for ME, horizontal for MC (see Figure I).

Some individual menus contain two or more behavioural groups. In order to model such menus Lean Cuisine uses the concept of virtual menemes. These are the parent menemes of groups exhibiting different behaviour but occuring in the same menu or presentation grouping. Virtual menemes are shown by enclosing their names in braces (eg {A}, {D} and {F} in Figure 1).

FinaIIy, in some menus there may be a requirement that a choice always be present, in which case one of the constituent menemes will be identified as a

‘Macintosh is a trademark of Apple Computer Inc. Prototyper is a trademark of SmethersBames and SmethersBames Publishing Division.

218 Interacting with Computers vol2 no 2 (2990)

Page 3: An interface prototyping system based on Lean Cuisine

X

Y

, Z

t

G

H

Figure 1. Example of Lean Cuisine description of system of menus

default choice. In Lean Cuisine, required choice groups are identified by the parent meneme being marked Q, and default menemes are marked *.

Action layer

The information necessary to construct the action layer consists of the primitive user actions and the associated graphical prompts and feedback. Systems such

Anderson and Apperley 219

Page 4: An interface prototyping system based on Lean Cuisine

as the Macintosh supply routines (in the toolbox) that support standard styles of event handling, and graphical representations of conventional objects such as pull-down menus, icons, windows, etc. Hence, in the simplest case, only the information necessary to construct these objects is required, with the standard software routines used to handle the user interaction. This has the advantage of ensuring consistency in interface style between applications which is un- doubtedly a desirable feature.

Given a Lean Cuisine specification, one can readily construct the menus that it represents. Each meneme has a unique name, which is used as the item name in a menu. Menemes have a specified ordering within their set, the ordering being the same as that within the menu that the set represents. Submenus are easily constructed since their insertion point in the parent menus is specified and their composition defined.

Virtual menemes represent groups of menemes in the same menus, but exhibiting a difference in behaviour. Often some form of visual cue is needed to show the user where such groups begin and end. A horizontal dashed line can be inserted for this purpose.

Figure 2 shows the translation of a simple Lean Cuisine specification ((a) and (b)) to an intermediate presentation specification (c). This presentation can be readily parsed and a set of hierarchical menus (d) constructed from it using a recursive algorithm. In the intermediate presentation specification each sub- menu is delimited by < > representing moves down and up in the nesting hierarchy. The beginning and end of virtual sets are indicated with ‘(-‘, which within the Macintosh toolbox routines equates to a horizontal line between items. Title menemes are repeated, occuring both in their position within their parent set, and as the first meneme within their child grouping.

Control layer

A major feature of the Lean Cuisine notation is its ability to describe interactions between menemes. Within the context of the Seeheim model such interactions are handled within the control layer. Because of the inherent asynchronous nature of these interactions, an event-response system (ERS) is an ideal formal model to describe them (Hill, 1987a). The input to the ERS is a high level event from the action layer identifying the meneme that has been selected from a menu. This can then be processed by the ERS in order to model the meneme interdependences. If the control layer is to be specified, then it is necessary that the ERS model can be directly derived from the Lean Cuisine specification.

Event-response systems

Hill (1987a) proposed the use of an ERS based on the concepts of production systems. Such systems are a form of automata consisting of three components:

l an event response loop a a memory containing a set of Boolean flags describing the state of the

interface

220 Interacting with Computers ~012 no 2 (1990)

Page 5: An interface prototyping system based on Lean Cuisine

(StyleS.ME. (Plain*, (lFancyJ,MC.

(Bold, Italic, (Font.ME,

(Geneva, Times)

)):’

b

Style §

t

Plain’

IFancy

Bold Italic Font

I Geneva

Times

a

Style Plain (- Bold Italic Font < Font Geneva Times >

(-

.

bold I

C d

Figure 2. (a) Lean Cuisine specification, and (b) its translation from a textual description to: (4 equivalent presentation model and cd) resultant menu

l a set of rules relating events and current flag values to new flag values

The rules are evaluated within an event response loop against the contents of the flag memory. Those rules that match the current state of the memory and the current event, are marked and subsequently fired, changing the state of some of the flags within the memory.

An ERS contains two types of rules: Regular rules of the form

e : Fr -> F2

where e = the current event

Anderson and Apperley 221

Page 6: An interface prototyping system based on Lean Cuisine

Fi = the set of flags in memory which must be TRUE for the rule to be fired, and which will be reset to FALSE when the rule is fired. F2 = the set of flags that are to be set when the rule is fired. ~-rules of the form:

E : Fi -> F2 which behave in exactly the same way as regular rules, but do not include an event. Hill (1987b) has shown that an ERS can be shown to be equivalent to a finite

state automata. In order to accommodate the Lean Cuisine concepts, some modification has

been needed to Hill’s notation. A variant of the ERS notation has been devised, called a modified event-response system (MERS). Like ERSs, MERSs also consist of regular and s-rules, however they differ in their method of rule interpretation and effect. The lists of flags within MERS rules not only identify the flags but also their state (i.e. set or unset). A regular rule is said to match if its event matches the current event, and all the F1 flags match their state specified in the rule; the same reasoning can be applied to s-rules. When either type of rule is fired, the F2 flags are set to the states specified in the rule, but the Fi flags are not cleared as they are in an ERS.

Translation process

Associated with each real meneme is an event that corresponds to the user’s selection. As a consequence of the bistable nature of menemes, two rules are associated with each meneme, corresponding to the setting and clearing of the meneme respectively.

In setting a real meneme, side effects are possible and have to be considered. If the meneme is a member of a mutually exclusive set, then all the other members of the set need to be cleared. However, side effects can carry very much further than just the set within which the meneme is located. Setting a meneme within a menu with a virtual parent has the effect of setting the parent. Hence, effects are propagated up the meneme tree through virtual menemes.

Consider the Lean Cuisine tree represented in Figure 1. The effect of setting meneme H will be to:

0 clear G (member of mutually exclusive set) 0 set F (virtual parent) 0 clear E (member of a mutually exclusive set contain F) 0 set D (virtual parent) l clear A (member of a mutually exclusive set containing D)

Because it is a real meneme, Z is unaffected. Hence the effects do not propagate further up the tree and Y is unaffected.

Taking the above example, the following regular rule describes the outcome of selecting H

h:j?->HGEA

222 Interacting with Computers vol2 no 2 (1990)

Page 7: An interface prototyping system based on Lean Cuisine

The virtual menemes F and D are not included in this rule since they are on the direct line of ascent from H; their substitution as described below would simply result in duplication.

The effect of clearing a virtual meneme (e.g. A in Figure 1) is to generate further changes which propagate down through the associated subtrees until stopped by real menemes. The virtual subtree A can be included by replacing A with real flags using the following substitution rule

A:=B.C

Carrying out this substitution the following regular rule is produced

--- - h:k>HGEBC

From the above analysis, the following general principle for generating the rule corresponding to the direct excitation of real meneme can be derived.

Direct excitation of a real meneme when it is in the cleared state gives rise to one regular rule of the form

x:x->XY

where X is the meneme directly exicted by event x. Y is the set of menemes that are members of mutually exclusive sets

occurring within the enclosing real set and excluding X. Any virtual menemes occurring in Y will be substituted as described above, this process being repeated until no further virtual menemes remain.

Direct excitation of a meneme in the set state, the act of clearing it, produces no side effects (except for those associated with default menemes in required choice groups described below), hence a rule of the following form is sufficient:

x : x -> x

Within a Lean Cuisine specification there are facilities to allow a meneme to be defined as a default choice, and the set of which it is a member to have a qualifier forcing a required choice. Menemes that are a default need to be set at interface initialization (in the implementation, meneme flags are intially cleared). To enable this to be done a dummy STARTUP event can be used that is only matched at initialization, one regular rule being meneme

generated for each such

STARTUP : x- > X

Finally, examining the behaviour of default menemes in required choice groups further, some means of setting the default menemes in response to all the flags within the group being cleared is neccessary. In order to carry out this action, an e-rule of the following form is needed

Anderson and Apperley 223

Page 8: An interface prototyping system based on Lean Cuisine

:XY ->x

where X is the default meneme Y is the set of all menemes within the same group as X but excluding X,

Again, any virtual menemes appearing in the resultant rule will be replaced by

substitution.

Lean Cuisine environment

The protoptying environment described above has been implemented on an Apple Macintosh as two programs:

l The first takes a Lean Cuisine specification in textual form and outputs an interface definition file (IDF) (see Figure 3). This contains two components; a description of the menus as suggested in the action layer model, delimited

I

###I ______ _______ ____ LC SPEC __**_____________

### ~StyleS,ME,(Plain*,((Fancy],MC,(Bold.ltalic,(Font,ME,(Geneva,Times)))))) ### _____________________-__________________*_*

%% Style Plain

(- Bold Italic Font < Font Geneva Times >

(- $8 ### Regular Rules: STARTUP : [Plain] -> Plain bold : Bold -> [Bold] bold : [Bold] -> [Plain] Bold font : Font -> [Font] font : Font] -> [Plain] Font geneva : Geneva -> [Geneva] geneva : [Geneva] -> [Times] Geneva italic : Italic -> [Italic] italic : [Italic] -> [Plain] Italic plain : Plain -> [Plain] plain : [Plain] -> [Font] [Italic] [Bold] Plain times : Times -> ITimes] times : (Times] -> [Geneva] Times ### E-rules:

: [Font] [Italic] [Bold] [Plain] -> Plain

Figure 3. Interface definition file corresponding to menu of Figure 2

224 Interacting with Computers ad 2 no 2 (19901

Page 9: An interface prototyping system based on Lean Cuisine

by */o*/o, and the MERS rules that model the control layer (note that lines beginning ### are comments). An interpreter then takes the IDF and simulates the interface that it describes. The menus are implemented as pull-down menus attached to the standard Macintosh menu bar. The user selects from the menus in the normal way, and the system determines which meneme has been selected. This information is the high level action supplied to the ERS modelling the control layer.

The control layer is implemented as a MERS interpreter, with an event response loop that first repeatedly marks and fires all firable s-rules until no firable ones are left. It then gets the next event by calling a subroutine that implements the action layer with the normal low level event response loop. The value returned from this routine identifies the meneme selected and all regular rules matching the event and current meneme states are marked and subsequently fired. This high level event response loop is then repeated. The effect of firing these rules currently is to change the meneme states which are displayed in a flag window (see Figure 4). Menemes set are indicated by their name in the flag window, those not set have their name enclosed in square brackets. The application layer is not currently implemented.

Conclusions

Lean Cuisine offers considerable potential as a design notation around which a prototyping environment for DM interfaces might be produced. The translation of the notation to an equivalent event-response system is straightforward

bold : [Bold] -> [Plain] Bold ----Processing eta rules---

Waiting for event event=itslic (3) ----Processing regular rules--- Firing, italic : italic -> [Italic] ----Processing eta rules--- Waiting for event

Flag Memory [Plain] Bold [Font] [Geneva] limes iltalicl

Figure 4. Output currenfly produced by interpreter.

Anderson and Apperiey 225

Page 10: An interface prototyping system based on Lean Cuisine

allowing easy implementation of the control layer. The notation contains all that is required to specify the appearance of menu objects manipulated by the interface. It does not, in its present form, support the description of more complex object types, nor does it provide for the definition of primitive event types. The notation needs to be extended in these areas.

The application layer consists of links from the control layer to the application routines that must to be invoked in response to a meneme being set or cleared. This could easily be inserted into the event response system in an analogous way to ERL (Hill, 1987a). Feedback from the application layer to the control layer, although not yet incorporated, could be implemented as additional input events to the ERS, again, as with Hill’s ERL. Inclusion of these features is currently being considered.

References

Apperley, M.D. and Spence, R (1989) ‘Lean Cuisine: a low-fat notation for menus’ Interacting with Computers, 1, 1, 43-68

Green, M. (1985) ‘Design notations and user interface management systems’ in Pfaff, G.E. (ed) User Interface Management Systems Springer-Verlag, 89-107

Green, M. (1986) ‘A survey of three dialogue models’ ACM Trans. Graph. 5, 3, 244-275

Harel, D., Pnueli, A., Schmidt, J.P. and Sherman, R. (1987) ‘On the Formal Semantics of Statecharts’ Proc. 2nd Symp. on Logic in Comput. Sci 54-64

Hill, R.D. (1987a) ‘Event-response systems - a technique for specifying multi-threaded dialogues’ Proc. CH1’87 Conf. 241-248

Hill, R.D. (1987b) ‘Supporting concurrency, communication and synchronization in human computer interaction’ PhD Thesis Department of Computer Science, Universi- ty of Toronto, Canada

Jones, J.C. (1970) Design Methods: Seeds of Human Futures Wiley

Olsen, D.R. Jr (1989) ‘A programming language basis for user interface management’ Proc. CHI’89 Conf. 171-176

Siochi, A.C. and Hartson, H.R. (1989) ‘Task-oriented representation of asynchronous user interfaces’ Proc. CH1’89 Conf. 183-188

Wellner, P.D. (1989) ‘Statemaster: a UIMS based on statecharts for prototyping and target implementation’ Proc. CHZ’89 177-182

226 Interacting with Computers vol 2 no 2 (1990)


Recommended