Reprinted from PC Magazine, March 31, 1992, pp. 87-88.

Just as the Windows interface is really taking hold, it’s coming up short. And object orientation is the reason.

Long live the right mouse button! For in it lies our salvation from Windows’ tyranny of endless pull-down menus and forgettable speed keys. Here’s the problem: As Windows programs grow ever richer in features, the menus get deeper and more complex. Many choices bring up a dialog box with even more choices, or another set of menus, which in turn may bring up dialog boxes. Windows’ lack of sticky menus forces us to go through numerous mouse clicks and drags to set or change options. The solution is that other mouse button.

In his column, The Riddle of the Right Mouse Button (January 14, 1992), Michael Miller documented the widely differing uses of the right mouse button by various applications. His survey showed that software manufacturers care nothing for consistency, and use the right button as they see fit to enhance their applications. As Windows applications proliferate, this open-ended pattern cannot continue.

There’s a deeper problem, too: the Windows interface itself. It’s based on IBM’s Common User Access (CUA) specification, which is part of Systems Application Architecture (SAA) – IBM’s answer to the longstanding criticism that each of its hardware platforms has different interface standards for hardware, software, and communications. SAA is ahuge, sweeping specification that ostensibly will bring the disparate mainframe, minicomputer, and PC platforms together. CUA is a relatively small part of that super set; it addresses only the screen and keyboard. In turn, the pull-down screen interface is a small part of CUA. The basic work was done nearly ten years ago, and its age is beginning to show.

The object angle

The whole idea of a pull-down interface is that you can logically organize all the functions of a program in several major categories, then access the functions hierarchically. It makes sense, and it works – to a point. It breaks down when you must go back to the same menu again and again.

Word for Windows 2.0 is a perfect example of this menu frustration. Sometimes you’ll want to run it with the ruler, ribbon, and icon bar; other times, you’ll just want a clean screen. It’s six trips to the menu to change from one mode to the other. Another example is when you want to fit type by eye, say with Windows Write. You can select the text and repeatedly press Alt-C-E, which calls up the Character menu and the Enlarge option. Within the context of the existing interface, it would be far easier to lock the Character menu or Fonts submenu in place so that you could just click on the desired action and observe the results.

GeoWorks is an example of another method of menuing. It has tear-off menus, where you pull down the desired menu or submenu and lock it in place. Then you’re free to move it anywhere on the screen. Tear-off menus are handy but they also tend to clutter the screen.

Object orientation brings a fresh point of view to what we’ve been doing all along. And the right mouse button is the ideal way to invoke it. By selecting an object on the screen and clicking the right mouse button, you should get a menu of all the things you can do right now. In the aforementioned example of selecting some text, you should be able to alter any of its characteristics: font, size, attributes such as underlining or holding, color, opacity, and so on. You should have the further option of making the properties menu sticky, and having your selections take effect immediately. After all, what’s the point of a visual interface if you have to wait, even for the closing of a window, to get results?

Drag & droppings

The Windows interface is similarly useless in handling another feature that’s gaining popularity by leaps and bounds: drag and drop. Shells such as The Norton Desktop for Windows and WinTools implement drag and drop across applications. Drag and drop overcomes the ugliness of cutting something out of the document and into the Clipboard just so you can paste it somewhere else, either in the same document or even in another application. With drag and drop, you highlight the desired information, then hold down a button to drag it to its new home. My fond desire would be to drag the data with the left mouse button and drag its properties with the right button. Being able to drag the properties would be incredibly handy for doing repetitive formatting. It would also be a handy way to implement inheritance, another cornerstone of object orientation.

Inheritance allows an object to inherit its properties from another object. Picture an application that allows you to pop up a “styles in use” box that shows all of the styles in your document. In effect, you’re creating a stylesheet or template as you go. You’d be free to save the stylesheet or properties list to a file, or to drag properties from the list to another document.

This raises the question of whether objects that inherit properties from one another should have those properties linked, so that if you change the first, the second will change, too. More important, should the links be bidirectional? That is, if you change the properties of the second object, are the properties of the first changed? We can all think of examples in which it would be useful to have the properties unlinked, directionally linked, and globally linked.

My examples are word processor oriented, but the same principles apply in spreadsheets, presentation graphics programs, or even telecommunication programs. Slowly, we’re beginning to see these tools trickle into today’s applications – a sure sign that they’ll gain popularity in the coming years.

Windows to the rescue

Rather than letting each software vendor implement its own version of these tools, it’s critically important that Microsoft take the initiative and expand the user interface to manage objects. Without leadership, Windows applications will follow DOS applications into chaos.

Bill Machrone