This paper describes the development and heuristic evaluation of the oval menu, a widgetfor use in applications for drawing networks and similar linked ...
The Oval Menu - Evolution and Evaluation of a Widget P.J. Lyons M. Pitchforth Comp. Sci. Dept PDL Electronics Massey University P.O. Box 741 Private Bag 11-222 Onekawa Palmerston North Napier New Zealand New Zealand
T. Given D. Page PDL Electronics Comp. Sci. Dept P.O. Box 741 Massey University Onekawa Private Bag 11-222 Napier Palmerston North New Zealand New Zealand
types of high-power motor. Depending on the load, they run at 90-98% of the frequency of the AC power supply, and thus control circuits which take feedback from the motor environment are used to regulate the power supply, providing fine speed control. In PDL‘s new Microdrive Elite motor controllers, the behaviour of the control circuit is simulated by a microprocessor from a schematic diagram produced using the VISTA schematic editor. It is therefore unnecessary to fabricate and maintain a unique control circuit for each application. PDL Electronics awarded the university a contract to develop VISTA; they were concerned to achieve a product with a high-quality interface. Conventional electronic CAD packages were ruled out because the facilities they provide don’t match the company’s requirements. Specifically, the interfaces to CAD packages are tailored for the production of printed circuit boards which will use large libraries of standard ICs. Circuits produced using VISTA fit neither of these assumptions. First, they are never implemented in hardware. Instead, a microprocessor, using a text description of the circuit and inputs from the environment, simulates the circuit and generates the output voltages that the circuit being simulated would have produced given the same inputs. Secondly, the circuit elements are high-level functional units like PID controllers, wave shapers, and integrators, not the usual CAD vocabulary of simple logic, processors, memory and IO devices. When low-level devices are required, a whole family of devices can be represented by a single generic component. For example, it is feasible to provide a generic AND gate, with a parameter to specify the number of inputs which will be used in a particular situation. Furthermore, questions such as whether a signal is active-high or activelow do not arise in a circuit which is being simulated, and similarly, ground-return connections are unnecessary. Finally, CAD packages often incorporate aspects of the physical realisation of the circuit into the schematic design phase, which is clearly inappropriate for a circuit which is to be simulated.
Abstract This paper describes the development and heuristic evaluation of the oval menu, a widgetfor use in applications for drawing networks and similar linked structures. It is a varietj of pie menu, capable of being organised as a hierarch?; and of having its contents updated dynamically. Thus it is suitable for environments where libraries of components are created and used. Care has been taken to optiriiise it for use as a direct manipulation tool. The oval menu has been implemented f o r use on PC and PGcompatible computers running Windows and Windows95. It is written in Microsoft Visual C++ and uses the Microsofr Foundation Classes. It is a DLL, and the component libraries it uses are also DLLs, so it is easily adaptable for use by other applications.
1. Introduction The oval menu is a selection widget for use in direct manipulation drawing tools, particularly tools for drawing networks of objects. Such networks are commonly used for system planning, and include GANTT charts, structure diagrams. entity-relationship diagrams, object hierarchy diagrams, data flow diagrams, and the subject of the present development. circuit diagrams.
Background - PDL and VISTA The specialised schematic editor VISTA, which incorporates the oval menu described in this paper, was designed and implemented at Massey University i n a collaborative project involving PDL Electronics and Massey University, and sponsored by the New Zealand Government’s TBG (Technology for Business Growth) scheme. PDL Electronics produce controllers for induction motors. These motors are simple and reliable, and cheaper than other
0-8186-7525-Xl96 $05.00 0 1996 IEEE
M.D. Apperley Comp. Sci. Dept Waikato University Private Bag 3105 Hamilton New Zealand
252
It was therefore appropriate to develop a new application free from the cognitive and processing overheads of conventional electronic CAD packages. This lends the software a certain generality which may allow some of its components, particularly the oval menu, to be used in a variety of similar contexts.
a choice of boxes to put at the end of the line, the user may have to change the box type by making a selection from a menu (cf. earlier remarks about controlling a drawing package). Whenever a component seems to be selected, it should be able to be operated on in whatever ways are sensible.
A direct manipulation environment
Giving the computer some responsibility. The system should shoulder the burden of producing complex parts of the diagram. With the power of a computer to draw them, automatically produced parts of the diagram can be arbitrarily complex, making it possible to use moremeaningful symbols, or even symbols that change according to the current situation. Users should only need to specify the end-points of connections; subsequent routing should be the responsibility of the system - autorouting algorithms with an overview of the routing space [ I ] now exist which are more efficient and better than the old A* algorithm
Schematic design, like many planning activities, involves establishing relationships between a system’s components. Drawings are an intuitive way of representing such relationships, and indeed, many designers fall into the class of human being who can only think with a pencil in their hands. For this reason, it was felt important to produce a schematic editor which felt like a manual drawing environment, but gave the designer discreet access to the computational power of the computer. This reasoning suggested an environment in which everything connected with creating the drawing was performed by the direct manipulation of objects on the screen. Now, many direct manipulation drawing applications already exist, but it seemed likely that this application could improve on established practice if it were carefully tailored to the activities involved in drawing schematic diagrams. This involved the following guidelines and their practical interpretations:
121. The system should have some awarenessof the meaning of the graphical syntax, and should be able to detect and create semantic relationships between objects when the appropriate graphical relationships exist. In the context of VISTA, this means, for example, that wires which are drawn to input or output points on boxes should automatically be connected to the boxes, and wires that end on other wires should automatically be “soldered” to them. To summarise the discussion about direct manipulation, the aim was to make the production of the circuit diagrams as much like drawing a schematicby hand as possible. There should be as little interference from the computer as possible except where the computer can unobtrusively make it possible to produce the drawings more easily, or can make it possible to produce more meaningful diagrams. The subject of this paper, the oval menu, allowed us to satisfy a number of the aims listed above, and supports several of the others. Indeed, of the points listed above, only the autorouting does not involve the oval menu in some way or other.
Central focus. Whille the designer is drawing, nothing should divert her or his attention from the drawing. A user should never have to look away from the current area of attention on the drawing to effect a change in the drawing. Thus., for example, pull-down menus should be restricted tal administrative functions, and never be used for purely drawing activities. Invoking system functions shouldn’t feel like controlling a drawing pacb.age; it should feel like drawing. Selectable drawing tools should be avoided if possible, Of course. this is consistent with the commonly encountered HCI admonition to avoid modal behaviour, because modes constrain the user’s freedom of action. However, the important point in the current context is that tool selection generally involves the use of a tool bar or a pop-up menu, and is thus visually as well as cognitively distracting.
2. Evolution In the sections that follow, we describe the ideas that led to the development of the oval menu, describe it in some detail, and then present the results of an evaluation, and some
Order-neutral object interaction. The system should not restrict the order in which the user operates on objects, but if a natural order exists, it should be supported. Object creation should not have to happen in a predefined order. Some conventional network editors force users to instan tiate components first, and connect them later. Others ,allow the user to draw a new box by dragging a line from an existing box, but when there is
suggestions for future improvements. One of the preceding guidelines (if a natural order of operations exists, it should be supported) was the starting point in the development of the oval menu. Personal experience, and observation of people drawing
253
circuit diagrams suggests a natural order of drawing. They draw a component - a resistor, say - and then a wire and then, at the end of the wire, another component such as a capacitor, and so on. The user is aware that a newly drawn wire isn’t going to be left dangling but will form a connection to an as-yet uninstantiated component. Conventional CAD systems do not support this. In fact, some of the earlier ones forced the user to instantiate the components at both ends of a wire before allowing a connecting wire to be drawn. That is, wires could only exist when there are components to connect. Today’s circuit editors are not so restrictive. They generally allow the user to draw “loose” wires, and to attach components to loose wires, but in relaxing the restriction, they have dispensed with a fragment of domain knowledge, that could have been used positively to assist the user. Afully “circuit-aware” system would not only allow the user to draw a wire to empty space, but would also assist with the selection and placement of a component at the end of the wire. Macproject, a project-planning application which provides support for the production of GANTT charts, automatically places components at the end of newly-drawn connections. From a purely diagrammatic viewpoint, the GANTT charts are component networks, just like schematic diagrams. In Macproject, the user can drag a link from an existing component into free space, and the application automatically places a component on the end of the link. There are two component types, a task component and a milestone component. However, only task components are automatically generated. If the user wants a milestone component, she or he has to change the component type via a pull-down menu option. This is distracting and unpleasant to use. In spite of these drawbacks, the interaction has a natural feel; it is only in the component-selection phase that it falls down. An improved system would allow the user to choose an appropriate component from a pop-up menu that automatically appears at the end of a newly-drawn wire. The user would select a component, and the component would be drawn and automatically attached to the wire. A conventional pop-up menu containing a list of component names could be used, but these menus have three disadvantages. First, a list of textual names is cognitively distant from an icon-based schematic diagram; the user has to switch from the pattern recognitiodpattern generation activity of drawing to a text-recognition, function-matching mode associated with choosing an item from a textual menu. Secondly, long linear component lists will draw the user’s visual attention away from the point on the screen where the component is to be inserted. Thirdly, conventional (linear list) pop-up menus. for all their immediacy, have a system-administration feel to them; their appearance is carefully chosen to be consistent with, and reminiscent of, other system-wide interaction widgets such as pull-down menus, list boxes, dialog boxes and so
extended set of components
on, and thus selecting items from a pop-up list externalises component selection as a system-control task when it could be internalised as a drawing action. Much HCI literature [3, 4, 51, emphasises the need for consistency across applications; the argument is that users adapt to a new application more easily when it uses familiar interface components to invoke similar functionality. The argument in the previous paragraph may seem to contradict this, and suggest abandoning widely used, well designed standardised components which possess the necessary functionality. In fact, the present authors do not suggest this, but they believe that the desire for consistency should not obscure the particular needs of a specific application area. In VISTA, and in many similar applications, the need to generate a network comprising a series of connected icons occurs frequently enough to warrant a bespoke selection tool.
First attempt: The Spiral menu Figure 1 [6] is a rough sketch showing the generate a menu which satisfied above. It shows a spiral menu with components and three component libraries. Component names have been omitted. VISTA component icons comprise a standard outline enclosing a unique 32x32 bitmap describing the component functionality. The menu shows the bitmaps. They appear in a spiral surrounding the mouseup point. The use of this popup spiral menu allows the designer to choose from a variety of components without having to mov menu. It also makes use of the eby a user selects commonly required g the cursor in a particular direction, This a1 or him to maintain full concentration on the design task. “
254
2. A simple circular menu allows components to be grouped functionally
they are laid out symmetrically [4], and ultimately this was felt to be more important contribution to the menu’s usability than ease of extension. Another drawback to the spiral arrangement is that it accommodates a textual representation of the circuit components (i.e., their names) poorly. Although users of the VISTA system will be professional circuit designers, who should be able to recognise circuit components from their icons, even such users will need to learn about the system, and can be expected to use the system sometimes when they are tired, when instant discrimination between similarlooking icons may not occur. In such circumstances, names are a useful backup for icons.
Clicking on an individual component icon selects it, and it appears in the circuit at the selection point.
The third region in the spiral menu contains library icons. Clicking on a library icon causes a list of component icons, arranged around the “next track” of the spiral, to appear. In Figure 1, the second library has been opened and its three components are shown in the “next track” of the spiral. It is apparent that this design would allow the user to achieve most of the aims described earlier, but its graphic design is poor. In particular, if efficient use is to be made of screen space, the sp,acing between successive entries on the spiral should be constant, and this would make it be impossible to organise any sort of radial structure. That is, although a group of items might be aligned along one particular radius, other groups which lay along other radii would be successively further out of alignment as the angle
Second attempt: Concentric menus
of rotation o f the radii moved further from the angle of
T h e second and subsequent attempts were all versions of the pie menu [7]. The circular menu in Figure 2 has a clear structure, includes component names, and allows the grouping of like items. Unfortunately, it is very big, and in a
rotation of the original radius. The spiral was originally chosen because it is an easy shape to extend, bult users find it easier to find items when
255
The appearance of the same item at two levels in the menu (the item is selectable at both levels) is an unusual feature; it allows the bottom level of the menu to contain (the most commonly selected) selectable items, and still function as parents of the items in the child menu. An alternative would be to use the lowest level of the menu exclusively for submenu names, and only include selectable items at higher levels. This approach would mean that the user would always have to issue two mouse clicks to select any item, and this would arguably be a worse case of externalising the selection as a system oriented task than the previously rejected approach of using a pop-up menu containing a list of component names.
Fourth attempt: the oval menu The hierarchical circular menu approach seemed, nevertheless, to have some promise. It can have a large branching factor, and thus it can represent a large selection space in a small amount of screen space. The large branching factor also means that the menu hierarchy will be fairly flat. The circular menu can be organised so that the most commonly selected items are directly selectable at the lowest level of the menu hierarchy, but can also be used as parents for related items at higher level. It is “clean” graphically. However, it does not provide sufficient space for component names, which turned out to take up more space when written by the MFC routines than when drawn by hand, as these diagrams were. In an attempt to make space for names, which are most legible when written horizontally, the radial lines separatingthe sectors were extended horizontally, creating horizontal bands for names adjacent to the components. For some reason, in this version of the menu, the menu navigation triangles for accessing a submenu (they are shown in white in Figure 4)were not repositioned. Figure 4 also shows another innovation - the inclusion of an archetypal component (a grey box) at the insertion point in the drawing. At this stage, the archetypal component was drawn in the centre of the menu as a passive placeholder, with no function but to indicate where the component to be created would appear on the screen. However, i n later versions of the menu, it developed more meaning. The intention of this development was to give the user an idea of what the component would look like when it was fully instantiated, and to reinforce the user’s impression that the archetypal component is a part, albeit incompletely formed, of the schematic diagram. In later implementations, the archetypal component first appears as a featureless grey rectangle, but as the user moves the cursor over the sectors of the menu (causing their colour to invert, as is common in menus), the icon field at the centre of the archetypal component changes to show the icon for the currently selectable component.
3. A circular menu with items that can be selected or used as “parents” of child menus production system, the component names could not easily be made as small as they are in this hand-drawn prototype, so in order to fit the names in, the size of the real menu would be even larger. Furthermore, because sectors further from the centre are larger, it uses space inefficiently. This problems would be avoided in a square menu - successive rows of the menu could have successively more entries - but this benefit only becomes significant when the number of items in the menu is extremely large. The square menu was thus also rejected.
Third attempt: Circles with hierarchy After these concentric, “show-everything’’ designs had been rejected, various hierarchical menu alternatives were designed and evaluated. Figure 3 shows an example. It is at the second level of the menu hierarchy and illustrates the use of up-controls for accessing higher levels of the menu (the outwards-pointing triangles) and down-controls for returning to lower levels of the menu (the numbered, inwardspointing triangles). The up-controls are associated with parent components which are representative of the type of component at the next level; clicking on the triangle adjacent to the low-pass filter icon in Figure 3 will result in a child menu containing a number of low-pass filters, including the parent component, which can thus be selected at either level of the menu. The user can go down to any lower level in the menu by clicking on a numbered down-control attached to the inner edge of the menu circle; the figure shows only one such control, but in general, if level n of the menu is displayed, there will be n-1 down controls visible. The branching factor of the menu should be set to minimise the number of levels.
256
4. Adding names to the menu gives it an oval footprint relationship, the menu is made to seem as though it floats above the drawing surface. The inter-sector divisions are not the simple white lines shown in Figure 4. They are in fact transparent, so that the underlying drawing can be seen through the “gaps” between the sectors. This simple subterfuge is not distracting, and is surprisingly effective in establishing an element of three-dimensionality in the diagram. It is aided by menu colouration, which has a higher saturation than the background colours used in the diagram, so that the menu seems to advance. As a general principle, object colours in VISTA are chosen so that objects are distinguishable on the basis of brightness alone. Saturations are generally low, and the highest values saturation(20%) are reserved for important items, small items, and items which are only on the screen for short periods. The menu falls into the latter two categories, and thus qualifies for a higher saturation colour. Transparency is used in another way in the menu. The VISTA software is implemented in Microsoft Visual C++ and makes heavy use of the MFC (Microsoft Foundation Classes) class library. The oval menu is implemented as a separate, borderless, window. However, the MFC library only supports rectangular windows. Whenever the menu displays itself, it must therefore make the part of its window which is outside the oval seem to be transparent. To do this, it first copies into its window an image of the background over which it will appear, and then superimposes the oval menu over the top of this image. Then when it displays the window, the only pixels which actually change are those inside the oval.
Optimisation: siize The shape of the oval menu is convenient; it matches the aspect ratio of notelbook computers with a screen resolution of 640 x 480 pixels. However, it is not small, and some effort was expended on minimising its size. First, however, the size of the circle round the archetypal component needs to be prevented from becoming too small, when there are few entries in the menu. A minimum size is set, and when the number of entries in the menu becomes large enough, it increases in size to accommodate the extra entries. Note that the number of entries in the menu is capable of being dynamicailly configured but in the VISTA system, the configuration is performed once at system startup, and the number of entries is fixed at 12 in VISTA. This restriction would not necessarily apply in another application which used the oval menu, though a dynamically resizable menu could be difficult to use. Secondly, major and minor axes for an oval which will just enclose the largest menu or submenu in the hierarchy are determined, and an oval this size is used for all the menus in the hierarchy. Although this does not produce the smallest menu possible on all occasions, it ensures consistency of size between parent and child menus.
Menu “transparency” Earlier, the point was made that the menu should be carefully integrated into the drawing activity. To foster this
257
5. Moving navigation triangles closer to the centre of the menu reduces confusion distinguishing between situations in which the click means deselection and situations i n which it means menu instantiation.
3. Evaluation A small group of computer-literate users, with skills in electronics design, computer science, and HCI evaluated the VISTA software. Their reactions were generally positive; the system felt good to use. However, a number of criticisms were raised, some relating to the oval menu. These are summarised below, as are the steps which are currently being taken to address them.
Navigation When component names were added to the out circular menu, creating the oval menu, the menu triangles were not repositioned. This left them components and their names, and all of the users found difficulty with, or commented on the clumsine S arrangement.Accordingly, it is proposed that the up triangles shown in Figure 4 should be replaced by the broad outward-pointing arrows shown in Figure 5, and that the go-down functio e bound to the similarly shaped, numbered in g, arrows also shown in Figure 5. As before, on the go-down arrows specify the level in t hy to which the system will return. t” for a submenu also appears in the submen at the same location as in the parent menu (it can be selected at either level). location will not be used as a parent in the s next generation of submenu will not have a goin the same location. This situation could generation submenu, and to accommodate that unlikely event, the go-down arrows can be staggered. This new arrangement of navigation controls separates menu navigation from the bl lection region of the menu, puts the go-up and go-dow Is in the same region, and
Single click menu instantiation In the prototype VISTA implementation, the menu was instantiated by a single click on the background. PDL engineers found this unnatural, as they were used to clicking on the background to deselect objects, and found it annoying when this action caused a menu to appear. Consequently, in the first release of VISTA, the menu is instantiated by a double-click. Three users disliked this solution. One simply disliked having to use a double click. Another repeatedly mixed up the double-click for menu instantiation and the single clicks for menu navigation and component selection, even after this has been explained. The third - a very experienced Macintosh user, and HCI expert - did not mind using a double-click, but could not reliably generate adouble click recognisable to Windows. Single clicks cause problems because they can have another interpretation; double clicks cause problems because they are double clicks. Current development is therefore directed towards disambiguating the single click,
258
keeps the controls near the centre of the menu, so that even when the user is interacting with the system rather than manipulating the schematic directly, her or his focus of attention remains near the insertion point.
Operating on the archetypal component The circle of component icons round the insertion point in the oval menu focussesthe user’s attention on the insertion point of the circuit diagram. In the prototype VISTA implementation the centre of the menu was empty. Later, a featureless grey placeholder was added, and then it was animated, so lhat as the user moved the cursor round the menu, the icon under the cursor appeared in the placeholder. It thus began seeming more like a real, but not completely instantiated component. Users commented favourably on this feedback, and it seemed that the more closely the archetypal component mimicked a real component, the more comfortablethey felt about the system. It was thus decided to allow the users to perform any sensible action on the archetypal component. There are only two; dragging and deletion. Deletion is trivial; it is simply a case of binding the delete key to the menu deletion action. Dragging is a little more complex; when the archetypal component is dragged, it should move across the screen just like a fully instantiated component, but the oval menu should move with it. However, in order to allow the user to see the context through which the archetypal component is moving, the oval menu should be reduced to a wireframe outline. This will have the added advantage of avoiding the computational complexity of moving an oval shape across the schematic; the oval menu is imlplemented as an MFC window. All such windows are rectangular, and the area in the window not covered by the ova11is a copy of the underlying portion of the schematic. If the whole window were simply dragged across the screen, part of the schematic would seem to move with it.
Menu size Some users felt that the menu was too big. It is disorienting to see such a large: object appear suddenly, and when it appears at the edge of the window, the schematic must slide a large distance so that the whole menu is on the screen. The vertical size of the menu is determined by the height of the icons and the need to leave sufficient space above and below their names It cannot be reduced much more. By contrast, the current horizontal size can be reduced; it is currently calculated to fit a longer string of characters than the longest component name, and it could instead be “made to fit”. A second alternative would be to display the menu in two phases; first the circle of icons would appear, and, if the user had been recognised (by rapidity of selection) as a power user, then the names would not appear till after a short delay.
In most cases, the user would select an icon before the names had appeared, and the impact of the menu would thus be much smaller. A novice user would see the names appear immediately after the icons, and maturing users would see intermediate delays, thus providing a transitional interface for the “improving intermediate” user who is partway between novice and power user [SI.
ConcIusion The oval menu has been developed to allow component selection in a graphical editor for electronic circuits. Because the circuits designed using this application are simulated, and not implemented in hardware, the editor lacks certain circuit-specific features, and the oval menu is consequently sufficiently general to be used in other visual editors designed to construct networks of components, including systems in which users add to the component set while the editor is running.
References SPAR: A Schematic Place and Route System, Frezza, S.T., and Levitan, S.P., IEEE Transactions on Computer Aided Design of Integrated Circuits, 12,7, July 1993, pps 956 - 973 Autorouting with the A* Algorithm, Neve, R., Dr Dobb’s
joumal, September 1989, 16-86 Designing the User Inter3cace: Strategies for Effective HumanComputer Interaction, Shneiderman,B, Addison-Wesley,pl 1,
1992 Designing Visual Interfaces: Communication Oriented Techniques, Mullet, K, and Sano, D. Sunsoft Press (Prentice Hall), 1995, p 117 Human-Computer Interaction, Dix, A., Finlay, J., Abowd, G. and Beale, R. Prentice Hall International,p135, 1993 Designing with PREVAIL, Lyons, P.J., in consultation with Apperley, M.D., Massey University Computer Science Department, December, 1994 An empirical comparison ofpie versus linear menus, Callahan, D., Hopkins, M., Weiser, M., and Shneiderman,B., Proc CHI ‘88 Human Factors in Computer Systems, ACM, New York 1988, PPS 95-100 “Persistent Usability”: A Multiphasic User Interface Architecture f o r Supporting the Full Usage Lifecycle;
Constantine, L.L., Proc. OZCHI ‘94 (Harmony through Working Together), December 1994, CHISIG, Ergonomics Society of Australia
