kk@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"
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.
lsr@Apple.COM (Larry Rosenstein) (06/08/90)
In article <2291@speedy.mcnc.org> kk@mcnc.org (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. Making this feature switchable is probably not the right thing to do. If an application really needs to be able to move the pointer, then it probably wouldn't work right with this feature turned off. (The result will be that programmers will ask for a way to turn the switch on.) It would be better to establish guidelines on when it was legal to move the pointer, and for each application to provide a preferences option to turn this on in the application. In applications (like games, perhaps) where moving the pointer is essential, you would just do it. In applications where it isn't essential (like MacX, apparently) the user has the option. > 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 This isn't clear to me (based purely on marketing). How many X users are there compared to users of standard Mac applications? In fact, most applications manage quite nicely without this feature, so the marketing argument isn't compelling. > the pointer jumped to the next checkbox that was likely to be checked - Someone else already explained one case where this isn't a good idea. If there are that many check boxes that the user needs some help, then perhaps something else is wrong. Also, a better implementation might be to allow the user to set up named settings, and to set the state of a bunch of checkboxes by selecting one of the settings. > of selected checkboxes could be implemented. And he asked: "now can YOUR > Mac do THIS?" I failed to defend the Mac Way... I wouldn't feel bad about this. Just be cause some application does this doesn't make it right. One would need to do a user test to see if it makes sense. > find the RAM Cache control *understandable*, all intuition aside. In the alpha versions of System 7, the RAM cache control is hidden from the average user. (You need to click on a button called Show Details to show the size of the cache.) I suggest that people send their suggestions to MacInterface@AppleLink.Apple.COM and see what the response is from the Human Interface people. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
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.
ba0k+@andrew.cmu.edu (Brian Patrick Arnold) (06/13/90)
If people don't like the way a mouse works, they can *choose* to buy an IBM PC. Choice isn't necessarily good for the user whose life you're trying to improve. I would like to argue that anybody who thinks they're doing users a favor to do some user interface research first. - Brian
ts@cup.portal.com (Tim W Smith) (06/15/90)
Moving the mouse under program control would be useful in a help system. The program could have a button named "Show Me", which the user could press while viewing help on a topic. The program would take over the mouse and show the user how the operation is performed. If keyboard input is required, the program could also put up the keycaps window and show the simulated keyboard input this way. Tim Smith
dce@smsc.sony.com (David Elliott) (06/15/90)
In article <30795@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes: |> Moving the mouse under program control would be useful in a help |> system. The program could have a button named "Show Me", which |> the user could press while viewing help on a topic. The program |> would take over the mouse and show the user how the operation |> is performed. The same effect can be achieved by changing the cursor to something less conspicuous (don't ask me how on the Mac -- it's easy in X) and then drawing a cursor and moving it. Of course, this could confuse the user just the same. It just avoids the problems that people have mentioned with actually moving the mouse pointer. David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "If I had a hat the size of Oklahoma, I'd be a happy person."