Reprinted from PC Magazine, July 1992, pp. 99-100.

Last time we looked at some of the artifacts that remain in the Windows interface, and at how Microsoft’s interface-design changes are catching up with our growing understanding of how GUIs can and should work.

Cleaning up such interface-convention problems as illogical keyboard shortcuts (such as Shift-Ins for Paste) in Win 3.1 was a big step. But many of Windows’ problems aren’t amenable to simple fixes.

The problem is that we don’t yet know enough about GUIs. This is a new field; we’re still figuring things out.

A favorite example is the floating (or tear-off) menu. When most PC users first see someone rip a menu from the header bar across the top of a window, then float it somewhere else on-screen, they go bananas.

I know the feeling: I fell hard for the idea myself. Being able to stash the Tools-selection menu palette in PageMaker next to the page rather than having it stuck in the right-hand corner of the display was wonderful; I shed all that mousing up and back.

But as whizzy as that idea first seemed, time and experience showed us that it isn’t as hot a feature as we thought.

A floating menu still leaves us with the job of choosing from among all those commands – not all of which are even relevant to our work. Why isn’t the computer smart enough to choose only the commands we want, and and show us just those?

Worse, the choices on that menu rarely represent the whole universe of commands we might need to accomplish our work. So we still have to make those long mouse roundtrips to the menu bar for those items that are buried under other menu headings. Why can’t the computer show us – in a combined menu palette right next to the selected object – all of the commands we need?

Enter the property inspector.

As good as floating menus looked, the newer property inspector idea is even better. Just select something in your document, spreadsheet, drawing program, or whatever, then click on the right mouse button. An ad hoc menu pops up next to the item you’ve selected, with access to everything you need to manipulate that item’s properties.

Borland started the property inspector idea, first seen in Object Vision 2.0 last year and coming in this year’s Quattro Pro/Windows and Paradox/Windows. Microsoft agrees that this is a good idea, but questions what we want in such a menu.

Borland hewed to the classical “manipulate an object’s properties” approach; Microsoft showed in Excel 4.0 that localized pop ups need verbs, too. That is, pop-up menus should list things you can do with an object – such as cut, copy, and paste – not just things that address the object’s properties, such as font and color.

Expect to see property inspectors in new releases of many programs. It’ll be interesting to see whose approach prevails. I’m betting on Microsoft’s more comprehensive answer. Windows itself will probably gain verb-inclusive property managers in Version 4.0, due next year.

If part of the puzzle in designing better GUIs is discovering new possibilities, another is managing the transition to newer ways of working with those interfaces.

This task is often neither simple nor obvious.

Implementing drag-and-drop is a perfect example: You might click on an icon representing a file, drag it over an icon representing a printer, and drop it there; the document is then printed.

That’s much faster and easier than loading the program, then loading the file, then choosing Alt-F, P, or using the mouse to issue the print command. Of course, if you already have the document on-screen, within the program, the Alt-F, P sequence is much faster.

When you’re at the Windows desktop level, however, and you want to drag-and-drop print the file, what should the keyboard shortcut – the interface convention – be?

It’s easy to drag and drop when you’re using a mouse. But many Windows users would rather use keyboard shortcuts to complete many tasks. It would be intolerable to have an important Windows function that you could not execute from the keyboard. Yet there is no logical keystroke equivalent to that action, because it is a new way of working. Interface conventions are based on our old ways of working.

Finally, continuity counts in interface design. I used to mutter about Microsoft’s shortsightedness every time I had to remember whether to use Shift-Del or Ctrl-Ins to cut something. In Win 3.1, that problem’s been cleaned up, and we have the more consistent Ctrl-X for cutting, Ctrl-C for copying, and Ctrl-V for pasting.

But what about older applications, such as PageMaker 4.0? Subsequent releases of these programs will explicitly support the new keyboard shortcuts, but because the programs work within the Windows environment, you can already use the new conventions with them. No more Shift-Ins for pasting; Ctrl-V does the trick – even if that doesn’t appear on PageMaker’s menus.

The evolution of interface conventions is not a pretty sight. We’ll see lots more shifts before we get it right – and with any luck, by then we’ll be using voice input instead of mice and keyboards.

Jim Seymour