Most of the computer systems essential to modern business and leisure activities have evolved a similar core set of graphical user interface commands like Cut, Paste, Save File, and Close File. The commands needed most frequently during personal computer operation can be classified into categories such as mouse cursor manipulation, text cursor manipulation, file management, window management, clipboard/editing operations, and searching. Though individual applications may support specialized commands not available in any other application, almost applications support commands from these core categories. Most of these core commands can be invoked by hotkeys or keyboard shortcuts such as Ctrl+for File Save and Alt+F4 for Exit Application that are fairly standardized across applications and even across diverse operating systems such as Microsoft Windows™ and Linux™ Numerous so-called “macro” programs have been written to allow capture and redirection of hotkey sequences to more specialized operating system functions or applications.
Attempts to speed issuance of hotkeys have led to software that activates command shortcuts in response to particular symbols drawn with the aid of a pen or mouse. Notable examples of such software are Sensiva™ (U.S. Pat. No. 6,057,845 to Dupouy), IBM's Pen for OS/2 (see the User's Guide to Pen for OS/2 Copyright 1995 IBM Corp.), and U.S. Pat. No. 5,252,951 to Tannenbaum et al.
Though users can memorize meaningful pen-drawn alphabets and symbols very easily, simple multi-finger gestures, i.e. slides in a certain direction by certain fingers, are quicker to perform, and if sensibly organized, are also intuitive due to their likeness to motions encountered in everyday tasks. Like hotkey combinations, once performed a few times the command association for multi-finger gestures becomes ingrained in the user's motor memory, and the user subconciously expects those gestures to be available at each computer he or she encounters. Thus careful design of a standard multi-touch gesture set that includes the core command categories in an intuitive manner is critical for user satisfaction in diverse computing environments.
U.S. Pat. No. 5,825,352 to Bisset et al. introduces primitive multi-touch capabilities wherein single-finger motions default to pointing and clicking operations, while addition of a second or third finger can enable drag, scroll, or double-click functions. However, the projective row and column scanning methods of U.S. Pat. No. 5,825,352 tend to limit its application to gestures involving fingertips that lie in a horizontal row, not including the thumb. These scanning methods cannot distinguish nor track the thumb reliably should it overlap roughly the same sensor columns as another finger, as often happens during hand scaling and rotation gestures. Likewise, presence of the palms also confuses such projective scanning methods, limiting their application to the simplest 1–3 finger gestures.
The multi-touch gesture set design in prior U.S. Pat. No. 6,323,846 by Westerman and Elias assumed that the multi-touch surface would be large enough for operation by two hands simultaneously, and that the two hands would be distinguishable so that gestures with different meanings or effects could be assigned to each hand. A two-handed multi-touch surface easily accomodates over 70 command gestures by recognizing up, down, left and right translational slides from the 7 chords per hand distinguishable by thumb presence and fingertip count, plus clockwise and counter-clockwise hand rotation and expansive and contractive hand scaling by the 4 of these chords that include the thumb. The two-handed gesture set taught in U.S. Pat. No. 6,323,846 lends itself to a complementary division-of-labor: mouse-cursor related commands and manipulations such as point, drag, and scroll were assigned to 2-fingertip, 3-fingertip, and 4-fingertip right-hand chords, while text cursor manipulation, selection via text cursor, and paging commands were assigned to the corresponding left-hand chords. (Left-handed users might want this mapping reversed). Similarly, file manipulation commands like Open, Close, Save, Back, and Forward could be intuitively mapped onto rotations, contractions and lateral slides of the right hand thumb plus 3-fingertip chord, while window manipulations like minimize, maximize, next application and previous application could be mapped to equivalent motions by the same chord on the opposite hand. Basic clipboard operations like Cut, Copy, and Paste mapped to pinches, taps, and flicks of a thumb and fingertip of either hand, while search operations like Find and Replace were mapped to pinches and flicks of a thumb and two fingertips on the left hand. Such a clearly organized division of tasks is easy to remember and helps balance the workload between the two hands.
However, such two-handed gesture sets also have disadvantages, as illustrated by past attempts to map the closely related File/Document/Subwindow Close and Application/MainWindow Exit commands to thumb plus 3-fingertip rotation gestures on opposite hands. For some users this causes bilateral confusion errors: they easily forget which hand Closes Files versus which Exits Applications, so they accidentally perform the left-hand counter-clockwise Application Exit gesture when they meant to perform the right-hand clockwise File Close gesture, or vice versa. Though the right-hand File Close uses a clockwise rotation that can intuitively be taught by analogy to closing ajar lid, the counter-clockwise rotation for left-hand Exit rotation introduces confusion: it feels like the opposite motion, similarly moving the left wrist toward ulnar deviation, but is not the same direction jarlids close. Attempting to map Exit to a simultaneous outward rotation by both hands was also poorly received by users, who don't wish to be forced to have both hands on the surface at the same time. Yet another disadvantage of the previous two-handed gesture set is that it only leaves about a dozen distinct motions free for user-customizable command mappings.
Thus there exists a need in the art for a multi-touch gesture set that avoids bilateral confusion by assigning closely-related file and application manipulation commands to sensibly-related gestures from a single hand. This need is particularly challenging because two fingertip, three fingertip, and four fingertip chords are preferably reserved for pointing, dragging, and scrolling, respectively, while the thumb plus 1-fingertip chord is preferably reserved for clipboard/editing operations, the thumb plus 2-fingertip for right mouse clicks and drags, and the five-finger chord for hand resting and zooming. This leaves only gestures by the thumb plus 3-fingertip chord to handle all core file and application manipulation commands.
Also, if such prior two-handed gesture mapping schemes are applied to a surface sized for only one hand, only half as many gestures can be supported. One-handed multi-touch surfaces are particularly important for three situtations: as the entire interface for palm-sized computers commonly known as personal digital assistants (PDAs), as a standalone desktop unit used in conjunction with a standard mechanical keyboard for interaction with a desktop personal computer (PC), or as part of a hybrid keyboard product that uses mechanical keyswitches for the primary alphanumeric layout but replaces the numberpad and text editing keys with a one-handed touch surface to the right of the alphanumeric layout.
Thus there exists a need in the art for a method to pack two-hands worth of multi-touch gesture commands and manipulations onto one hand, just as there has been a long-felt need in the art to pack two-hands worth of alphanumeric keys from a standard keyboard into a space accessible by one hand. Matias addressed this one-handed keyboard need in U.S. Pat. No. 5,288,158, which teaches an easy-to-master half-sized keyboard that acts by default as the left half of a QWERTY key layout, but acts as a reflected version of the right half QWERTY key layout for keys pressed while the thumb holds down the spacebar. Since multi-touch gesture chords are partially distinguished by initial thumb presence, using the thumb as a modifier in this fashion does not work for a multi-touch gesture set. Axthelm used a similar modifier switch and layout reflection technique for a one-handed keyboard in U.S. Pat. No. 5,367,298, while other one-handed keyboard schemes such as U.S. Pat. No. 6,142,687 to Lisak and U.S. Pat. No. 5,336,002 to Russo primarily attempt to regroup the keys in an easy-to-reach yet well-organized manner around the fingers of one hand. Though such modifier switch methods could also expand the capacity of a multi-touch gesture command set, they cannot generally work within one hand since most multi-finger gestures already involve the whole hand for their motion. A second hand, or even a foot, would be needed to activate the modifier key or chord, and coordinating two hands simultaneously requires considerably more cognitive and postural effort from the user than a one-handed solution. Thus there exists a further need in the art for a method to pack multi-touch gestures into one hand without requiring awkward modifier holds by that same hand or the opposite hand.
USPTO Backgrounds
USPTO Backgrounds