Here's the problem: As programmers, we build programs function by function. Users, however, want to use software in a way that enables them to achieve their goals. It's an unfortunate fact that the view of software you get from looking at it function by function is likely to be orthogonal to the view you get from looking at it in terms of user goals.
Complicating the problem is the fact that the user's goals are probably not what we think they are, and probably not even what the users say they are.
Here's the thesis: The user interface should be designed on the basis of the user's goals, not on the basis of the internal functional structure of the program. That's probably not too shocking a thesis, but it's rarely followed with any real rigor. In fact, it's violated regularly, even in shrinkwrapped, commercial software from established companies. It's easy, though, to state the programmer's goals, or rather the user-interface designer's goals, that are implied by this thesis:
The thesis has, over the past few years, motivated much of the user-interface design work of Alan Cooper, including his design of the user interface for Visual Basic. Cooper, a well-known user-interface consultant and software designer, is the recognized "Father of Visual Basic" and the author of About Face: The Essentials of User Interface Design (IDG Books, 1995, ISBN 1-56884-322-4), a book based on the concept of goal-centered design for user interfaces. It's a book that should be read by every...
But let's hear who the author thinks should read it.
Authors' expressed ideas about who is likely to profit from reading their books ought to be taken with a grain of salt. For one thing, many authors honestly and fervently believe that everyone would be better off if they would just commit the author's books to memory, or at least read a few choice lines before breakfast every day. Not all authors are this self-assured, but even if they aren't, their publishers are unlikely to let them include introductory notes characterizing the potential market for their books so cautiously that the bookstore browser gets the idea that the book really isn't for him unless he was one of a dozen aerospace engineers working on a particular project at NASA Ames Research Center in the late '80s.
Cooper's views on who should read his book are something different. And I'm not just talking about his "Who should read this book" section in the "Introduction."
Throughout the book, Cooper implicitly defines a new job classification--the professional user-interface designer. This is not surprising when you consider that he explicitly defines this new career path every day for his staff at Cooper Software. These professional user-interface designers are the ideal readers for the book. Ideal, but rare. Since there are about as many professional user-interface designers today as there were aerospace engineers working on a particular project at NASA Ames Research Center in the late '80s, I'm sure his publisher is glad he didn't explicitly characterize his readership that way.
Explicitly, he says that the book should be read by those programmers, documentation writers, trainers, and technical-support people who are aware of and concerned about the need for better software design. Personally, I think that everyone should be concerned about it; or, to put it another way, I think everyone would be better off if they would just commit the entirety of About Face to memory.
Magazine art directors and automotive designers know that you can talk about design at different levels. There's the large-vision level, where you lay out broad strategies and concepts, and there's the specific-detail level, where decisions are more tactical. About Face tackles user-interface design at both levels. Cooper makes a point of presenting both strategic and tactical advice. "There is no such thing," he says, "as an objectively good dialog box--the quality depends on...who the user is and what his background and goals are." What's good tactically is a function of strategic considerations.
Getting the result you want, Cooper says, requires that you maintain "a strategic sensitivity for how users interact with specific software. This will enable you to correctly choose the appropriate tactics to apply in a particular situation."
This is a very readable book, primarily because it so well thought out and because the voice is so clear. Cooper makes strong assertions that, even if you disagree with them, really focus attention on important design issues. I find myself agreeing with most of them. A few examples:
Of all the misconceptions to emerge from Xerox PARC, the global metaphor myth is the most debilitating and unfortunate.
The Mac didn't succeed because of [the] metaphors...but because it was the first computer that defined a tightly restricted vocabulary...for communicating with users.
I believe that, with proper design, all error messages and confirmation dialogs can be eliminated. I'll tell you how.
Today's Help menus are poorly designed reflections of poor help systems.
The canonical mode of the book, though is imperative, not declarative. For example:
Allow input wherever you output.
Never make the user ask to ask.
Never scroll text horizontally.
Debounce all drags.
And this one:
Don't make the user look stupid. In the course of this book we will examine numerous ways in which existing software makes the user look stupid and explore ways to avoid that trap.
And he does. Cooper uses real, commercial software in his examples. Since he often seriously criticizes particular aspects of the programs' user-interface design, this can be--er, interesting. Cooper can be brutal.
To demonstrate the danger of bending your interface to fit a metaphor, he rips apart the MagiCap interface from General Magic, which he calls, in only apparent praise, "the acme of the expression of the metaphoric paradigm."
Nothing in the program is done without a thorough metaphoric rationalization...All of the interaction has been subordinated to the maintenance of these metaphors. I'm sure it was a lot of fun to design. I'll bet it is a real pain to use.
He points out, for example, that when you want to call people, you must go down the metaphorical street to the metaphorical phone-company building, and metaphorically enter it. You must do this every time you want to call someone. The metaphor is a mechanical-age model, and it imposes all the limitations of the mechanical age on a device that is supposed to be an information-age communicator. Is this progress, Cooper wonders.
One of the things I like best about the book is Cooper's willingness to neologize. He creates new terms whenever he needs them, and I'll let you read for yourself his justification for doing so.
I'll also let you read the other topics that the book covers and that are not touched on in this brief account, including his "Irreverent History of Rectangles on the Screen," "Overhead and Idiocy," "The Secret Weapon of Interface Design," "The Meaning of Menus," "Dialog Box Etiquette," and other entertaining and enlightening subjects.
Although Cooper tries to credit the originators of ideas, I feel compelled to point out Ted Nelson has been talking about the myth of metaphors and the tragedy of files, in almost those words, for years.
Quibbles aside, About Face is a must-read for any software designer or anyone interested in software design.
The rest of this column is the second installment in my survey of programming paradigms.
This survey began last month by looking at some implementations of languages characterized by a common feature: They are not C. As it happens, they have a couple of other things in common: The languages or some of their implementations are in the public domain or are distributed as freeware or shareware, and they are available on the Macintosh. If I live long enough and get my Intel box back in action, I'll eventually move on to languages with implementations on Windows, although most languages do have implementations on several platforms. The ones I'm looking at now I've examined on the Mac platform. This month continues the survey with a language that is definitely not C and that does have free implementations. It's available on the Mac, but not as available as had once been expected, and thereon hangs a tale.
Dylan was to be Apple's effort to change the nature of programming languages. Although it was never strictly an Apple project, Apple funded a team of researchers at Cambridge and started promoting Apple Dylan. Then, last fall, with profits down 40 percent, sales projections disastrously muffed, PowerBooks bursting into flames, and a president in trouble (no, no, Apple's president), Apple took decisive action. It canceled all funding for its Dylan team. A banner headline at the Cambridge Website says it: "Apple: The power to cancel your very best."
Just a few months ago, Apple was waxing rhapsodic about Dylan. Whatever you wanted in a language, Dylan had it, or so Apple was saying. Here's what Apple said right up to the day of canceling the project:
Dylan is a new language developed at Apple. It is a bold new effort to create a powerful, practical tool for writing mainstream commercial applications. We believe it combines the best qualities of static languages with the best qualities of dynamic languages.
Apple may still be saying that Dylan is a bold new effort, et cetera. It's just a little too bold for the Apple of 1996, apparently. Dynamic languages, of course, have the virtue of letting you program in an interactive style, leading to rapid development and prototyping. They are typically more robust against errors because they retain more information at run time. They typically have automatic memory management. Their interactive style may be implemented as an interpreter, a byte-code compiler, or an incremental native compiler. They typically have dynamic type information. All this adds up to code that's easy to read, write, and maintain.
The virtues of a static language, of course, are small, fast applications and the fact that you had it hammered into your head in school to the extent that you now naturally think in C--I mean, in a static language. You may have seen demos of Dylan; I've been seeing them for some time now, and they are impressive, at least when they're done by one of those professional Apple demoers. Actually, even playing around with the toy implementations leaves one--this one anyway--pretty impressed.
Dylan really is cool.
Dylan is actually an object-oriented, dynamic language--a language that has automatic memory management, supports dynamic linking and incremental development, and provides self-identifying objects, according to Joseph Dumas and Paige Parsons, writing about it in Communications of the ACM, Vol. 38 #6, June 1995.
Many of the promised benefits of Dylan are features of the proposed development environment, like storing your project in a database rather than in files, customizable browsers, and the ability to inspect objects in your program while it's running. Dumas and Parsons point out that this is common: The popularity of Visual Basic is probably not attributable to the love we all harbor for the Basic language. Dylan has undergone a lot of change in response to feedback in the past four years. By the time you read this, a definitive reference specification known as the Dylan Reference Manual may be available online. Or then again, it may not. It's not clear at this writing how sweeping the effect of the Dylan cancellation will be. But the Dylan language design is in the public domain.
All implementations of Dylan as of late 1995 were toy or experimental implementations, strictly for exploration and hacking. Chief among these are Marlais, an experimental Dylan interpreter written in C and available for UNIX, Macintosh, and Windows; and Mindy, an experimental byte-code compiler and interpreter written in C at Carnegie-Mellon University and available for UNIX and Macintosh.
I've played with MacMarlais, a port of the UNIX program Marlais to the Macintosh, created by Patrick Beard. It implements a subset of the Dylan infix syntax. MacMarlais uses multithreading to make the user interface responsive even while the interpreter is running. It handles Apple Events, and you can add code resources to it to extend its functionality. Marlais is available from ftp://ftp.cis.ufl.edu/pub/Marlais/, and MacMarlais is available from ftp://ftp.bdt.com/home/beard/. Mindy was developed by the Gwydion Project at Carnegie Mellon University for internal use as a development tool while they work on their "real" Dylan implementation.
Mindy is an acronym meaning "Mindy Is Not Dylan Yet", and as the name implies, Mindy is incomplete. The Gwydion folk claim, though, that it implements most of what they expect Dylan to include. Gwydion, their high-quality, integrated Dylan development environment for UNIX, should be out this year. Check it out at http://legend.gwydion.cs.cmu.edu:8001/gwydion/. Mindy is available by anonymous ftp at legend.gwydion.cs.cmu.edu in the file /afs/cs.cmu.edu/project/gwydion/release/mindy.tar.gz.
Also look for an implementation from Harlequin early this year. Harlequin has been developing DylanWorks, a dynamic development environment and native compiler for the Dylan language. When released, Harlequin expects it to produce small, fast, commercial-quality applications. DylanWorks will initially be released for Windows 95 and Windows NT, and will provide full interoperability with OLE and Win32 functionality. You can find out about it at http://www.harlequin.com/full/dylan.html.
Whether or not Dylan survives Apple's dropping of its project, it seems likely that we will see the best features of Dylan migrate into traditional language compilers and development environments.
Dylan information is at this writing available from ftp://ftp.cambridge.apple.com:/pub/dylan/. The Dylan Web page at Carnegie Mellon University is http://legend.gwydion.cs.cmu.edu:8001/dylan/. The Dylan newsgroup is comp.lang.dylan.
Easy to state, not so easy to achieve. But help has arrived.About Face
Strategy and Tactics
The Master's Voice
A Real Pain to Use
Keep it by Your Keyboard
Blowin' in the Wind
What was it You Wanted?
I Shall be Released