HyperMark: issuing commands by drawing marks in HyperCard

  • Authors:
  • Gordon Kurtenbach;Thomas Baudel

  • Affiliations:
  • University of Toronto, Toronto, Ontario Canada;Universite' Paris-Sud, Batiment, Cedex, France

  • Venue:
  • CHI '92 Posters and Short Talks of the 1992 SIGCHI Conference on Human Factors in Computing Systems
  • Year:
  • 1992

Quantified Score

Hi-index 0.00

Visualization

Abstract

Pen-based interfaces that use markings to issue commands arebecoming more popular every day. The advantages of markings ascommands can also be used in traditional mouse-based interfaces. Wehave developed a system called "HyperMark" which allows markings tobe used in Apple's HyperCard. For example, if HyperMarks are addedto a screen button, not only does a button react to a mouse press,but marks can also be drawn on the button which trigger otheractions. This results in fewer buttons and faster interactions insome cases. In effect, HyperMarks are similar to pop-menus whereadditional functions are "hidden" under a button until popped up.However, with HyperMarks, a user does not have to wait for menupop-up, visually search the menu and point to an item. Instead, amark triggers the item directly and quickly. Our intention is thatordinary HyperCard users/programmers can incorporate markings intotheir own HyperCard stacks.Two types of marking recognition systems can be used inHyperMark. One system is a user trainable gesture recognizerdeveloped by Rubine (1991) which we have ported to HyperCard. InRubine's system a user can create their own vocabulary of markingsand train the recognizer with several examples of each marking. Theother recognition technique called "marking menus", developed byKurtenbach (1991), has a preset vocabulary of markings. Thisvocabulary of marks consists of straight stroke marks distinguishedby the angle of the stroke. Although this marking set is verylimited, pie menus (Callahan, Hopkins, Weiser, &Shneiderman, 1988) are used in conjunction to help a user learn andremember the associations between marks and commands.This poster presents the design issues concerning userprogramming and use of either of these systems in the context ofHyperMark. Furthermore, we examine how these design issues apply tomarking based interfaces in general. The major issues are: how muchprogramming effort is required by a user to make use of one ofthese systems? How easy to use is each system? How self explanatoryare they? How easily and successfully can marks be drawn in eithersystem?We have found that either system has its advantages anddisadvantages and that the systems can successfully be usedtogether. The advantage of the Rubine's system is that user cancreate one's own custom set of markings. However the disadvantageis that it is then the user's responsibility to design anunambiguous mark set and provide examples to train the system.Also, because markings are not self-revealing like buttons ormenus, some sort of user built explanation must also be created. Incontrast, with marking menus, because the marking set is preset, nomarking set need be designed and ambiguity is not a problem.Furthermore, the pie menu aspect of marking menus provides built inhelp. Adding a marking menu is as simple as adding a pop-up menu.Thus for very little implementation overhead a user can obtain thebenefits of using marks.