November 22, 2004
HCI Comments XV
User Learning and Performance with Marking Menus, Gordon Kurtenbach and William Buxton, CHI 1994: ACM Conference on Human Factors in Computing Systems, pp. 258-64
The advantages of radial and marking menus over linear selection mechanisms in terms of efficiency and speed are described sufficiently in the paper. I want to focus on some issues left undiscussed.
The "press-and-wait" mechanism used to invoke radial menus serves as a context switch operation - it is clear to user and application that the following pen stroke will be interpreted as a menu selection command. But what about marking menus where no clear context switch exists? It appears possible, if not likely, that menu strokes can be confused as strokes meant to be directly registered (e.g. as drawing) in the application window and vice versa. What kinds of disambiguation strategies exist? How likely are such errors of stroke interpretation? The authors specifically use the dual purpose of marks to their advantage to combine object selection and command specification in a few select cases in the ConEd software. But would this overloading work as well in a drawing or design application? Are overloadings application specific so that the user will have to relearn them for every application or do general principles exist?
Besides giving a heuristic of "natural" matching of selection direction to intended action, guidelines are missing for how to arrange menu items in a circle. The principle of command distinctness (Norman) suggests placing similar actions far away from each other.
A quote: "If possible, once a function in a menu is invoked, it is replaced by the corresponding inverse function." This seems half-baked and counter-intuitive. An implicit assumption is made here that a normal workflow alternates between issuing do and undo commands. But what happens if the user wants to sequentially mark all "laugh" occurrences? The appropriate menu item will have disappeared after the first mark and won't return until something is "unlaughed". This practice goes against the author's own recommendation that "marking menus are not appropriate when the list of items changes dynamically." Users will have to remember a set of binary modes to decide which action will be invoked by drawing a stroke in a particular direction.
In the discussion of the case study, the highly unequal amounts of time users A and B worked with the system -- user A crammed all testing into one week while user B took about a month -- complicate interpretation of the results. The different time periods may have had as much of an influence on learning marking as the different user experience levels.
The explanation for not including selection error in the study is not convincing. While not trivial, it is certainly possible to track error frequency at least as an approximation - for example by counting undo operations.
Passive Real-World Interface Props for Neurosurgical Visualization, Ken Hinckley, Randy Pausch, John C. Goble, Neal F. Kassell, CHI 1994: ACM Conference on Human Factors in Computing Systems, pp. 452-8
Dealing with 3D manipulation on a 2D display is indeed a frustrating task. Using 2D input devices like mice exacerbates the problem. 6DOF rotation+translation pucks exist (see Logitech's Magellan line), but manipulation still passes through a layer of indirection: movement of the control device has to be mapped into movement of the objects in virtual 3D space. The frame of reference here is the virtual world, so manipulation of the physical-world controller can be counterintuitive. Hinckley et al.'s approach is appealing in that the frame of reference is moved into the real world which the user already knows how to interact with. The computer merely listens/watches to replicate that interaction in its virtual representation.
The authors stress the need for a system that has a low re-learning time. This longitudinal aspect of system knowledge is seldomly addressed (exception: the previous paper).
I felt that the problem of "clutch" mechanisms was not discussed in sufficient depth in the paper. A neurosurgeon can easily manipulate 3D views, but she cannot efficiently work with the data beyond this 3D exploration. She would have to switch back and forth between some other input devices, e.g., mouse/keyboard, and the bimodal props. The described binary clutches afford the possibility of performing a switch, but the effort to do so is still substantial (find free space on desk, put objects down, make sure they stay in place, locate other input devices, etc.) Moreover, it is impossible to seamlessly resume the 3D manipulation once props were set down. Efficient task/device switching may well be a general issue with bimodal interfaces - a given task may be better supported in a bimodal system, but changing from that particular task to other interaction with the computer system may now be harder since both of the user's most versatile output devices - her hands - are already occupied.
The Design of a GUI Paradigm based on Tablets, Two-hands, and Transparency, Gordon Kurtenbach, George Fitzmaurice, Thomas Baudel, and Bill Buxton, CHI 1997: ACM Conference on Human Factors in Computing Systems, pp. 35-42
The authors make a strong case for the usefulness of their bimodal manipulation technique by retrofitting a production-level application with their system. Successful WIMP applications have often already undergone many years of incremental development and offer very comprehensive toolsets (e.g., Photoshop) unlikely to be matched by an experimental application. Research findings from an artificial "toy" system don't automatically scale to these more complex work environments. That the authors tested their GUI paradigms in both situations much increases my confidence in the reported results.
Notably, the permanent on-screen presence of the toolglass was eliminated in the Studiopaint implementation. In the physical world, artists do not keep all tools piled right on top of the central work area - it would create too much physical clutter. While watching the video, the toolglass did appear to me as visual clutter during non-tool-picking interactions. Instead of selectively hiding the toolglass, hiding it by default and only selectively displaying it, for example through a non-dominant hand move or button click, would seem to better support the goal of maximizing screen real estate for the artwork itself.
Using color picking as the example to demonstrate click through functionality is a bad choice in my opinion. When a color swatch is made semi-transparent, the perceived color is a mixture of the swatch itself and the underlying background color - while general hue assignments are possible (green vs. red), saturation and value cannot be picked precisely in a transparent overlay.