GUIdebook: Graphical User Interface galleryHome > Articles > “The Mac Interface: Showing Its Age”
Go backArticlesThe Mac Interface: Showing Its Age

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

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

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

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

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.

Don Crabb

Don Crabb is the director of laboratories and a senior lecturer for the computer science department at the University of Chicago. He is also a consulting editor for BYTE. He can be reached on BIX as “decrabb.”

Your questions and comments are welcome. Write to: Editor, BYTE, One Phoenix Mill Lane, Peterborough, NH 03458.

Page added on 5th June 2004.

Copyright © 2002-2006 Marcin Wichary, unless stated otherwise.