Abstract
Pen-based interfaces that use markings to issue commands are becoming more popular every day. The advantages of markings as commands can also be used in traditional mouse-based interfaces. We have developed a system called "HyperMark" which allows markings to be used in Apple's HyperCard. For example, if HyperMarks are added to a screen button, not only does a button react to a mouse press, but marks can also be drawn on the button which trigger other actions. This results in fewer buttons and faster interactions in some cases. In effect, HyperMarks are similar to pop-menus where additional functions are "hidden" under a button until popped up. However, with HyperMarks, a user does not have to wait for menu pop-up, visually search the menu and point to an item. Instead, a mark triggers the item directly and quickly. Our intention is that ordinary HyperCard users/programmers can incorporate markings into their own HyperCard stacks.
Two types of marking recognition systems can be used in HyperMark. One system is a user trainable gesture recognizer developed by Rubine (1991) which we have ported to HyperCard. In Rubine's system a user can create their own vocabulary of markings and train the recognizer with several examples of each marking. The other recognition technique called "marking menus", developed by Kurtenbach (1991), has a preset vocabulary of markings. This vocabulary of marks consists of straight stroke marks distinguished by the angle of the stroke. Although this marking set is very limited, pie menus (Callahan, Hopkins, Weiser, & Shneiderman, 1988) are used in conjunction to help a user learn and remember the associations between marks and commands.
This poster presents the design issues concerning user programming and use of either of these systems in the context of HyperMark. Furthermore, we examine how these design issues apply to marking based interfaces in general. The major issues are: how much programming effort is required by a user to make use of one of these systems? How easy to use is each system? How self explanatory are they? How easily and successfully can marks be drawn in either system?
We have found that either system has its advantages and disadvantages and that the systems can successfully be used together. The advantage of the Rubine's system is that user can create one's own custom set of markings. However the disadvantage is that it is then the user's responsibility to design an unambiguous mark set and provide examples to train the system. Also, because markings are not self-revealing like buttons or menus, some sort of user built explanation must also be created. In contrast, with marking menus, because the marking set is preset, no marking set need be designed and ambiguity is not a problem. Furthermore, the pie menu aspect of marking menus provides built in help. Adding a marking menu is as simple as adding a pop-up menu. Thus for very little implementation overhead a user can obtain the benefits of using marks.