kk@mcnc.org (Krzysztof Kozminski) (06/07/90)
In the beginning a suggestion to Apple: 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. 2) Provide a flag in SysEnvirons that lets the program know the status of this bit, so that the program can use it for the convenience of the user. 3) Provide this sorely missing routine for setting the mouse position. Something like SetMouse(x,y), returning TRUE if mouse was set, or FALSE if it was not set. (e.g, if the user has turned the 'jumpy mouse' off, or the position was off-screen or something like this). In article <16995@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >In article <1990Jun5.091419.14219@portia.Stanford.EDU> canuck@portia.Stanford.EDU (William Stocker) writes: >>I'm writing a Mac program in THINK Pascal 3.0, and need to force the >>mouse to a particular screen location. > > DON'T DO IT. It's *very* bad technique, and your application > won't run, besides. > >Tell me what, exactly, this `good purpose' is that you've thought up, >and I and millions of other Netters will help you come up with a more >proper way of doing it. I am not the original poster, but coming up with a good purpose seems to be a trifle (hey, I am so stuffed with painkillers right now that I can come up with ANY idea for anything :-) Purpose 1. Imagine running MacDraw on a large screen (1200x1000 pixels or more), editing some stuff in the lower right corner. You want to change a tool and continue drawing in the lower right corner. You have to move the mouse all the way to the palette, select a tool, and move it all the way back. Kinda trouble, especially on a cluttered desk with all 2 inches to mouse about without bumping your coke can off the desk... Solution accordingly to the guidelines: you gotta roll this mouse. Or dig up this reference card and find out which option-command-control- capslock-shift combination selects the tool you want (in case your program was produced by a certain company that considers shift-option-H to be a perfect mnemonic for changing the text style to subscript :-) Solution that comes immediately to anybody whose perspective has not been limited by a puny 512x340 screen and/or by The Gospel from Apple (or whose perspective has been broadened by a substantial dose of opiates after surgery :-) - press, say, <CTRL> key: pointer moves to the palette containing controls <-> CTRL key - quite easy to remember. - select the tool you want, - release the <CTRL>: pointer moves to the area where you were doing your things Purpose 2: You are editing elaborate widgets on your elaborate multi-screen setup, double-click on a widget to open a dialog, and thanx to the ossified guidelines gotta move this mouse to the dialog, then back to your widget ... Opening the dialog in the vicinity of the widget would obscure the widget, hence is no good... Solution: if looking at the widget is useful while manipulating the dialog, open the dialog on another screen, jump the pointer there, return the pointer to the widget after dismissing the dialog. I would be very interested in hearing any suggestions for handling such situations that are both convenient and consistent with the guidelines (then I'll swallow another Percocet and generate more 'good purposes'). Actually, here's the best reason: LOTS of programs using X-windows move the mouse. How are you going to run X-windows on a Mac without this capability? KK -- Kris Kozminski kk@mcnc.org "The party was a masquerade; the guests were all wearing their faces."
bskendig@phoenix.Princeton.EDU (Brian Kendig) (06/07/90)
In article <2285@speedy.mcnc.org> kk@mcnc.org.UUCP (Krzysztof Kozminski) writes: >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... > ... >In article <16995@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >>In article <1990Jun5.091419.14219@portia.Stanford.EDU> canuck@portia.Stanford.EDU (William Stocker) writes: >>>I'm writing a Mac program in THINK Pascal 3.0, and need to force the >>>mouse to a particular screen location. >> DON'T DO IT. It's *very* bad technique, and your application >> won't run, besides. >>Tell me what, exactly, this `good purpose' is that you've thought up, >>and I and millions of other Netters will help you come up with a more >>proper way of doing it. >Purpose 1. Imagine running MacDraw on a large screen (1200x1000 pixels >or more), editing some stuff in the lower right corner. You want to >change a tool and continue drawing in the lower right corner. You have >to move the mouse all the way to the palette, select a tool, and move >it all the way back. Kinda trouble, especially on a cluttered desk with >all 2 inches to mouse about without bumping your coke can off the desk... >Solution accordingly to the guidelines: you gotta roll this mouse. Or >dig up this reference card and find out which option-command-control- >capslock-shift combination selects the tool you want (in case your >program was produced by a certain company that considers shift-option-H >to be a perfect mnemonic for changing the text style to subscript :-) Then we've gotta come up with better standard guidelines. I'd rather be able to hit Command-Minus to select subscript than have to follow the mouse as it jumps all over the screen... >Solution that comes immediately to anybody whose perspective has not >been limited by a puny 512x340 screen and/or by The Gospel from Apple (or >whose perspective has been broadened by a substantial dose of opiates >after surgery :-) >- press, say, <CTRL> key: pointer moves to the palette containing > controls <-> CTRL key - quite easy to remember. >- select the tool you want, >- release the <CTRL>: pointer moves to the area where you were doing your > things Better yet -- hit the Control key, and the tool palette comes up right under your pointer. Same effect, but the machine doesn't wrench your hand away from you. >Purpose 2: You are editing elaborate widgets on your elaborate multi-screen >setup, double-click on a widget to open a dialog, and thanx to the ossified >guidelines gotta move this mouse to the dialog, then back to your widget ... >Opening the dialog in the vicinity of the widget would obscure the widget, >hence is no good... >Solution: if looking at the widget is useful while manipulating the dialog, >open the dialog on another screen, jump the pointer there, return the >pointer to the widget after dismissing the dialog. 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 can just see it now -- I'm working, and suddenly my pointer vanishes. After a long search, I find it on another monitor beside a dialog box. Foo. >I would be very interested in hearing any suggestions for handling such >situations that are both convenient and consistent with the guidelines >(then I'll swallow another Percocet and generate more 'good purposes'). The point here is that the Mac interface is designed to be as natural as possible. The pointer is your hand. When you're working at your desk and you need to grab a pencil instead of the pen you're using, do you teleport your hand over to the pencil-box to get one? No -- you put the pencilbox as close to your work area as you can. >Actually, here's the best reason: LOTS of programs using X-windows move >the mouse. How are you going to run X-windows on a Mac without this >capability? Go ahead and provide the capability in an X-windows server; I don't feel like getting into the methodology behind different windowing systems. But Apple is trying to make their Macintosh OS as intuitive as possible; having the pointer jump all over the screen would sacrifice this to a degree. The Macintosh has gained a lot of its success because it finds innovative, intuitive ways to simply do things that are complicated to do on other machines. If you start doing esoteric things with menus, windows, and especially the pointer, novice users will become confused and leave. << 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.
philip@Kermit.Stanford.EDU (Philip Machanick) (06/07/90)
In article <2285@speedy.mcnc.org>, kk@mcnc.org (Krzysztof Kozminski) writes: > In the beginning a suggestion to Apple: > > 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. > > 2) Provide a flag in SysEnvirons that lets the program know the status of > this bit, so that the program can use it for the convenience of the user. > > 3) Provide this sorely missing routine for setting the mouse position. > Something like SetMouse(x,y), returning TRUE if mouse was set, or > FALSE if it was not set. (e.g, if the user has turned the 'jumpy mouse' > off, or the position was off-screen or something like this). "sorely missing?" See below - I can't say I particularly miss this feature. I used the Mac first, them moved to X. Beware of the "the first system I used is best" syndrome. I can do the same thing back to you (but I won't). [...] > I am not the original poster, but coming up with a good purpose seems to > be a trifle (hey, I am so stuffed with painkillers right now that I can > come up with ANY idea for anything :-) > > Purpose 1. Imagine running MacDraw on a large screen (1200x1000 pixels > or more), editing some stuff in the lower right corner. You want to > change a tool and continue drawing in the lower right corner. You have > to move the mouse all the way to the palette, select a tool, and move > it all the way back. Kinda trouble, especially on a cluttered desk with > all 2 inches to mouse about without bumping your coke can off the desk... > > Solution accordingly to the guidelines: you gotta roll this mouse. Or > dig up this reference card and find out which option-command-control- > capslock-shift combination selects the tool you want (in case your > program was produced by a certain company that considers shift-option-H > to be a perfect mnemonic for changing the text style to subscript :-) > > Solution that comes immediately to anybody whose perspective has not > been limited by a puny 512x340 screen and/or by The Gospel from Apple (or > whose perspective has been broadened by a substantial dose of opiates > after surgery :-) > - press, say, <CTRL> key: pointer moves to the palette containing > controls <-> CTRL key - quite easy to remember. > - select the tool you want, > - release the <CTRL>: pointer moves to the area where you were doing your > things My solution: exactly rhe same, only you warp the palette to the cursor instead. Why? - it's more consistent with the rest of the interface - you don't lose sight of the cursor - you stay focussed on 1 part of the screen > Purpose 2: You are editing elaborate widgets on your elaborate multi-screen > setup, double-click on a widget to open a dialog, and thanx to the ossified > guidelines gotta move this mouse to the dialog, then back to your widget ... > Opening the dialog in the vicinity of the widget would obscure the widget, > hence is no good... > > Solution: if looking at the widget is useful while manipulating the dialog, > open the dialog on another screen, jump the pointer there, return the > pointer to the widget after dismissing the dialog. Instead of the idiotic beep when you click outside a modal dialog, 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. > I would be very interested in hearing any suggestions for handling such > situations that are both convenient and consistent with the guidelines > (then I'll swallow another Percocet and generate more 'good purposes'). I'd hate to be responsible for your health, but please feel free to continue the discussion. > Actually, here's the best reason: LOTS of programs using X-windows move > the mouse. How are you going to run X-windows on a Mac without this > capability? Fair enough, but you are presumably conscious that you are in a different operating system if you use X, just the same as you have to change to MS-DOS mode if you run Soft PC, or find the keyboard behaving in funny ways if you use your Mac as a VT100 terminal. This doesn't stop you from trying to think of alternatives more consistent with the Mac interface (for example, there are some contexts where Soft PC uses standard Mac open file dialogs, and I use a Mac-style dialog to enter my unix password in Microphone II). See also comp.sys.mac.programmer for my suggestion for menus on a big screen. Philip Machanick philip@pescadero.stanford.edu
edgar@function.mps.ohio-state.edu (Gerald Edgar) (06/07/90)
* Solution: if looking at the widget is useful while manipulating the dialog,
* open the dialog on another screen, jump the pointer there, return the
* pointer to the widget after dismissing the dialog.
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.
--
Gerald A. Edgar
Department of Mathematics Bitnet: EDGAR@OHSTPY
The Ohio State University Internet: edgar@mps.ohio-state.edu
Columbus, OH 43210 ...!{att,pyramid}!osu-cis!shape.mps.ohio-state.edu!edgarkk@mcnc.org (Krzysztof Kozminski) (06/08/90)
[I've added comp.sys.mac.programmer to the distribution - I think it's weird it wasn't there in the first place ... - KK] 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. Some details on the methodology I intend to use are included. 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? 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 :-) >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. >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. >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. 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 :-):-) 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. 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. 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. 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... >>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. 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. All the above seems to me quite failproof - any comments are welcome. 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. 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. I have a couple of other, more elaborate uses, but this article is already way too long ... have I made any converts yet? KK -- Kris Kozminski kk@mcnc.org "55 saves lives. 110 saves twice as much"
sec@cs.umn.edu (Stephen E. Collins) (06/08/90)
bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: [stuff] >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"). [more stuff] >The point here is that the Mac interface is designed to be as natural >as possible. The pointer is your hand. When you're working at your >desk and you need to grab a pencil instead of the pen you're using, do >you teleport your hand over to the pencil-box to get one? No -- you >put the pencilbox as close to your work area as you can. But your hand is limited by the laws of physics. There are things you can do on a computer that make it easier than simply trying to immitate real life. I'd hope we're trying to use the computer to advance beyond the limitations of standard procedure. If my computer functions exactly like my real desk, paper, and pencil, why should I use a computer? [even more stuff] >The Macintosh has gained a lot of its success because it finds >innovative, intuitive ways to simply do things that are complicated to >do on other machines. If you start doing esoteric things with menus, >windows, and especially the pointer, novice users will become confused >and leave. If I follow your logic correctly, you're saying that something such as holding down option-command while restarting the mac; or shift-control while bringing up the control panel is "innovative and intuitive". However, something such as moving the pointer to a dialog that requires a mouse-click before the user can proceed is "esoteric and confusing". Stephen E. Collins University of Minnesota Microcomputer & Workstation Networks Center sec@boombox.micro.umn.edu
billkatt@mondo.engin.umich.edu (billkatt) (06/08/90)
In article <2291@speedy.mcnc.org> kk@mcnc.org.UUCP (Krzysztof Kozminski) writes: >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. > >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. Yes, X-window SERVERS on a Mac are a fact. They don't EMULATE X-windows, ok? I am using Mac X right now, and it doesn't warp my cursor. It has a check box "Enable Mouse Movement Under Client Control", and I keep it disabled. I haven't had ANY compatibility problems yet. BTW, I originally turned it off because I was tired of Motif (specifically MWM) warping my cursor to the OK button. If I want it there I'll put it there. So, it is not a necessity. I'll put an argument forth against respositioning the cursor to the next likely check box. I know, FOR SURE, in every Mac program I use that if I position the cursor over a box and click three times, it will ALWAYS just change the state of that box three times. Say I have four check boxes: +-+ +-+ +-+ +-+ A !X! B !X! C ! ! D ! ! +-+ +-+ +-+ +-+ If you position the cursor over 'C' and click three times, what will the state be? I know on my Mac it will be A-On, B-On, C-On, D-Off. What will it be on that guys machine? He doesn't know unless he tries it and then remembers it. It is a matter of intuition, it is important that the user know what is going to happen every time they do something BEFORE they do it. The Mac provides that. The mouse pointer belongs to the user. It should never be moved by the program. If programs start moving it, they user no longer feels they have control over what happens. You should move your windows under the cursor, since the windows belong to the program. ============================================================================= Steve Bollinger ____/| 909 Church St. Apt C \ o.O| Ann Arbor, Mi. 48104 =(_)= (313)-662-4073 -home (313)-763-3070 -work U billkatt@mondo.engin.umich.edu -ACK ACK ACK ACK! "thhhhppppttt!"
bskendig@phoenix.Princeton.EDU (Brian Kendig) (06/08/90)
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.
philip@Kermit.Stanford.EDU (Philip Machanick) (06/08/90)
One more thought on this issue. This has largely been argued as a philosophy/ personal preference issue. Of course, human interface is a science (sort of). It should in principle be possible to program some of the alternatives, and set people to using them for a few months. The difficult part of course is an objective measure... I am not convinced by any of this that warping the cursor is better than warping a tool palette, but if someone is prepared to program both, I'm prepared to try both. Philip Machanick philip@pescadero.stanford.edu
kk@mcnc.org (Krzysztof Kozminski) (06/08/90)
In article <1990Jun7.190113.28131@caen.engin.umich.edu> billkatt@mondo.engin.umich.edu (billkatt) writes: >I am using Mac X right now, and it doesn't warp my cursor. It has a check >box "Enable Mouse Movement Under Client Control", and I keep it disabled. Which is EXACTLY what I've been proposing all along. It was *YOUR* decision to turn this feature off. You don't like it - fine, don't use it, but give the others the same choice that you have exercised by disabling this checkbox. Fair? >If I want it there I'll put it there. I couldn't agree more. >[argument against respositioning the cursor to the next likely check box, >which was one of my (KK) examples of a possibly useful cursor warp, deleted] I partially agree - the described method may be confusing indeed. I would not write an application that would *force* you to use this method. But why do you protest against providing a *CHOICE* for those who would like to have an option of the interaction I described? (To say the truth, these weren't exactly checkboxes, but items functionally very similar to checkboxes). BTW, the program that I referred to in my example is what I think is the singularly most popular schematic capture package - the exact name of the program withheld to avoid diverging into an unrelated argument about its popularity - so perhaps some ideas in its interface are found useful by *some* people. Now you're tellng them to go buy an XXX brand workstation, 'cause Mac IIfx won't be caught dead doing a mouse warp ... >The mouse pointer belongs to the user. It should never be moved by the >program. If programs start moving it, they user no longer feels they have >control over what happens. This happens to be your opinion, shared by many people, but it is not an universal truth ... please, should I direct followups to talk.religion? >You should move your windows under the cursor, >since the windows belong to the program. Don't you think that many people would be confused if windows started jumping around? IMHO, this is way worse than having the pointer do an occasional warp (but I am not going to protest it as long as I can disable it on *MY* computer). KK -- Kris Kozminski kk@mcnc.org "The party was a masquerade; the guests were all wearing their faces."
bskendig@phoenix.Princeton.EDU (Brian Kendig) (06/08/90)
In article <2294@speedy.mcnc.org> kk@mcnc.org.UUCP (Krzysztof Kozminski) writes: >In article <1990Jun7.190113.28131@caen.engin.umich.edu> billkatt@mondo.engin.umich.edu (billkatt) writes: >>The mouse pointer belongs to the user. It should never be moved by the >>program. If programs start moving it, they user no longer feels they have >>control over what happens. >This happens to be your opinion, shared by many people, but it is not an >universal truth ... please, should I direct followups to talk.religion? Hm, might create an interesting train of discussion... >>You should move your windows under the cursor, >>since the windows belong to the program. >Don't you think that many people would be confused if windows started >jumping around? IMHO, this is way worse than having the pointer do >an occasional warp (but I am not going to protest it as long as I >can disable it on *MY* computer). It's basically the difference between either snapping your fingers and having a notepad ten feet away suddenly appear under your hand, or snapping your fingers and suddenly having your hand appear over a notepad ten feet away. << 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.
bayes@hpislx.HP.COM (Scott Bayes) (06/11/90)
> One more thought on this issue. This has largely been argued as a philosophy/ > personal preference issue. Of course, human interface is a science (sort of). > It should in principle be possible to program some of the alternatives, and > set people to using them for a few months. The difficult part of course is an > objective measure... I am not convinced by any of this that warping the > cursor is better than warping a tool palette, but if someone is prepared to > program both, I'm prepared to try both. > > Philip Machanick > philip@pescadero.stanford.edu This is the most sensible response yet. Rather than guessing, do what Apple did--Try it! Scientifically, as an experiment. Do what the experimental data tell you, rather than guessing or saying "This is Sooo neat! Let's do it." 'Course that's expensive. So are Macs. Many people are willing to pay a premium for some pretty ho-hum H/W (well, at least until some of the later Mac IIs came out), with a pretty consistent and usable User Interface. Wonder if there's a correlation? Scott "don't Corrupt the Interface by Jumping to Conclusions" Bayes Hewlett-Packard Company The opinions expressed above are my own opinions and are not an official statement of Hewlett-Packard Company.
scottb@hpcvia.CV.HP.COM (Scott_Burke) (06/13/90)
My solution to this problem is simply to use PointingDevice or Mouse2 to dramatically increase the speed of the mouse. If I have to cross my 2-page monitor, no big deal; since my mouse moves fast enough, I can do it without lifting the mouse once. Perhaps I have a finer touch than most people, but I don't think so; I don't mind having an extremely sensitive mouse. To me, this discussion seems pointless; Apple's guidelines work just fine. An INIT or CDEV can be used to increase the mouse speed for those few of us that desire it--I'm not sure Apple should allow an option "Blinding Mouse Speed" in the Control Panel--and I'm perfectly happy. scott