My desktop machine is an upgraded, yet still old Blue and White G3 mac. For the longest time, I used the tried and true ADB Mouse II, with simple curves and a single button covering the entire top.
Currently, however, I use an optical mouse from some unknown manufacturer. It's got pretty blue and red LEDs, two buttons and a clickable scroll wheel. The scroll wheel's button is set to "Application windows" in Expose, and scrolling with the wheel is almost indispensable.
And yet, I'd still argue that, at the heart of things, Windows, Mac, and even linux GUIs are one-button systems, the extra buttons a waste, hardly justifying the added complexity and support costs.
My reasoning is not on how many buttons the mouse has, or how many the drivers can access, but how many are truely used in a mouse-related context.
Consider, if you will, the primary mouse button. In its everyday use, it's used to select. It's used to activate buttons or links. It's used to select menu items. It's used to move the text insertion point. With a double-click, it opens. With a click-drag, it moves. All of these are vital in day-to-day operation. Furthermore, with actions like drag, the button state and mouse movement are intracately tied.
At the other end of the scale, terierty buttons (like clicking the scroll wheel) are not tied to the mouse's location. In that sense, they're not mouse buttons. Instead, they are convieniently placed macro buttons, and their actions are simply a relocated keyboard key.
So whither the secondary button? It's typically on the right if you're right handed. Of course, the positions can be swapped if you're left-handed, adding to the confusion. The scroll wheel and middle mouse button don't have this chance for modal errors, because of their central location. Surely this wayward button must have a good justification! And yet, there isn't.
The main mouse button is for selecting. It's for choosing. It's for moving. It's for copying. It's for opening. It's for almost any interaction that isn't entering text with the keyboard. In contrast, the second mouse button is for a popup menu. That's it. And even this function has been made redundant; on the Mac, a control-click (On the primary button) will do the same, and on Windows, it's a keyboard key.
Ironically enough, to make a selection on the popup menu -The sole reason for a secondary button- the main mouse button is used.
This is not to say that there's no need for a secondary button. Like a scroll wheel, I find it useful. But the full extent of its utility will be forever squandered. The primary mouse button is overloaded. Even the use of modifier keys as chords can't solve it all.
Click-dragging on selected text or other items can either change the selection or move the text. There's been quite a few times where I meant to do one, but the other occurred. The solution with text has been to differentiate based on how long the mouse was held down before dragging. But with no visual or other feedback, it's still easy to do the wrong thing.
Similarly, to move a window, only a tiny portion of the window allows movement. The rest is non-movement commands of selecting text and pushing buttons. I still miss the border that MacOS 9 windows had, giving an effective titlebar around the entire window. The brushed metal window was a throwback to it, in some ways. However, the border was extra clutter, and the slight shadows of most MacOS X styles frame the content better.
Resizing is the same issue, with the lower right corner the only point to change the entire window. And if the portion of the window dedicated to this function is obscured, the functionality of the rest of the window, which is plainly visible, is reduced. Windows and many unix window managers offer resizing widgets at the window fringes, but if the title-bar is offscreen, this still doesn't help.
A solution would be a second mouse button, one that isn't merely a menu keyboard key. One button would be to select, to activate, to serve as the primary button. The second would be to move. Move text, move items, move windows, and, if at the edge of a window, move the border, resizing. These are two very different actions. Pressing a physical button on a device is quite different than moving the device itself.
Relocating this functionality, to remove the drag from an already well-established primary button, and replaced the well-established menu button, is impractical. For better or worse, the current mouse layout is cast in stone, consistent across almost all mouse-based systems. Like iconic metaphors in car dashes, changing now would be counter-productive. The only real option is in future user interface designs.
Mostly.
In writing this article, I realized that there's one input device that still held true to a single button design. Sure, the track-pad has added buttons underneath, but the actual pad itself is pristine, used by a single finger in most cases. And it gets better. Since MacPaint, many graphics programs have had a hand tool, used to scroll the viewing area simply by click-dragging.
In the latest incarnations of Apple's trackpad, the user can simply place two fingers on the trackpad to scroll in any direction. In effect, this new mode is a hand tool for any scrolling area. While it doesn't effect window positions, nor moves text, it's a step in the right direction. Unlike the mouse, it doesn't matter if the user's left or right-handed. Unlike the mouse, the functionality isn't squandered on a popup menu. And since this action is so new, and in the shade of the pinching in the iPhone, there's a chance that scrolling, zooming, and moving can flourish as a separate command.
Finally, a true second mouse button. Only, not on a mouse, and not with a button.
