borton@net1.ucsd.edu (Chris Borton) (03/10/88)
In article <1739@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >In article <14458@oddjob.UChicago.EDU>, mcb@oddjob.UChicago.EDU (Still amused by setenv NAME) writes: >> alternative to the standard interface. The reason the Macintosh has a >> one-button mouse (in case anyone doesn't know) is that the average user >> works > faster with a single button. Apple tested this fairly >> extensively, and it turns out that most people get confused when there's >> more than one button on the mouse. >I take it you believe them? >I have worked on a one-button mac and three button Apollos and Suns and >I hold the opposite opinion (and obviously those companies must share >that opinion since they give you three button mice). I tend to work >much faster on a three button mouse (three functions versus one function). >When I go back to the Mac the one-button mouse seems completely awkward >and lacking flexibility. Let's all try to keep in mind here one difference -- the Mac was originally targeted at 'The Rest of Us', NOT workstation power-users. (128K Workstation? Hmmm...:-)) Suns and Apollos are targeted quite specifically at a technical market that usually has some computer background already. Speaking in general terms, I would agree that a 1-button mouse is *simpler* to use, while a 3-button mouse gives much more power and flexibility. This does not mean that either is BETTER, just different. Different people, different tools. The proliferation of modifier key combination shortcuts on Mac programs demonstrates the usefulness of this type of thing. The Mac covers a much wider market than current workstations do. It also has a much nicer price tag (I'm speaking in generalities here!). However, since Apple has targeted the workstation market so clearly, this raises a potentially interesting issue: Would it be possible to add a three-button mouse to the Mac interface? The hardware would be simple enough with ADB, I believe. The key to this would be defining in the semi-usual-Apple way an interface that would function like Color QuickDraw -- let the old stuff work like normal, and IF the new function is there THEN take advantage of it. Let's think about this carefully... -cbb Chris "Johann" Borton, UC San Diego ...!sdcsvax!borton borton@ucsd.edu or BORTON@UCSD.BITNET Letztes Jahr in Deutschland, nog een jaar hier, en dan naar Amsterdam! "H = F cubed. Happiness = Food, Fun, & Friends." --Steve Wozniak
mcb@oddjob.UChicago.EDU (Not prince Hamlet . . .) (03/10/88)
I'm disinclined to go with a three-button mouse because, as I said, it's been shown that for non-experts, a one-button mouse is easier and faster to use (I don't just believe Apple, I happen to KNOW that they did this research). The mouse should be as simple as possible: a tool for pointing and doing something. What I would like to see instead of more buttons would be a row of "modifier buttons" along the bottom edge of the keyboard. These would be used in much the same way as as keys like shift and option are often used now. I see two main advantages to this scheme as opposed to a multi-button mouse scheme: you get better control (at least 4 buttons are feasible), and you don't clutter up the mouse (and confuse novice users). Note that REAL MEN could have special mice with the buttons on them, if they wanted to. As I see it, there are a couple of issues / problems that would have to be addressed first: 1) This would require a bigger keyboard (and maybe left/right handed models) 2) For the sake of the novice / casual user of an application, the modifier buttons should only duplicate functionality which is available by "normal", if cumbersome means. 3) The use of the buttons should be consistent across applications. This is something that Sun and IBM are apparently incapable of understanding- the single most important part of a user-interface is that it must ALWAYS behave the same way. Offhand, I can think of a couple of "standard" modifier buttons: - Activate (same as double-clicking on an application's icon) - Copy (same as option-dragging on a file's icon) - Select Unit (same as double-clicking on a word) Obviously, applications would be allowed to define their own meanings for unused modifier keys, but the "secret code" approach to functionality (as typified by such monsters as MS Word 3.0) would have to be discouraged. -Matt -- Matt Bamberger "And while you watch and wonder, 1005 E. 60th St., #346 I'll pull the world asunder Chicago, IL 60637 And show you who I am." 312-753-2261 - Supertramp
jwhitnel@csi.UUCP (Jerry Whitnell) (03/11/88)
In article <4737@sdcsvax.UCSD.EDU> borton@net1.UUCP (Chris Borton) writes: | ... |Would it be possible to add a three-button mouse to the Mac interface? The |hardware would be simple enough with ADB, I believe. The key to this would be |defining in the semi-usual-Apple way an interface that would function like |Color QuickDraw -- let the old stuff work like normal, and IF the new function |is there THEN take advantage of it. The current ROM only knows about one button. Hence it would ignore any other buttons on a multi-button mouse. But it would be straight-forward to program a CDEV to recgonize the addition buttons and translates them into any desired function (for example, a pop-up "menu-bar" or windows that can resize from any point on the frame). | |Let's think about this carefully... | |Chris "Johann" Borton, UC San Diego ...!sdcsvax!borton Jerry Whitnell Been through Hell? Communication Solutions, Inc. What did you bring back for me? - A. Brilliant
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/11/88)
In article <14485@oddjob.UChicago.EDU>, mcb@oddjob.UChicago.EDU (Not prince Hamlet . . .) writes: > The mouse should be as simple as possible: a tool for pointing and doing > something. What I would like to see instead of more buttons would be a row of *it* should be as simple as possible for *NOVICES*! again why laden experienced users (users that 10 minutes before where novices :->) with weak tools. > "modifier buttons" along the bottom edge of the keyboard. These would be used oh no! The linking with of keys and mouse is not 1) egonomic and 2) a weak replacement for mouse buttons. Why would anyone add keyboard keys rather than have the simpler and more logical multiple mouse buttons. I think users would be even MORE confused by having additional keys that ACT on the mouse...i can understand a mouse/keyboard RESET button (which would reset the keyboard and mouse configuration to it's default configuration). Tho' i see problems with this too... > 3) The use of the buttons should be consistent across applications. This > is something that Sun and IBM are apparently incapable of understanding- the Apple also doesn't understand this consistency either, note that when you click (select) a file from you Mac hard disk window and drag it to your floppy window you do a COPY. When you try to to the same only instead make the destination directory a hard disk directory ... you MOVE. Note this is an operating system inconsistency...it makes sense but is inconsistent. Second Apple has a good standard but is not consistent across appliations (even MacWrite and MacPaint as mentioned by the previous poster). Also look at Interleaf on the Mac. Their is no enforced standard. FYI. Sun also has a chapter in their SunView Programmer's book on Sun user interface design.
mce@tc.fluke.COM (Brian McElhinney) (03/12/88)
In article <4737@sdcsvax.UCSD.EDU> borton@net1.UUCP (Chris Borton) writes: >Would it be possible to add a three-button mouse to the Mac interface? The >hardware would be simple enough with ADB, I believe. The key to this would be >defining in the semi-usual-Apple way an interface that would function like >Color QuickDraw -- let the old stuff work like normal, and IF the new function >is there THEN take advantage of it. You don't even need to create a new user interface; just add two more buttons and a driver that translates middle-click to shift-click, and left-click to option-click. Viola! No more two-handed mousing! Works in every application! I love it. Now if I just had one... Brian McElhinney mce@tc.fluke.com
pablo@polygen.uucp (Pablo Halpern) (03/15/88)
In article <4737@sdcsvax.UCSD.EDU> borton@net1.UUCP (Chris Borton) writes: >Would it be possible to add a three-button mouse to the Mac interface? The >hardware would be simple enough with ADB, I believe. The key to this would be >defining in the semi-usual-Apple way an interface that would function like >Color QuickDraw -- let the old stuff work like normal, and IF the new function >is there THEN take advantage of it. I like the idea of adding a two- or three-button mouse to the Mac but WITHOUT changing the mac interface. The way I see it, the best use of the extra buttons would be as accelerators. E.g., the left button would be the same as the one-button mouse button; the middle button would be the same as a shifted-button; the right button would be the same as command-button or option-button. The default mapping would be set in the control panel. In addition, a resource could be added to an application file to override the default if that application uses, say, option-click more than command-click. By using the extra buttons as short-cuts only, you prevent the developement of software that REQUIRES a multi-button mouse. I, for one, like the one-button mouse but would go for a three-button mouse if the software interface were as I have just described. Pablo Halpern | mit-eddie \ Polygen Corp. | princeton \ !polygen!pablo (UUCP) 200 Fifth Ave. | bu-cs / Waltham, MA 02254 | stellar /
vita@falstaff.steinmetz (Mark F. Vita) (03/19/88)
In article <1759@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >In article <14485@oddjob.UChicago.EDU>, mcb@oddjob.UChicago.EDU (Not prince Hamlet . . .) writes: >> 3) The use of the buttons should be consistent across applications. This >> is something that Sun and IBM are apparently incapable of understanding- the >Apple also doesn't understand this consistency either, note that >when you click (select) a file from you Mac hard disk window and drag it to >your floppy window you do a COPY. When you try to to the same only instead >make the destination directory a hard disk directory ... you MOVE. Note this >is an operating system inconsistency...it makes sense but is inconsistent. I don't think that this an inconsistency in the way the *mouse button* is used. In either case, the mouse button was used to select an item in one place, move it to another place, and drop it. The fact that the Finder, in this example, interprets this action so as to not make a redundant copy of the file when the destination is the same as the source is really independent of the human interface technique of clicking and dragging. The Mac interface is always consistent in that clicking on an item with the button selects it, and dragging it moves the selection. How the application decides to interpret the consequences of such an action is up to that application. (A minor quibble: note that the Finder is not technically part of the operating system. It's just an application which allows the user to perform file operations and launch programs. One needn't use the Finder at all; there are many alternatives available.) I think what the original poster meant by "inconsistent use of mouse buttons" is when different applications use the same buttons to perform completely different user interface actions; for example, some applications use the right button for menus, some use the middle button; some use the middle button to extend selections, some don't. >Second Apple has a good standard but is not consistent across appliations >(even MacWrite and MacPaint as mentioned by the previous poster). >Also look at Interleaf on the Mac. Their is no enforced standard. Balderdash. There IS a standard, which is extremely well-documented, and which 90% of Mac applications follow very closely. I don't know what you mean by "enforced". Do you mean that Apple should sue software vendors that don't follow the guidelines or something? I think Apple encourages developers to follow the guidelines as vigorously as they can within practical bounds. Also, putting up Interleaf as an example of inconsistency in the Macintosh interface is extremely misleading. Interleaf is NOT a Macintosh application. It's a Sun application that was ported to the Mac, complete with it's brain-damaged abomination of a user interface. (brain-damaged even by Sun application standards). >FYI. Sun also has a chapter in their SunView Programmer's book on Sun user >interface design. Yeah. Obviously the people at Interleaf haven't read it. :-) But seriously, this little five-page appendix is not nearly as detailed and extensive as the user interface guidelines Apple has published for its developers. And it concentrates on very specific pieces of an interface such as buttons and frame headers; it's doesn't say much about what the overall user interface of a SunView application should be like. And it's vague in spots (for example, even Sun isn't sure exactly what should be done with the middle mouse button). Just look at the results. Mac user interfaces are extremely consistent across applications. One can start a brand new Mac application and, in most cases, start using it productively without even cracking the manual. This is because almost all Mac applications look nearly identical when they start up - an empty document window called "Untitled", and a menu bar containing the Apple menu with an "About <application>..." option followed by a list of available desk accessories, a File menu which always has "New", "Open", "Close", "Save", "Save As...", "Revert", "Page Setup", "Print" and "Quit", an Edit menu which always has "Undo", "Cut", "Copy", "Paste", "Clear" and "Select All", and often a "Font" menu containing a list of available fonts, plus whatever other application-specific menus are required. There is not even close to this level of consistency across Sun applications. Note that I'm not saying that all SunView user interfaces are bad. Some are very good (example: FrameMaker. Wonder where they got their inspiration? :-). But by and large, they just aren't consistent with each other. ---- Mark Vita ARPA: vita@ge-crd.ARPA General Electric Company UUCP: vita@desdemona.steinmetz.UUCP Corporate R & D vita@desdemona.steinmetz.ge.com Schenectady, NY desdemona!vita@steinmetz.UUCP
gae@osupyr.mast.ohio-state.edu (Gerald Edgar) (03/20/88)
A three-button mouse allows 8 combinations. If you add double and triple
clicks, how many is that?
I can imagine the manuals...
"While holding down the middle button, double-click the left button and
simultaneously triple-click the right button ... "
Maybe all that time I spent on Czerny will finally bear fruit.
--
Gerald A. Edgar TS1871@OHSTVMA.bitnet
Department of Mathematics gae@osupyr.UUCP
The Ohio State University ...{akgua,gatech,ihnp4,ulysses}!cbosgd!osupyr!gae
Columbus, OH 43210 70715,1324 CompuServebarnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/20/88)
In article <445@osupyr.mast.ohio-state.edu> gae@osupyr.mast.ohio-state.edu.UUCP (Gerald Edgar) writes: | |A three-button mouse allows 8 combinations. If you add double and triple |clicks, how many is that? | |I can imagine the manuals... | |"While holding down the middle button, double-click the left button and |simultaneously triple-click the right button ... " No you can't. In most cases the manuals for the basic tools only describe the way to bind the complex actions to your own functions. When you can combine 1 of n mouse buttons control/shift/meta modifiers double/triple clicks mouse chords (pressing 2 of 3, or 3 of 3) you end up with so much flexibility that you in reality use modifiers to have GENERAL meanings like: shift - changes direction of function control - modifies function - may dramaticly change interface double-click - select word instead of letter triple-click - select sentance or line instead of letter. pressing three mouse buttons - on-line help manual, exit, etc. and so on. It is a lot easier to remember the modifiers because there are patterns involved. And because of the number of modifiers that are available - it is easier to group together modifiers because you have so many combinations, you can afford to NOT USE many of the combinations. To continue the example, in SunView - the middle mouse button moves a window. Adding the Control-key modifier changes the function to resize. The left mouse button brings the window to the front. The shift- modifier reversing the direction so the window goes to the bottom. In scroll-bars, the shift-modifier reverses the direction of the scrolling. Most tools don't use many complex modifiers. Complex modifiers are not needed because you HAVE so many combinations. One exception is the interface to Emacs. Since emacs is so flexible, the user interface to emacs should also be flexible. So if the user WANTS to bind a (double click the left and middle button while holding down the meta key) sequence to an operation, it is because the user finds some convenient way to remember the sequence or because all of the other combinations are already used. I have a chart I use for the Emacstool/GNUemacs bindings. To be honest, I don't know anyone whom uses more than a hundred different mouse/keyboard combinations from memory. But then I haven't asked around :-) Remember, these modifiers should be _optional_ in a friendly window system. The basic interface should work without double-clicking, function keys, chords, etc. These modifiers should be easy to learn because of some mnemonics like the ones I mentioned above. I like SunView myself - having used it for years. It should be more customizable, which is one reason I am looking forward to NeWS. One other point I would like to make about SunView and three-button mice: Any mouse/keypad accelerator that has a dramatic effect usually has a warning if the results cannot be undone, giving the user a change to change his/her mind. This is very important and encourges people to experiment, because if there are wrong, the wrong action can be undone. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/21/88)
In article <4101@vdsvax.steinmetz.ge.com> I wrote: |In article <445@osupyr.mast.ohio-state.edu> | gae@osupyr.mast.ohio-state.edu.UUCP (Gerald Edgar) writes: ||I can imagine the manuals... |No you can't. I appologize to Gerald for the abrupt reply. I missed the Keywords: humor in his posting. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett