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
lsr@Apple.COM (Larry Rosenstein) (06/09/90)
In article <1990Jun8.200303.19157@d.cs.okstate.edu> norman@d.cs.okstate.edu (Graham Norman Perc) writes: > 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/ Absolutely right. There are 2 good examples from the latest CHI proceedings. One is a test of accelerated (as on the Macintosh) vs. constant-velocity mice, which showed that accelerated mice didn't improve user performance. (Accelerated mice do save on the required desk space, which may account for their favor among users.) The other tested pull-down menus (as on the Macintosh) vs. a 2-level popup menu system and found that pull-down menus were faster even on a large monitor. (The reason seems to be that the top of the screen acts as a barrier making easier to hit the menu titles.) Both results seem to go against one's intuition about how things should work. > to a program determined position, how about a modifier key that > makes the mouse twice as fast (or 3x or 4x or ...); this modifier See above. > B) In your scheme, users must > 1) stop cognitive processes on the primary task, ... > 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. ... > 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 These kinds of factors also enter into the debate of using a graphical interface vs. a command-line interface. Users think that command-line interfaces are faster, but according to the clock they aren't. (This according to Bruce Tognazzini, our Human Interface Evangelist; TOG@AppleLink.Apple.COM.) Larry Rosenstein, Apple Computer, Inc. Object Specialist (graduate of the Wagner School of Human Interface Design) Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
kk@mcnc.org (Krzysztof Kozminski) (06/09/90)
OK, my last submission on the subject (I am off the post-surgery painkillers :-( and having regained full control of my mind gotta go back to do things I get paid for :-). First, a question: it has been assumed throughout this discussion that Human Interface prohibits the 'pointer warp'. Wanting to know what was the original HI argument, I just scanned all HI chapters in the IM, browsed through the files on Apple.COM, and could not find anything on the subject. Where is this proscription exactly stated, then? Should I go to see an eye doctor, or what? (Could not find anything prohibiting 'window warp', either, and I *am sure* I saw it in the past ...). Anyway, the arguments from Larry Rosenstein and Graham Norman Perc have undeniable merits. Instead of exchanging 'my gut feeling is different than your preconception' arguments, it would be useful to make an actual experiment to determine whether 'mouse warp' or 'palette warp' are Good Things, and, if they are, which one is a Better Thing. I just hope that my contribution (if any) was to point out a couple of situations where it is conceivable that it could be a Not So Obviously Bad Thing. I have also to admit that Larry convinced me that the 'mouse warp' should be an attribute of an application, not selected in the Control Panel. I would volunteer to put mouse/palette warps into the ArtClass included with Think C4.0, if not for the fact that this is the third month of my waiting for Symantec to replace a defective disk with the sources :-( Any volunteers with the complete set of sources out there? Then again, wait a second. Since apparently the HI guidelines are against either or both of these techniques, I presume that such experiments were already conducted by the Apple HI Group - could we hear more about this? ----------------- Now some minor wrap-ups on some arguments I did not quite agree with: >From: lsr@Apple.COM (Larry Rosenstein) >>[somebody's suggestion: mouse warp to the default button in a dialog] >You can achieve the same result by displaying the dialog box so that the >safest option is under the pointer. Your suggestion will not work close to the screen edge - part of the dialog may be off-screen. >From: bskendig@phoenix.Princeton.EDU (Brian Kendig) >>[Palette warp may cause long update times - (KK)] >And update events are practically instantaneous, so that's a non-issue >unless you're using some heinously kludgey plotting program, in which >case the time spent in cleaning up after a palette will be negligible >compared with the time spent in cleaning up after other things. This would be a non-issue in Finder. A floating palette in MultiFinder may obscure other applications' windows, and no matter how smart your program is in doing instanteneous updates, if your palette moves off a Word document containing a complicated table displayed in a page view mode, you'd better expect some waiting. I am trying to look at this whole mouse warp issue from the perspective of a power user, working on a *large* monitor, and trying to shave fractions of seconds from frequently repeated actions - personally, I've never used anything but the fastest mouse tracking setting, but on the 1600x1200 (not sure about the exact numbers - so please don't pick on them) monitor I still would like to do mouse warp now and then. >By refusing to allow programmers to go add all sorts of obscure >functions to the machine, Apple is trying to ensure that it remains as >simple as possible while still being powerful. How was this saying ... make something as simple that an idiot can use it ... (again, I'm not trying to pick up another discussion, just that it depends on the intended users what is obscure and what is not). >(...) by having the Mac be as intuitive as possible. It >resembles familiar things: the pointer is your hand, you throw things >in the trash can to get rid of them, you can drag icons that look like >pieces of paper into folders. >[latter, about mouse warp] >Except that it just doesn't model the real world. My intuition tells me that I do not have to drag a piece of paper from underneath other papers if I want to write something on the part that sticks out, yet Mac alows me only to interact with the top window ... (this is not meant to start another discussion, just to point out that some things fail to model the real world already). > Modal dialogs shouldn't be movable. Not so, see HI note #4. >Or, perhaps, the fact that the pointer doesn't jump all over creation >will become an inspiration to X programmers everywhere, sparking a >worldwide rush to rewrite code. Ya never know. :-):-):-):-):-):-), right? >>[description of my mouse warp (KK)] >Now, let me try to figure that out... better yet, have a >novice try to figure that out Let's make a bet - I teach a novice handling the mouse warp, you teach another novice assorted power-user features of Word 4.0 - say, how to handle 'Position' attribute of paragraphs in a multi-column document (ok, you're off, I spent some frustrating times trying to teach some folks to do the latter :-). KK -- Kris Kozminski kk@mcnc.org "The party was a masquerade; the guests were all wearing their faces."