[Next] [Previous] [Top] [Contents] [Index]
Interaction techniques for a virtual workspace
In the Workbench, interactions follow the principle of "reach in for the object of interest and press the switch on the stylus to interact with it," using a simple bounding-box detection algorithm. Thus, all relevant widgets must be within view (in full, or simplified/iconized, to save rendering time). There is no special double click on the single stylus switch, nor magic key to pop menus up. Whenever the stylus tip enters the volume of influence surrounding an object, the object shows it has become active by a change of colour or other highlighting trick.
Figure 2. The basic elements of a Virtual Workbench application. Examples of selectors
At any one time, one operating mode controls the function of the stylus (as signalled by its appearance), which in different modes becomes a slice-selector, a point-mover, a rotator, etc.
There are application-specific objects, and control-objects or widgets (Figure 2). Application-specific objects are mode-sensitive, and respond to the current mode of operation whenever the stylus enters their volume of influence. Thus, for polyline curves and rotation mode, the user can rotate any curve by reaching near it, and activating the switch. In curve-editing, the selected curve is highlighted and selection descends to a lower level, where the user picks a control or node point and moves it. In contrast, widgets follow a mode-insensitive paradigm: when the stylus enters a widget's volume of influence, the stylus transforms to the manipulator associated with the widget, that knows how to interact with it. For example, when the stylus enters the slider widget, it will change to the slider-dragger from, say, the rotator, indicating to the user that it will not rotate the slider widget but interact with its sliding bead. On leaving the slider's volume, the stylus returns to its former function. This difference between application object and widget keeps interactions simple. If widgets were mode-sensitive, it would be hard to change modes; a rotator approaching a menu, for instance, could rotate it but not select from it. If a menu is to be movable, it can be given mode-sensitive handles.
Mode transitions do not need millimetre precision, and can thus be relegated to the non-dominant hand. We do not yet have hardware support for an absolute-position slider, which the user can move to a remembered location without looking down at it, but buttons can be selected with the mouse. With the customized two-button Immersion Probe we reserved the thumb button to the 'rotate' mode, always active when this was pressed; active selection in returning to (say) the 'edit' function is more obtrusive, since rotation during a sequence of similar operations is so frequent. (Comfort with head tracking imposes more stringent latency constraints than we can meet in rendering medical volume data, so even small changes of viewing angle require rotation.)
[Next] [Previous] [Top] [Contents] [Index]
Generated with Harlequin WebMaker