Reprinted from Byte, issue 6/1989, pp. 235-237.
The best microcomputer user interface needs revamping, lest it turn from
state-of-the-art to stodgy
A month ago, my NeXT computer showed up, with its 17-inch MegaPixel display,
256-megabyte optical disk drive, 660-megabyte hard disk drive, and 400-dot-per-inch
laser printer. During my first two weeks with the NeXT computer, my thoughts
haven’t focused so much on this machine as on the Macintosh. I find
myself thinking about how far the Mac has progressed in the last five years
and how it compares to the NeXT computer.
Upon considerable reflection, I have to once again give my kudos to Apple
for producing what I still think is the best personal computer on the
market. Not the fastest. Not the sexiest. Not the most powerful. Not the
most expandable. Certainly not the cheapest. Just the best. So why is the Mac
the best microcomputer around? Its user interface.
More people can fire up a Macintosh right out of the box and start getting
work done the same day. Regardless of arguments to the contrary from
devotees of other user interfaces, and regardless of the inroads made on
the interface elements that we all think of as distinctly Macintosh (e.g., graphics,
icons, mouse, pull-down menus, special sound cues, and many user-definable
options), the Mac’s interface remains preeminent among those available today.
Unfortunately, during my first month of fiddling with the NeXT computer and
its beta 0.8 software and Mach operating system, it has become clear to me that
the once state-of-the-art Macintosh interface is really starting to show its
age. Regardless of how Apple modifies the Macintosh operating system over the
next couple of years to make it more powerful and better able to extract the
full horsepower out of its hardware, the company must also extend and improve
its aging user interface.
I’ve put together a list of possible improvements for future Mac
interfaces. It’s quite likely that some of these ideas couldn’t be
easily applied without an extensive overhaul of the System, Finder, and
MultiFinder. So be it.
Apple’s real competitive advantage in today’s microcomputer
market is the Macintosh user interface. In fact, that’s always been
the case. That’s why I (unlike other industry watchers) don’t
really have a problem with Apple’s “look and feel” lawsuit
against Hewlett-Packard and Microsoft. Apple should protect its
Regardless of whether the company has a legal leg to stand on in its suit,
Apple’s moral obligations are quite clear: It owes it to its shareholders
and customers (many of whom put their professional lives in jeopardy to
bring Macs into their companies a few years ago) to protect the interface
from being ripped off by competitors. Apple spent considerable time
and money on developing the Mac interface; in my opinion, the company is
entitled to reap whatever rewards the marketplace deems appropriate for
My suggestions for improving the Mac interface assume that some important
new computing paradigms aren’t put on the market by Apple or others over
the next two years. If you assume that the
microcomputer interface market will continue to make incremental improvements
over that period, then my suggestions fit right in.
Improvements need to be made in six different areas: the desktop, file
management, the use of sound, the way windows are displayed and used, general
operation, and the integration of development and user environments.
The Apple Desktop has aged less gracefully than any other part of the
Macintosh interface. A month’s worth of NeXT work, plus daily work with
other interfaces, like X Windows, has made this clear to me.
Apple needs to make the Desktop more dynamic, more configurable, and more
powerful. For example, why can’t you tear off any item on the Mac
menu and stick it on the screen (open, of course) where you need it? Sure,
you can do this with some individual software, and some shareware utilities add
this capability to programs, but it needs to be a standard feature, built
in and available to developers.
In the same vein, how about resizable menus? Or how about menu items that
you can link to function or option keys for one-time use and that revert back
to some status quo? How about the ability to place menus at the bottom of the
screen, or on the left or right side, or to get rid of them altogether?
The basic point here is that the current pull-down Mac menus are too staid and
too static. You should be able to reconfigure them and store Desktop configuration
settings. That way, you can create and save a number of customized working
environments attached to specific applications.
Naturally, a configurable Desktop needs some real computing power behind it.
To accommodate the interface changes I’ve suggested, the Macintosh operating
system will have to become fully multitasking and will have to offer all the
features that a fully multitasking system demands. Such features would have
to include virtual memory paging, preemptive event scheduling, and interprocess
and interapplication communications.
Once Apple has strengthened the Desktop, the company should improve file
management capabilities. The biggest change, which could also be categorized
as a Desktop or general operational improvement, would be the introduction
of a command-line interface.
I’m not arguing here for a return to MS-DOS’s C> prompt or
Unix’s % prompt, but the Mac needs some kind of shell window (similar
to Unix running with X Windows or Mach running with NextStep) that can
be popped up as needed for direct file management operations. This shell window
could also be used instead of pull-down menus if a power user felt
so inclined. But the real purpose of the shell window would be to manipulate
odd groupings of files in ways that just aren’t possible with a mouse but
are child’s play when done with commands.
To this end, the command-line interpreter needs a Unix-style grep (global
regular-expression parser) facility. The grep commands can flag lines of
input filenames that match a pattern and copy them to another file. Of course,
to be really useful, the improved Mac file manager would have to include
many (if not most) of the techniques used in Unix to keep track of files,
filenames, and directories. The file manager would also need things
like wild-card character support, so groups of files could be manipulated together.
The future Mac operating system shouldn’t become a Unix kernel with Mac
window dressing, however. If Apple is going to maintain its competitive
edge and protect its intellectual property, it makes more sense for the
Mac operating system to incorporate the kinds of file management capabilities
I’ve hinted at here, without resorting to simply “Macifying”
Unix. What I’m arguing for is a maturation of the Mac file interface by
including features that are common to today’s Unix and OS/2 interfaces,
the most important of which is the command-line shell.
One way to extend current command-line shell interfaces would be with the
improved use of sound. While a Sound Finder has been rumored to be under
development by Apple for years, I don’t think the use of sound needs to
go far to become much more effective than it is now. For example, Farallon’s
Mac-Recorder has shown just how effective it is to link short sound bites
(like quick notes or file descriptions) to files containing other information.
Imagine how much more informative it would be if, in the Finder, you could
click on a file you’d just created and add a short spoken note to it,
a note that could be replayed at any time.
Suppose you have a partially complete C program that a colleague is going to
take a look at to help you fix an incorrect algorithm. With the new sound
capabilities of the Finder, you could first append an auditory note that plays
when the file is opened, telling your colleague where to look for the
bad algorithm. In just a few spoken sentences, you could convey more
information in that note than you can with a filename or with written
comments, because your voice projects inflections and emphasis that written
This use of voice annotation is just one way the Finder’s management of
sound resources could be improved. With the availability of better sound
compression and digitization techniques, the increased use of special
digital sound-processor chips, and the drop in price of very large hard
disk drives and read/write optical disk drives, I have every confidence
that the hardware necessary for successful sound management on a Mac will
soon be in place.
Did you ever wish you could tile all your Finder windows with a quick
Desktop command, or automatically overlap them, or reduce them to icons and
sweep them into the corners of your screen? And what about resizing windows
in any direction? Why is the Finder limited to a single resizing handle in
the bottom right corner of a window?
While the current Macintosh interface does a creditable job of window
management, there’s significant room for improvement. Overall, the
windowing interface should be more flexible, offer more configuration
options, and be controllable from the new command-line shell window.
Specifically, with a command-line shell window, you could write special window
scripts (since no command-line interface is worthy of the name if it
doesn’t have its own script language) that could invoke different
kinds of windows based on their purpose and environment. Software
authors could write programs to invoke a particular style of window,
but you could override their choices. Once again, the key improvement
A lot of little things have always bugged me about the Mac interface. Why
can’t I change the fonts (or sizes, or styles) in the menu bar or
in the application menu without having to resort to using someone’s
shareware utility? Why can’t I throw away the menu items I don’t
need from the Desktop or from any application? Why can’t I resize icons
or get rid of them altogether (without switching to a “Name”
view)? Why can’t I – well, you get the idea.
When you’ve used the Mac for as long as I have, you develop a number
of pet peeves. I would categorize these as general operational improvements.
I’m sure Apple has a bunch of these kinds of suggestions squirreled
away, given all the market research the company does. It’s time to pull
them out and see which ones would really improve the Macintosh interface.
Finally, we come to development and user integration. All the changes I’ve
suggested in this piece are worthless unless MPW/MacApp provides developer
support for them. All modifications made to the Macintosh interface need
to permeate through third-party applications, rather than appear
just on the Desktop.
I hope Apple is working on the next-generation Macintosh operating system
and that it includes some of the improvements I’ve outlined here. Given
Apple’s responsive nature in the past and its commitment to the
extension of the Macintosh computing metaphor, I’d be surprised if we
don’t start seeing some of these improvements before too long.