kevinw@portia.Stanford.EDU (Kevin Rudd) (10/15/90)
This is a modified repost of an article which got lost. It attempts to explain why kludging keyboard modifiers is a BAD IDEA when implementing a multi-button mouse WITH system support but the ONLY WAY when implementing a multi-button mouse on a Mac WITHOUT system support. It's long but worth it (?!?!). In article <9038@jarthur.Claremont.EDU> wilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: >In article <1990Oct11.174840.21598@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >>Using modifier keys is not much better, worse, or different than having >>multiple buttons on the mouse, if done properly. "Properly" I would define >>as pretty much what an earlier poster said: >> >>Left button, click >>Right button, shift-click > > > Sorry if you got the impression that I was attacking that concept with my >earlier post. > > The person to whom I was responding had the opinion that multiple mouse >buttons should be treated differently, in a standard and explicitly separate >way by the operating system. In fact, he was flaming what your propose. ^^^^^^^ N.b. that flaming typically means something to the effect of irrational and excessive slam in an otherwise civilized message stream. None of my messages have been "flames" and it is unfortunate if individuals felt that my opposing opinion was utter condemnation of them and their ideas. This has been a good discussion and has raised some good points on both sides. The remainder attempts to clarify my position on mice and cheese. Now, let me restate that it seems to me painfully clear that multi-button mice should be treated differently BY THE SYSTEM software. However, this does not imply that the current interface would become incompatable with current software. It would be compatable with software which assumes that the mouse has only one button. For mice with more (e.g. three) buttons, software which does not believe in them would still react the same way to a mouse down event. Only if the application checked would it find out that it was the right button or such rathere than just a single button. This is the only way in which the mouse interface should be done using the system. The mouse down event would return as normal. Then, either somewhere in the event field or with a separate call (e.g. theKey = GetMouseKeys(theEvent)) would either return 0 (standard mouse result) or (MOUSE_BUTTON_LEFT, MOUSE_BUTTON_CENTER, MOUSE_BUTTON_RIGHT in some or'ed combination). Thus current software would treat all the keys the same and new software could behave appropriately. Now, there is no reason that, in the event software does not appropriately understand (or react) to the new mouse keys, there is pleanty of room for a QuickButtons INIT which would provide customizable responses (essentially lisp-bindings just as QuickKeys does for the keyboard). There are two problems with having the mouse directly simulate the keyboard to effect SHIFT-CLICK and siblings. The main one from Apple's GUI Police standpoint is that applications do not all behave the same way between modifier keys and poly-click sequences. Thus one application would use LEFT-BUTTON and another would application would use OPTION-RIGHT-BUTTON to accomplish the same thing. At least by starting with a DEFINED INTERFACE (of whatever kind -- popup menu navigation or multi-function depending on the button, that kind of discussion is beyond the current thread (but very important nonetheless)) there will be some consistency in the use of the buttons. Inconsistency will simply make three button mice less desirable by the masses and will probably prohibit mainstream software support. The other problem is more major: simulating both mouse and keypress events. This is a REAL KLUDGE. (Note, kludges have their place -- more follows). Not all keyboards today have the same codes for all keys (the right control on the extended keyboard normally as well as the right cluster of keys optionally have different codes), and it is not unlikely that new keyboards will have SHIFT, OPTION, and COMMAND as different encodings on different keyboards. For this technique to be used, the mouse would have to know which keyboard was in use and know how to simulate it. Another method is to have an INIT which would intercept mouse events and patch in a prior key down event in the queue (also considered a no-no by Apple). The method of using a simulation or software kludge is a requirement if multi-button mice are to be used WITHOUT APPLE SUPPORT. However, the system and users would benefit by using the hardware directly. I would certainly use one of these kludged mice with great pleasure. But I would dump it as soon as there was actual support for the buttons directly in software. Thus there is certainly a place for the key-and-button approach. However, the place only exists while there is no support in fact. And these devices would still function, they would just not be fully functional with the new system (without a modification to support the STANDARD (easy to implement thereby giving use now while Apple is bline and later when they open their eyes)). I hope that we will see kludges to fill the void. But Apple should not adopt a kludge into the system itself. As was noted in earlier messages, a multi-button mouse would be a compatable OPTION and would only be supported as an ENHANCEMENT to the standard features as the new keyboards were for the Mac. Old Macs with old keyboards still function, but those who upgraded (either Apple or third-party) gain new features. Those who choose not to upgrade plod along as always and probably don't notice the difference. Their Macs would use new software as before -- keyboard modifiers and menu commands. But the software would be able to use three button mice (as governed by the interface guidelines) to ENHANCE the operation of the software. Why three button mouse? Many programs would be much more effectively used with multiple-buttons, and using the mouse and the keyboard at the same time is awkward (using modifier keys). Yes, the buttons could certainly ACT as if they had a modifier key in some applications, but many application) would be better written to support the actual hardware by reading the buttons in some manner and determining what happened and acting accordingly. Making the mouse play keyboard as well prevents this and applications would be the same as today and not be able to offer any additional functionality. And finally, progress shouldn't be kludged when better alternatives exist. Kludges are for PC's -- they NEED them. After all, is a PC with Windows 3.0 as good or better than a Mac? That's a kludge until a real system gets put on the machine to hide the rest of the hardware -- either OS/2 or Unix (you shouldn't have to ask which one I would prefer). Anyway, I hope that Apple gets the message: We need MORE BUTTONS! But KEEP THE INTERFACE CLEAN. Let's get enough three-button mice out there unsanctioned (read: kludged) so they fill the need and build in a good interface! -- Kevin
wnn@ornl.gov (Wolfgang N. Naegeli) (10/20/90)
I fully support what Kevin has said about three-button mice, and I hope that Apple is listening. User-friendliness means at least two things: (1) Ease of learning and use for a novice, and (2) Convenience and efficiency for the expert. The Mac's present interface shines in the first instance, but it really doesn't offer very much for the power user. These two aspects of user-friendliness do not exclude each other, if they are well coordinated and thought through, as Kevin proposes in the case of the mouse. But Apple's failure to pay enough attention to # 2, leads to developers trying to satisfy the needs in divergent fashion, such as MS Word's menu reconfiguration, WordPerfect's use of function keys, or Nisus' use of multi-stroke Command key sequences. This eventually defeats # 1 at least in part. Apple needs to implement some sort of customization manager and guidelines for developers on how to implement interface enhancement in a way that assures unity across applications and the operating system. In an earlier posting I have outlined some ideas about saving preferences in standard portable personal files that users could take to and load on any Mac to customize the Finder as well as applications to better suit their individual requirements and preferences. Wolfgang N. Naegeli President, MacClique--East Tennessee Macintosh Users Group Internet: wnn@ornl.gov Bitnet: wnn@ornlstc Phone: 615-574-6143 Fax: 615-574-6141 QuickMail (QM-QM): Wolfgang Naegeli @ 615-574-4510 Snail: Oak Ridge National Laboratory, Oak Ridge, TN 37831-6206