norman@d.cs.okstate.edu (Graham Norman Perc) (06/09/90)
[Followups to c.s.m.programmer only; c.s.m should be dead.] From article <2291@speedy.mcnc.org>, by kk@mcnc.org (Krzysztof Kozminski): > I am still going to defend the idea that allowing the software to > control the mouse position is occasionally a Good Thing, and my primary > example of such is still a situation when you need to go to a tool > palette or a modal dialog and then return to the place on the screen > that is distant from the palette/dialog. You can't argue Human Interface issues from examples; examples only show what _might_ be profitable. To see if it is _truly_ profitable, you must write sample programs that use the technique. Then you must perform scientific experiments with real users (sophisticated and unsophisticated) to see how the new technique affects productivity/ performance/whatever as measured against the old technique. The new technique should be released on the public _only_ after it has proven itself in the lab. The failure to use prototyping and user testing in the design of human interface elements has resulted in much of the ad-hocery that we see in today's GUIs. Far too often, we've relied on the programmer's sense of design (which is often just "gee-whiziness" in disguise). Now, I'm not flaming programmers (I'm a Comp Sci type myself); but the simple fact is that most programmers have absolutely no human factors engineering knowledge or experience and thus are not qualified to design computer-human interfaces. I do not consider myself qualified to do such work, even though I'm a doctoral candidate in Computer Science, have used and programmed the Mac since 1984, and know a bit about the reasoning behind the Mac's HI. Indeed, I'm content to follow the guidelines designed by the human factors engineers at Apple and elsewhere; after all, these guys have the knowledge, experience, and resources needed to design and test HI elements. Of course, sending ideas to these guys is one thing; doing their job is quite another. Let me point out that program control of the mouse position has been debated in the Mac programming community since before 1984. Since it's not become a sanctioned part of the Mac's HI in the last 6 or 8 years, I doubt that it ever will. But lest I come off sounding too negative, let me suggest a compromise. Instead of a modifier key that makes the mouse jump to a program determined position, how about a modifier key that makes the mouse twice as fast (or 3x or 4x or ...); this modifier would essentially turn the mouse into a turbo mouse. Of course, the user is free to select the modifier key and the speed of both the normal mouse and the turbo mouse. This way, the user is always in control of the mouse position and the user also can travel across the screen quickly. I suppose I should point out my personal biases: I use a 15 inch monitor with mouse tracking set to the fastest speed; with this setup I have absolutely no problems moving anywhere on the screen as quickly as I need. In all fairness, I doubt that either my proposal or your proposal will really increase user productivity. This opinion is based on the following reasoning: A) Mouse movement is a low-level cognitive function; thus users need not abandon cognitive processes on the primary task (in your example, selection from a palette) while moving the mouse. B) In your scheme, users must 1) stop cognitive processes on the primary task, 2) enter a decision-making process (to remember the jumpy mouse modifier key), 3) press key, 4) locate the new mouse position, and 5) reacquire the cognitive processes for the original task of selecting from a palette. C) In my scheme, step (4) would be replaced by "moving the mouse". Because mouse movement is a low-level cognitive function, steps (4) and (5) would be performed at the same time. I believe the time required to do all this cognitive shifting effectively negates any real time saved by either scheme. However, because both schemes (mine and yours) require high-level cognitive shifts, the user is likely to perceive them as faster than normal mouse movement when, according to the clock, they may actually be slower. Of course, all this is speculation as I've not done any of the testing I previously said was required. > [...] several weeks ago my officemate, showing off some features of > an elaborate schematic capture program, was gloating over the fact that when > he was adding a new element, after checking on some attribute of the element, > the pointer jumped to the next checkbox that was likely to be checked - IMHO, if a program is smart enough to anticipate my intentions, then it should actually perform the action. If it can only decide what I'm likely to do, then it should let me do it lest I have to undo what it thought I would do. The above program should have either checked the checkbox or left it alone, it should not have moved the pointer. Your description of this program makes it sound like it's using the old model where the computer asks a series of questions (each question may be selected based on past user responses) and users are forced to answer each question before they are allowed to continue; however, this program seems to have wrapped the whole thing into a modal dialog where each possible question is represented by a checkbox. -- Norman Graham Oklahoma State University Internet: norman@a.cs.okstate.edu Computing and Information Sciences BangPath: 219 Mathematical Sciences Building {cbosgd,rutgers}!okstate!norman Stillwater, OK USA 74078-0599