|
|
|
Alan Cooper has a legendary status among Windows programmers. This is due partly to his talents as a writer and speaker, partly to his somewhat murky reputation as the "Father of Visual Basic," and partly to the widespread perception that he beat Microsoft at their own game, then cashed in and walked away without a scratch. Rather than sit in his gazebo and clip coupons from his Microsoft stock, however, Cooper has chosen to put his fame as a user interface guru on the line in About Face.
The first thirteen chapters of About Face address global issues: programmers' versus users' mental models of program operation and file systems, what Cooper refers to as program "posture," and the application's facilitation of workflow (or impedance of same). The middle set of chapters deal with relatively low level, technical aspects of application "affordances" -- buttons, menus, cursors, dialog boxes, and so on. The last seven chapters return to more philosophical musings on errors, exception handling, installation, personalization, "undo" facilities, and the future of user interfaces.
Cooper has a lot of valuable things to say about program design and behavior. His comments on sovereign as opposed to transient programs, the evolving role of menus in the era of toolbars, nested and tabbed dialogs, drag-and-drop, and the tendency of most commercial applications to "go stupid" without warning for unpredictable lengths of time were interesting and thought-provoking. I particularly enjoyed his railings against the many idiotic applications which provide unbounded controls for user input, and then immediately turn around and slap the user's wrist for entering an illegal value.
Although About Face is subtitled "The Essentials of User Interface Design," it is really about "The Essentials of Windows Application User Interface Design." The book does mention the Apple Macintosh and the Xerox Star in passing, but I get the impression that Cooper's experience with alternative modern GUIs such as OS/2 Warp, Macintosh OS, NextStep, and the UNIX variants is minimal. Certainly Cooper's perspective comes across in the book as quite parochial, and he passes up many opportunities to compare and contrast Windows features with their (often superior) counterparts in other systems.
Other weaknesses of the book include Cooper's widespread use of self-invented, idiosyncratic terms for user-interface issues and objects, wide swings in technical level, and the apparent absence of a strong manuscript editor. But the Windows-95 orientation will probably have the most serious effect on the book's long-term value. Even before the majority of PC-compatible users have switched from Windows 3.1 to Windows-95, Microsoft is preparing to jettison the Windows-95 interface in favor of a new Web-browser-based metaphor.
With typical IDG hyperbole, About Face's cover blurb quotes Stewart Alsop as saying "Alan Cooper is a software god... This is a landmark book." That's stretching things a bit for my taste; my conception of a software god runs more to the likes of Donald Knuth, and of landmarks more to the likes of Donald Norman's Design of Everyday Things. This is a good book, and certainly light-years better than Microsoft's own pathetic little application style guides (which are conspicuously ignored by Microsoft programmers), but it would need a broader base and some stringent editing to be a great one.
-- Ray Duncan
It has been said that the great scientific disciplines are examples of giants standing on the shoulders of other giants. It has also been said that the software industry is an example of midgets standing on the toes of other midgets. This old joke seems particularly relevant with respect to standards.
Nothing is more paradoxical in the software industry than standards. Standards are easily the biggest aid to interface designers. Standards are also the biggest obstacle for interface designers. The lack of standards is the biggest aid to interface designers. The lack of standards is also the biggest obstacle for user interface designers.
If this were the business of making soap or paper or drinking glasses, we would have well-established standards and they would be slowly, so slowly creeping forward decade by decade. The solidity of standards allows producers and consumers alike to depend on quality, features and price. There are no great technological changes in the world of soap or paper or drinking glasses, so their respective apple-carts remain upright. In software, though, new technologies and techniques appear monthly. In the world of user interface design, we desperately need all the advances we can get. Naturally -- it seems -- we should immediately discard the old for the new, except that users and vendors hate moving targets.
Standards allow us to consolidate our technological gains and exploit our collective accomplishments. Standards are a plateau in the steep climb of invention. They may hinder innovation, but they allow commercial products to build a base of customers. This commercial success in turn funds more invention.
The big standards, like interface paradigms and platforms, are set de facto -- by the market. Only now, after twenty years, is Microsoft powerful enough to establish standards de jure -- by declaration. And even there, Microsoft is only effective on the fringe standards like MAPI and TAP, while standards on center stage like OBDC and OLE are fiercely contended by others.
IBM's foolish CUA was a last-gasp attempt by the fading giant to set a standard de jure in an area where none was wanted; plus, they had virtually no expertise. CUA failed because it was too much, too soon and too much of a lowest common denominator. Calculated to offend no one, it offended all.
On the other hand, designers and inventors hate standards because they cramp their style and obstruct their pushing out of the boundaries of the envelope.
I hear amateur user interface designers and programmers speak of user interface standards all the time as though they are codicils recorded in a big book somewhere. It's as though Apple or Microsoft had figured out the right methods for all time and it is our duty to perpetuate them. Sure, both companies actually have published user interface guidelines, but both companies freely break them and then update the guidelines.
In the Windows world, we really don't have standards as much as we have big examples. Our standards are "what Excel does" or "what Word does." Every time Microsoft proposes something as standard, they willfully go ahead and change it for something better in the next version. And they should. Interface design is today in its infancy and it is silly to think that there is benefit in chiseling our baby steps in granite.
Windows 1.0 violated the standards set by MS-DOS. Windows 2.0 violated the standards of 1.0. Windows 3.0, 3.1, and Windows 95 each stepped on their predecessors in turn. The Macintosh was such a spectacular achievement because it absolutely abandoned all of Apple's previous platforms.
Conversely, much of the strength of the Mac came from the fact that vendors all followed Apple's lead and made their interfaces look, work, and act alike. Similarly, many successful Windows programs have been unabashedly modeled after Word or Excel. You should be getting a sense of where I'm going by now, as I keep goring user interface design on the horns of the "standard" dilemma. When we find two otherwise true propositions in direct opposition. The answer is to rephrase the question. Instead of asking whether we should follow standards, the question must be articulated more like this: When should we violate standards? The answer to this question is simple, but difficult: We should violate standards whenever we have a darn good reason to.
Of course, this begs the question: What makes a darn good reason? Personal preference is out, including those of your client or user-test subjects. I'd like to answer "when a new idiom is measurably better," but I am deeply suspicious of the objectivity of contemporary "measurement" approaches. The real answer is the de facto answer: when the idiom can be seen to be manifestly better, go ahead and use it. This is how the toolbar came into existence, along with buttcons, outlines, tabbed dialogs, and many other idioms. Scientists and academics may have been examining these artifacts in their labs, but it was their presence in real-world software that showed the way. Your reason may ultimately prove to not be darn good and your product will suffer -- possibly die -- but designers will learn from its lack of merit. This is what Christopher Alexander, in Notes on the Synthesis of Form (Harvard University Press, 1964), calls the "unselfconscious process," an indigenous and unexamined process of slow and tiny forward increments as individuals attempt to improve solutions. Like art.
-- from About Face, pages 499-501.
A dialog box is another room. Have a good reason to go there.
A gallon of oil won't make a bicycle pedal itself.
A multitude of gizmo-laden dialog boxes doth not a good user interface make.
A rich visual interaction is the key to successful direct manipulation.
A visual interace is based on visual patterns.
Accepting bounded data into unbounded gizmos is an important source of user dissatisfaction.
All idioms must be learned. Good idioms only need to be learned once.
Allow input wherever you output.
Any command is a working set candidate.
Ask forgiveness, not permission.
Audit, don't edit.
Consistency is not necessarily a virtue.
Directly offer enough information for the user to avoid mistakes.
Disks and files make users crazy.
Disks are a hack, not a design feature.
Do, don't ask.
Don't hamper primary markets by serving secondary markets.
Don't make the user look stupid.
Don't put might on will.
Don't stop the proceedings with idiocy.
Good user interfaces are invisible.
Hide the ejector seat levers.
Hot, simple and deep.
If it's worth asking the user, it's worth the program remembering.
Imagine users as very intelligent but very busy.
It's not your fault, but it's your responsibility.
Make errors impossible.
Make everything reversible.
Never bend your interface to fit a metaphor.
Never make the user ask to ask.
No crisis within a computer is worth humiliating a human.
No matter how cool your interface is, less of it would be better.
Nobody wants to remain a beginner.
Obey standards unless you've got a darn good reason.
One user's excise task is another user's revenue task.
Optimize for intermediates.
Provide an escape from dragging, and inform the user.
Purchase the right software then buy the computer that runs it.
Put primary interaction on the primary window.
Questions aren't choices.
Show don't tell.
Sovereign users are experienced users.
The computer does the work and the user does the thinking.
The customer is always right.
The goal of all software users is to be more effective.
Things that behave different should look different.
Transliterated mechanical models are always worse on computers.
User interface design is not guesswork.
User interface is not just skin deep.
User interfaces that conform to implementation models are bad.
User testing can never substitute for user interface design.
Users don't make mistakes.
Users get humiliated when software tells them they failed.
Users make commensurate effort.
Users would rather be successful than knowledgeable.
Visually hint at compliancy.
Visually show what, textually show which.
-- from About Face, pages 555-556.
All dialog boxes should have caption bars.
Any program that demands precise alignment must offer a vernier.
Any scrollable drag-and-drop target must autoscroll.
Build function controls into the window where they are used.
Build the program to run on only one platform.
Button-down means propose action, button-up means commit to action over gizmos.
Button-down means select over data.
Cancel drags on chord-click.
Debounce all drags.
Dialogs break flow.
Dialogs should be as small as possible, but no smaller.
Disable menu items when they are moot.
Don't put close boxes on modal dialogs.
Don't stack tabs.
Don't use bang menu items.
Don't use dialogs to report normalcy.
Double-click means single-click plus action.
Eliminating excise makes the user more effective.
Error message boxes stop the proceedings with idiocy.
Every text item in a list should have an identifying graphic icon next to it.
Give modeless dialog boxes consistent terminating commands.
Have a reason for each idiom.
Indicating pliancy is the most important role of cursor hinting.
Make selection visually bold and unambiguous.
Menus and dialogs are the pedagogic vector.
Never change terminating button captions.
Never create a system-modal dialog box.
Never scroll text horizontally.
Never use sustaining dialogs as error messages or confirmations.
Never use terminating words in dialogs.
Offer bounded gizmos for bounded input.
Offer OK and CANCEL buttons on all modal dialog boxes.
Offer shortcuts from the help menu.
Offer the user a gallery of good solutions.
Parallel visual symbols on parallel command vectors.
Prepare for the probable case.
Put terminating buttons on untabbed area.
Show validated entry gizmos with a different border.
Single-click selects data or changes the gizmo state.
The drag cursor must visually indicate the master object.
The drop candidate must visually indicate its dropability.
The program must inform the user when it gets stupid.
The program should be designed expressly for the target platform.
The program should perform optimally on hardware that doesn't exist yet.
Toolbars provide experienced users with fast access to frequently used functions.
Use COLOR_HIGHLIGHT and COLOR_HIGHLIGHTTEXT to show selection.
Use cursor hinting to show meta-key meanings.
Use object names in property dialog caption bars.
Use verbs in function dialog caption bars.
Users don't understand boolean.
Visually differentiate modeless dialogs from modal dialogs.
-- from About Face, pages 557-558.
|
1 |
Goal-Directed Design |
|
2 |
Software Design |
|
3 |
The Three Models |
|
4 |
Visual Interface Design |
|
5 |
Idioms and Affordances |
|
6 |
An Irreverent History of Rectangles on the Screen |
|
7 |
Windows-with-a-Small-w |
|
8 |
Lord of the Files |
|
9 |
Storage and Retrieval Systems |
|
10 |
Choosing Platforms |
|
11 |
Orchestration and Flow |
|
12 |
Posture and State |
|
13 |
Overhead and Idiocy |
|
14 |
The Secret Weapon of Interface Design |
|
15 |
Elephants, Mice, and Minnies |
|
16 |
Selection |
|
17 |
Direct Manipulation |
|
18 |
Drag and Drop |
|
19 |
The Meaning of Menus |
|
20 |
Menus |
|
21 |
Dialog Boxes |
|
22 |
Dialog Box Etiquette |
|
23 |
Toolbars |
|
24 |
Roll the Credits, Please |
|
25 |
Imperative and Selection Gizmos |
|
26 |
Entry and Display Gizmos |
|
27 |
New Gizmos |
|
28 |
The End of Errors |
|
29 |
Managing Exceptions |
|
30 |
Undo |
|
31 |
Good at What You Do |
|
32 |
Installation, Configuration, and Personalization |
|
33 |
Shouldering the Burden |
|
34 |
Where Do We Go from Here? |
|
Readability |
|
|
Originality |
|
|
Organization |
|
|
Accuracy |
|
|
Consistency |
|
|
Depth |
|
|
Timeliness |
|
|
Editing |
|
|
Design |
|
|
Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.
