4.1. Informal Engineering Specification
4.1.1.1. Rationale for Selection of Application
The decision to develop a general menu structure for planning tasks as an application representation was based upon an appreciation of graphical user interface styles as implicated in a manner of carry forward that: (i) exhibits at least some of the characteristics of informal HCI Engineering; (ii) is effective enough in practice; but (iii) is deficient in terms of the support offered to design work. It was also influenced by design guidelines which were taken to suggest that, despite its limited scope and content, the pre-conception was nevertheless likely to support the specification of many aspects of a menu structure.
An Appreciation o f User Interaction Styles
User interface styles, are increasingly popular. Initially, styles were
designed by the vendors of computer platforms for their operating systems, for example, the Macintosh 'Finder' (Apple, 1985), Microsoft's 'MS Windows' (Microsoft, 1992) and Sun's 'Open Look' (Kannegaard et al., 1988). In recent years, end-user organisations and third party software
A ,..:,
C h a p ter 4 C arry F orw ard in Specification
Figure 4.1. Development of a General Graphical User Interface Object - a Menu Structure for Planning Tasks
personal computers & workstations extract appreciation of user interface styles. specify pre-conception support 1 o fC 2 support guidelines for menu design
expression support w reqt. element
3f the General (initiating)
constrain/ object (menu
Design Problem support structure)
specialise specialise reqt. element (initiating planning) constrain/ support support ii support guidelines support for menu
design pre-conception object (menu or planning tasks) h o u s e s h a v e d e s i g n e d i n t e r f a c e sty les to m e e t th e r e q u i r e m e n t s o f g e n e r a l p u r p o s e c o m p u t e r u se rs (fo r e x a m p l e , th e O p e n S o f tw a r e F o u n d a t i o n 's ' M o t i f (O S F , 1991) and p a r tic u la r ty p e s o f a p p lic a tio n , fo r e x a m p l e , m i l i t a r y i n t e l l i g e n c e g a t h e r i n g s y s t e m s ( B r a i m & H e p w o r t h ,
1992) a n d t e l e c o m m u n i c a t i o n s s y ste m s ( M a h o n e y & G o w e r , 1991).
In this th e s is , an in te r f a c e s ty le is tak en to c o m p r i s e a s tru c tu r e d c o l l e c t i o n o f g e n e r a l g r a p h ic a l u s e r in te r f a c e o b je c ts , w h ic h m ay be s e l e c t e d , s p e c i a l i s e d an d in te g r a t e d to d e v e l o p an in s t a n c e s p e c i f i c a t i o n (se e F ig u r e 4.2 ). A g e n e ra l u se r in terface o b je c t, here, is an e le m e n t o f a g e n e r a l s p e c i f i c a t i o n , th a t is, a s p e c ific a tio n o f a s e p a r a b l e s u b s e t o f the
C h a p ter 4 C arry F orw ard in Specification
contributions to human-computer interactions in an instance. Separable, here, implies that one object may be re-specified without necessitating the re-specification of other objects in order to retain the consistency
and coherence of the instance specification - the instance specification is modular. A GUI has been specified elsewhere as supporting interaction which the user experiences as directly and immediately engaging with a virtual world (Hutchins et al., 1985). For this thesis, a general g r a p h i c a l - d i r e c t m an ip ul at i on user interface object is an object which supports com puter contributions to interaction which are visual, rather than aural or tactile, for example, and user contributions to interaction which are perceived by the user as manipulative, rather than verbal or textual^. Thus, a GUI may be said to support computer ‘displaying’ behaviour and user ‘m anipulating’ behaviour. Specifications of separable sub-sets of interaction, then, must specify computer displays and user manipulations (see Section 4.1.1.2).
To distinguish the term ‘user interface style’ from related terms, a style guide is taken to be a document in which object specifications are
presented, together with guidelines for developing interfaces that comply with the style. An interface 'toolkit', 'environment' or 'User Interface Management System' (UIMS) (for example, Mahoney & Gower, 1991) is a program m ing environment in which interfaces which comply with the style may be implemented.
Currently, the majority of objects that comprise a user interface style - windows, menus, buttons, message bars, views, dialogue boxes, icons cursors etc. - tend to address the super-ordinate level of generality, that is, they specify the computer contributions to interactions for work tasks generally. Consequently, the majority of objects concern the 'look and feel' of interaction, that is, the fundamentals of mouse and keyboard
^U se of the term ‘object’ rather than ‘specification element’ is intended to emphasise the fact that the styles and objects of concern to this thesis are graphical. Styles currently tend to specify graphical-direct manipulation interactions. The potential range of interactions that may be specified at a general level, however, is far larger, and includes speech, 3-D imaging, gesturing, touch screens, to name but a few (Jacob et al., 1993).
C h a p ter 4 Carry For war d in Specification
Figure 4.2; User Interface Styles as Collections o f Objects Supporting Design in the Instance
interpret/ :heck style objects select, instantiate & integrate instance requirement nstance pecification specify/ assess implement/ obtain client's
requirement <|x^O<XXXXXXXXX><X><XX><xXx)^^ artefact implement/
test
o u t p u t a n d th e p h y s ic a l a p p e a r a n c e o f th e v is u a l d is p la y (h e n c e
r e f e r e n c e to a c o lle c tio n o f o b je c ts as a ‘s t y l e ’)- H o w e v e r, o th e r o b je c ts th a t c o m p r i s e a s ty le a d d re ss d e sig n at a m o re sp e c ific (c la ss or s u b -c la s s ) lev el, bu t s p e c ify m o re a s p e c ts o f in te ra c tio n . T h e s e o b je c ts re fle c t a d i f f e r e n t t r a d e - o f f b e tw e e n g e n e r a l i t y an d sc o p e . F o r e x a m p l e ,
R o s e n b e r g a n d M o r a n a t t e m p t e d to d e s ig n a g e n e r a l ( s u b - c l a s s ) m e n u fo r c o m p u t e r file c o n tr o l task s (1 9 8 2 ). (T h e m o d e rn e q u i v a l e n t o f th is m e n u , i n f e r r e d f r o m th e p e r s o n a l c o m p u t e r w o r k s t a t i o n s a n a l y s e d in s h o w n in F ig u re 4.3). ( M c C r a c k e n & A k c sy n , 1984, and V an P u tten et al, 1993, h a v e a ls o a t t e m p t e d to d e s ig n g e n e ra l o b je c ts, but at lo w e r (c la ss, s u b - c la s s or s u b - s u b - c l a s s ) l e v e l s o f g e n e r a l i t y .
C h a p te r 4 C arry F orw ard in Specification
Figure 4.3.: A General M enu for Com puter File Control Tasks (inferred from Macintosh and MS Windows and after Rosenberg & Moran, 1982)
File
New Open... C lose S ave S av e As... ‘Specify O ther C haracteristics of Print Out Print QuitKey: * = place-holder, rather than actual manu label
I n t e r f a c e s ty le s a re t h o u g h t to e n c o u r a g e th e e f f i c i e n t d e s ig n o f e f f e c t i v e s y s t e m s in a n u m b e r o f ways:
( i ) s p e c i f i c a t i o n s and c o d e are re -u s a b le , an d so d e s ig n e ffo rt is saved. W h e n the s ty le is a s s o c ia te d w ith a U I M S , im p l e m e n t a t i o n effo rt m a y be r e d u c e d by a facto r o f fo u r or five an d the a m o u n t o f so u rc e c o d e m ay also be red u ced ( S c h m u c k e r , 1987). F o r e x a m p le , the M a c i n t o s h 'U s e r In te rfa c e T o o lb o x ' o f fe rs a set o f r o u tin e s that e v e r y M a c i n t o s h a p p lic a tio n m ay call as r e q u ir e d . E a c h a rte f a c t, th e n , n e e d not i m p le m e n t all a s p e c ts o f its in te r a c tio n fro m s c r a t c h ;
(ii) th e sty le its e lf is well d e s ig n e d , so m i n i m i s i n g u s e r e r r o r and d if fic u lty (B e w le y et al., 1983; S m ith et al., 1982). A lso, industrial d e s i g n e r s m a y p a r t i c i p a t e in s ty le d e v e l o p m e n t an d e n s u r e th a t a s t y l e is a t t r a c t i v e an d p r o j e c t s an a p p r o p r i a t e c o r p o r a t e i d e n tity ( G a le & B re n n a n , 1993; O hlfs, 1991);
(iii) s t y l e s e n a b l e c o n s i s t e n t u s e r i n t e r f a c e s . C o n s i s t e n t u s e r in te r f a c e s a re c o n s id e re d to be m o re f a m ilia r to a u s e r and so
A-vW ■-•ù-'^ •» - Oe .w Jfv'#* j 6
C h apter 4 C arry F orw ard in Specification
easier to learn, and to increase user confidence (Kellogg, 1987; Barnard et al., 1981). It may also reduce the chances of confusion that may result from divergent design. Consistency is a widely applicable, and fundamental rule of thumb for interface design (Denley et al., 1992);
(iv) interface styles are easily transferred to, and acquired by, third parties. It is relatively easy to learn how to apply a style
appropriately, particularly when the style is offered in
conjunction with a toolkit, guidelines and an interactive tutorial (Alben et al., 1994). In addition, designers may learn about a style by analysing existing applications that are written within the style - a learning strategy that feels natural to many designers (Grief, 1985).
Such is the spread of interface styles, that many have come to be de f acto standards for interface design (Buxton, 1993). Compatibility with an interface style is also perceived by many end-users to 'guarantee' a certain, acceptable level of usability and learnability. Interface styles, then, appear to satisfy a designer's need for support, and an end-user’s need for 'guarantee' of effectiveness, at least to some extent, and better than other less widely adopted forms of 'design support'.
This appreciation of user interface styles, then, suggests that they be regarded as application representations that implicate the design practices of general informal specification and informal specialisation. As such, styles appear to exhibit at least some of the characteristics of informal Engineering (see Table 1.1). Since their spread may be
interpreted as suggesting their effectiveness in practice, user interface styles may provide a useful starting point for attempts to illustrate this manner of carry forward.
However, the current tendency for interface styles to comprise mostly objects designed at the super-ordinate level for work tasks generally, may result in failure to support designers adequately. Some complain that the sub-set of aspects of interaction specified is too small and superficial.
"The style guidelines associated with most ... commercially available interfaces do little more than specify what classes of users' choice
C h apter 4 C arry F orw ard in Specification
operations should be supported by which of the supplied selection widgets. Typically, the domain areas of the supplied interfaces, where users actually do their work, are blank spaces with little more in the style guidelines to show how these should be filled."
Hakiel, 1993, p. 1
Further, a style begins to support design at a somewhat late stage,
specifically, towards the end of detailed design and so fail to inform many of the more important design decisions that occur during earlier
elicitation and analysis, and conceptual design (Lim et al., 1993).
There is a need to enhance interface styles, then, by designing objects at lower levels of generality (class or sub-class level).
Menu Structures and Domain Analysis
The second consideration which influenced the decision to develop a generic menu structure for planning tasks is the constraints and limitations imposed by supporting the design with preliminary knowledge. The nature of the pre-conception constrains the type of design support it may offer, and so constrains the type and level of generic object that is likely to be specifiable with acceptable
effectiveness. A menu structure, here, is a set of menus and menu options which categorise, label and display alternative interactive behaviours and/or the work goals that such behaviours may achieve. Menu
structures comprise the computer contribution to i n i t i a t i o n interactions. When one party is in control of the interaction as a whole, typically the user, an initiation interaction is one that results in the on-set of another interaction (Paap & Roske-Hofstrand, 1988). Menu use, then, is taken to be an interaction aimed at determining subsequent interaction. Since menus 'categorise, label and display ... work goals' (line 8, this
paragraph), and the pre-conception comprises a narrow, high level characterisation of work goals, the pre-conception may be expected to support the design of menus.
More specifically, menu names ( l ab el s ) that express work goals are likely to be effective because: (i) during menu use, the user is thought to
formulate an intention in terms of a work goal and then matches this goal with a goal displayed as a menu-option label; and (ii) menus that display
C h apter 4 C arry F orw ard in Specification
the goals that may be achieved through interaction with the computer are thought to help the user to develop a mental model of the device (Snyder et al., 1985). However, since menus also 'categorise, label and display ... int eracti ve b eh avi ou rs ', the pre-conception alone is unlikely support the design of menu labels completely. Users who formulate their intentions in terms of subsequent behaviour, or who seek to develop a mental model based on the system's behaviour, may prefer menus whose labels directly express these behaviours. Thus, Paap and Roske-