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
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
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.