The One Button Mouse - Why It's Still a Good Idea
Originally Written by Brains
As much as I've been using multi-button mice since my first ADB Animas jobby in 1987, I still hold that the one button mouse is a good idea, especially when one takes it into consideration as part of the collective user-interface experience.
If one reads
'About Face' by Alan Cooper (considered the bible for computer interface design methodology) you will strike again and again the problems inherent in a multi-button design. Alan praised the elegance and simple fluidity of a single button mouse, and how it gave a small, quickly learned vocabulary that allowed a new user to become almost instantly familiar with the machine's interface. Apple stuck to their 1984 publication "
Human Interface Guidelines" (which actually had more than a little bit of input from Xerox legend
Alan Kay) for more than a decade, refusing to add a second button and contextual menuing claiming (correctly) that it over-complicated user interaction and "inspired confusion". Apple were determined to stick to their 'KISS' approach because they saw it as their edge over Windows, citing the many productivity comparisons between MacOS and Windows throughout the late 80's and the 90's. Macintosh was "the computer for the rest of us." Leave Windows to the geeks and the accountants, if you just wanted to Get Things Done, you bought a Mac. That was the mentality.
Apple's inclusion of 'control click' with Mac OS 8.0 was a grudging step, its primary reason for inclusion was as another lure for switchers used to contextual-clicking inside Windows, and thanks to Adobe, this trick worked, and worked well enough to survive -- control-click and inherent contextual support came very close to being removed with MacOS 8.1, if it weren't for Adobe Photoshop who used Apple's version of contextual menus to further homogenise Photoshop across the MacOS / Windows boundary.
Whilst it was possible to add a multi-button ADB mouse to a pre-8.0 Mac, not many people did so because there was no contextual support anyway, nor any standard mechanism for interpreting the second (and in some cases third) button. Animas and Kensington independly decided on the same approach of mapping the second and third buttons to the left and right arrow keys, something lifted from early Unix GUIs. of course, once more-than-one-button mice were available as an option, people started writing for it.
One of the earliest and most successful 'mouse extenders' was NowMenus, from Now Software (which was bought by Proteron and subsequently became ActionMenus). Thanks to Apple's INIT31 mechanism, and well documented traps and entry points for interface subroutines, it was a rather simple exercise to extend the MacOS interface in logical ways that increased versatility and provided extra functionality, whilst retaining the overal 'look and feel' of the MacOS interface. NowMenus was a powerhouse, and to this day there is still nothing like it on any platform. You could create new custom menus in the menubar. You could tear off menus and turn them into floating palettes. You could dynamically re-assign hotkeys to any menu item, in any application system-wide, in real-time. It increased the hierarchial menu structure to more than 5 levels deep (handy if you had an alias of your hard drive in the Apple Menu). You could dynamically re-order the Apple Menu, and add dividers and special folders. Best of all, if you had a multi button mouse you could assign functions to the extra buttons, and even call a particular menu (or the whole menubar as one single hierarchial menu) right at the mouse pointer.
This last feature I loved dearly, and still wish I could replicate it on OSX -- of all the features in pre-OSX MacOS, Apple or third party, NowMenus is what I miss the most. A middle-click would make a menu appear right where my pointer was that was the menubar -- no matter which app, all the menus (including any custom additional ones) would appear in a normal, top-down menu list. By using another extension called MenuShade, I could remove the fixed menu bar entirely, and reclaim desktop real estate. No more tracking to the top-left corner, just click and there was my menubar.
Back in my youth, when I worked at an Apple reseller as a tech looking after SEs and Macintosh IIx's with Two Page Displays attatched for pre-press, I turned on so many graphic designers to NowMenus -- having an A3 screen to work in was good, but having to track all the way back to the top left was arduous, and NowMenus solved that.
The presence of contextual menus in OSX is more a legacy of OSX's heritage in
NeXTStep and BSD. Despite Steve still insisting on the one button mouse concept, the actual coders of the kernel & UI were used to right-clicking, so they wrote it in anyway. Steve grimaced, and agreed to look the other way as long as they made sure that everything they did with a right-click could still be accessed by a single button mouse
There is one last virtue of the single-button-mouse graphic interface: it lends itself to touch screens perfectly. Whilst Apple themselves have not released a tablet Mac, they have experimented several times with the concept in the past. Because of the one-button methodology, everything that could be clicked on or dragged could be controlled by a single finger-tip, without any keyboard needing to be present. Tablet PCs running Windows are often cumbersome and confusing to use in this manner because of the strong reliance on contextual menus that Windows has -- tablet makers have to resort to placing 'right click' keys on the sides of the tablet. When Apple finally release their iPad, they won't need to include any work-arounds, because the OS is geared around a single 'button' anyway.
Long live the single button mouse!
