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.