An interface prototyping system based on Lean Cuisine

  • Published on
    26-Jun-2016

  • View
    215

  • Download
    0

Transcript

  • 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: P.Anderson@nz.ac.massey tTelephone: (063) 69-099 Ext.8021. E-mail: Internet: M. ApperIey@massey.ac.nz Janet: M. Apperley@nt.ac.massey

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

  • 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)

  • 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

  • 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)

  • (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

  • 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 Hills 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 users 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)

  • 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

  • :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))...

Recommended

View more >