Xref: utzoo comp.sys.mac:55167 comp.sys.mac.programmer:15216 Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!udel!princeton!phoenix!bskendig From: bskendig@phoenix.Princeton.EDU (Brian Kendig) Newsgroups: comp.sys.mac,comp.sys.mac.programmer Subject: Re: There *ARE* uses for forcing the mouse to a location (non-games). Message-ID: <17071@phoenix.Princeton.EDU> Date: 7 Jun 90 21:59:17 GMT References: <1990Jun5.091419.14219@portia.Stanford.EDU> <16995@phoenix.Princeton.EDU> <2285@speedy.mcnc.org> <17041@phoenix.Princeton.EDU> <2291@speedy.mcnc.org> Reply-To: bskendig@phoenix.Princeton.EDU (Brian Kendig) Followup-To: comp.sys.mac Organization: Starfleet Academy: Princeton University PQC PTC CIT EECS SCI Lines: 262 In article <2291@speedy.mcnc.org> kk@mcnc.org.UUCP (Krzysztof Kozminski) writes: >First of all, please remember that I would like to see this feature to >be switchable on or off from the Control Panel, thus conforming to the >principal idea of giving the control TO THE USER. I am somewhat surprised >to see a dissent in this respect. By all means, 'jumping cursor' should >be switched off as a default, but if the user is willing to accept the >chance of an occasional confusion as a price of the increased convenience >on many other occasions, then LET HIM/HER use it. The official guidelines >forbiding this reek of BigBrotherhood to me. The restriction was >acceptable in the times of a 9 inch screen, because it was not really >noticeable. I think it is time to relax it (see the elaboration of the >X-windows argument later on) - what do Apple people think about it? I cringe at the thought of adding more things to the Control Panel. The RAM cache is esoteric enough, but fortunately, its use doesn't really affect novices much, so they can tinker with it as much as they want to without getting confused. And this isn't Big-Brother-hood by any means. Rather, it's an effort to break the misconception that the more obscure a computer is, the more powerful it is. 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. This is achieved 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. In my opinion, menus and dialog boxes are necessary evils; someday, someone will think up a really innovative way to do away with them entirely, thereby allowing even more simplicity. (Who ever saw a desk with a menubar on it?) But then again, I'm an idealist, and I'm content to bear with them. [ 1/2 ;-) ] >So far, the alternate proposals to my examples of a Good Thing were: >>From: edgar@function.mps.ohio-state.edu (Gerald Edgar) >> ADB Macs can have two mice plugged in. We just need the software to run >> both mice, one for each screen ... After all, I have two hands. >Some people could cope with this - but I personally find it very awkward >to operate even a single mouse with my left hand. And keeping two mice >within the reach of my right hand brings the vision of tangled cords... >and if you need to type, two mice are no good, unless lingual dexterity >allows you to operate keyboard with your tongue :-) Taste-sensitive computing? Outrageous! >>From: bskendig@phoenix.Princeton.EDU (Brian Kendig) >>Better yet -- hit the Control key, and the tool palette comes up right >>under your pointer. >While trying to break one guideline, I probably should not use another as >an argument, but aren't 'jumping windows' another no-no? I have a better >argument against it anyway: this will generate an update event (possibly >also for some background applications), thus slowing you down and negating >the speedup that is desired by allowing the pointer to warp over to the >palette. Jumping windows aren't exactly a no-no, but whould be avoided. Jumping palettes are fine, and should be encouraged. More on this later. 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. >>Or hit Return for the OK button, Command-Period for the Cancel button, >>and other command-things for other buttons (such as Cmd-S for "Save"). >I am talking about editing complicated (maybe hierarchically organized) >widgets - with just as complicated dialogs (or windows) associated with >them - try, e.g, to manipulate a scrollable list with a keyboard - yuck. Then make the widgets simpler. And it's no problem to manipulate a scrollable list with the keyboard; I always do (such as in a Standard File Open dialog. Ever notice that you can begin typing a filename, and the machine will highlight the name you've started to type?). >>From: philip@pescadero.stanford.edu (Philip Machanick) >> The dialog should warp to the cursor. Better still, the modal dialog >> should be movable, so you can adjust its position once it's near enough >> to reach without risk to your ligaments. Modal dialogs shouldn't be movable. (Non-modal dialogs should be, of course.) A user, when confronted with a movable modal dialog, will promptly move it aside (probably almost completely off the screen), then be utterly baffled why the machine keeps beeping at him whenever he does anything. Never underestimate the stupidity of a user. >OUCH, that hurts (a torn ligament is why I had my knee surgery yesterday :-) >(and if anybody is wondering why the smiley, read my previous article :-):-) Hope your knee gets better soon... >I presume that you mean that the dialog should come up near the cursor >(to avoid a jumping window, and to avoid having two areas to update). >But the dialog will obscure the widget you're editing - this is why I >wanted it to show up away from the cursor in the first place. What if your widget is in the center of the screen? The dialog will block it anyway... Am I getting off the subect, or what? Hmm. Never mind. >Now back to the X-windows: this is where I hope to make a final convincing >argument. I'd like just to mention that "the first system I used is best" >syndrome does not apply here; I am not pushing Xerox Star paradigms, am I ?-) >I've picked the X-windows just because sometimes I have to use them. >Normally I run UW or Telnet from a Mac, so that I can write documents while >watching over the number crunchers outputs in the terminal emulator windows. Use MacLayers. Much nicer than UW. >X-window emulators on a Mac are a fact. Allowing the software to move the >pointer all over the screen is a necessity for this particular application. >The size of the X-window market seems to my uneducated in the marketing >matters self a good reason for Apple to provide some kind of consistent >access to these undocumented low-memory globals to the X-developers. >So why should this acces be denied to others? Assuming that the user >knows when to expect a 'pointer warp', there is nothing wrong with it. >The feature should be used with good judgement, and the current guidelines >seem to deny that developers have the ability to make such a judgement. 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. >Some final wrap-up. > >>Brian Kendig: >>If you start doing esoteric things with menus, windows, and especially the >>pointer, novice users will become confused and leave. > >And it you forbid doing esoteric things, sophisticated users will leave. >Point in case: 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 - >the choice of the next checkbox depended here on ALL the previously >checked boxes, so no nice things like a default button or a default choice >of selected checkboxes could be implemented. And he asked: "now can YOUR >Mac do THIS?" I failed to defend the Mac Way... I've dealt with programs like that before, and I don't like the feel of them. When your pointer jumps, there's a brief lapse of time before your eyes can orient on its new position again. That throws me off. If it doesn't jump, you have to move it yourself, and for me the latter is actually faster enough that I can notice it... Show your officemate any typical Macintosh spreadsheet. When you're done with one cell, you can hit Tab to move on to the next. No bother with the pointer. Want to change things like the cell's font style? Hit Command-B or Command-I, then hit Tab again, and repeat as neccesary. Here, there's a difference between what your finger is pointing to and the cell of the spreadsheet you're concerned with, because you should be able to do different things with one specific cell. >>>1) Let the user choose in the Control Panel whether she/he wants to allow >>> a 'jumping mouse pointer'. There's lotsa space there to fit one checkbox >>> that is needed. >>Can you say `counterintuitive'? Sure, you can... >Come on, this was just a sketch, not a final interface specification. There's >enough space in the Control Panel to put a detailed exaplanation. Speaking >of 'counterintuitive' I haven't seen many Mac users outside CS/EE who would >find the RAM Cache control *understandable*, all intuition aside. There's enough space for an explanation, but putting one in is cheating. The options in the Control Panel should be easily understood by sight: cursor flash rate, time and date, volume, and so forth. I don't like the RAM Cache option there, but people can confuse themselves out of their minds by tinkering with it, so it's pretty harmless if misused. On the contrary, a user who's used to having the pointer stay put will be baffled if it suddenly jumps around, and vice versa. Novice users don't think to check the Control Panel. >OK, now, how am I going to do this in my program for widget editing ... >First of all, while displaying the About... dialog on startup, I watch >these undocumented locations, compare them with the legally obtained >mouse location, and, if they do not agree, I assume that something is >not compatible and disable the pointer warp. Just to make sure, I >request that the user moves the mouse before dismissing the startup >dialog - to double check that the numbers agree - but usually the user >will fiddle with the mouse without a reminder. Of course, the entire >feature can be disabled via the program setup/preferences dialog, just >in case the initial checks happen to be insufficient. Furhtermore, I >store the environment in the preferences file, so that when the >program is moved to a different machine/system version, the feature >becomes automatically disabled (just in case low memory suddenly >becomes protected and trying to read it produces an exception), and >the user is notified that the warp mode is off. Picture a worst-case scenario. Apple uses the memory locations for something else, but they just happen to shadow the mouse every now and then. Your program thinks they're okay, and works properly -- for a while. "Fiddle with the mouse"? I never do, and I'd think that a program that asked me to move the mouse with no easily understandable reason is being silly. You're taking too many precautions against something that will inevitably die on you anyway. Way back when, Apple told people to follow certain addressing guidelines. The programs that didn't follow the rules crash the IIci and IIfx. Apple has been warning people not to tinker with low-memory globals for a longer time. You're playing with fire... >All the above seems to me quite failproof - any comments are welcome. If a system is idiotproof, than only people who think they know what's going on will be able to utterly screw it up. Never underestimate the destructive power of a novice. >Now when do I use mouse warp? Precisely for moving the pointer to one >of the several palettes with the tools. Pressing the CTRL (the actual >modifier key used is selectable via the preferences/setup dialog) >turns on the 'warp watch': when the user moves the pointer towards >one of the palettes, it is automatically moved all the way there. >Selecting a tool transports the pointer back. Moving the pointer off >the palette while still holding CTRL warps it to another palette, >provided that the direction of move is correct, otherwise beep and warp >mode off (no return to the work area), to allow exit the warp mode if >the user wishes so. Sounds neat. Now, let me try to figure that out... better yet, have a novice try to figure that out, and try to explain to him why his pointer jumps around whenever he hits the Control key, and why it suddenly won't do that anymore after other people have used the machine (and played with the preferences). >Aside of the pointer returning to the work area after tool selection, >all the above is totally consistent with the interface guidelines - it >just can be considered as an ultra-fast, speed-sensitive mouse tracking. Except that it just doesn't model the real world. Okay, think of it from a psychological angle. Ninety percent of a user's time in a graphics application is spent concentrating on the area of the screen right around the mouse. If the mouse suddenly disappears, he has to scan the screen looking for it (not bad on a nine-inch screen, but larger and multiple ones are a pain -- especially when they're monochrome). Now, have the mouse keep jumping all the time, and the user will gradually expand his attention to cover the entire screen, making him get tired of working sooner. This might sound a bit farfetched, but it's the kind of thing I've read about in psych journals. I'm still staunchly against letting the computer wrench control of the pointer away from the user; there are better ways to handle cases where this seems necessary. << Brian >> -- | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | ... s l o w l y, s l o w l y, w i t h t h e v e l o c i t y o f l o v e.