- Shopping Bag ( 0 items )
This book expresses the intangibles of interface design with clarity and practical functionality. Cooper combines tactical and strategic tools, allowing you to create user interface features, while also experiencing as a user world. The edict here is to understand the user`s goals along with the applications and the technology. Subjects covered include windows, files, platforms, mouse, drag & drop, menus and dialog boxes. You`ll also study sequence of commands, toolbars and undo functions. An interesting section discusses flow, orchestration (creating a coherent interface) and "modeless feedback." In modeless feedback, information is built into the interface in a seamless fashion; there is no dialog box barging in, interrupting activities.
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.--Dr. Dobb's Electronic Review of Computer Books
PART I: The Goal.
Chapter 1: Goal-Directed Design.
Chapter 2: Software Design.
Chapter 3: The Three Models.
Chapter 4: Visual Interface Design.
PART II: The Form.
Chapter 5: Idioms and Affordances.
Chapter 6: An Irreverent History of Rectangles on the Screen.
Chapter 7: Windows-with-a-Small-w.
Chapter 8: Lord of the Files.
Chapter 9: Storage and Retrieval Systems.
Chapter 10: Choosing Platforms.
PART III: The Behavior.
Chapter 11: Orchestration and Flow.
Chapter 12: Posture and State.
Chapter 13: Overhead and Idiocy.
Chapter 14: The Secret Weapon of Interface Design.
PART IV: The Interaction.
Chapter 15: Elephants, Mice and Minnies.
Chapter 16: Selection.
Chapter 17: Direct Manipulation.
Chapter 18: Drag-and-Drop.
PART V: The Cast.
Chapter 19: The Meaning of Menus.
Chapter 20: Menus.
Chapter 21: Dialog Boxes.
Chapter 22: Dialog Box Etiquette.
Chapter 23: Toolbars.
Chapter 24: Roll the Credits, Please.
PART VI: The Gizmos.
Chapter 25: Imperative and Selection Gizmos.
Chapter 26: Entry and Display Gizmos.
Chapter 27: New Gizmos.
PART VII: The Guardian.
Chapter 28: The End of Errors.
Chapter 29: Managing Exceptions.
Chapter 30: Undo.
PART VIII: The Teacher.
Chapter 31: Good at What You Do.
Chapter 32: Installation, Configuration and Personalization.
Chapter 33: Shouldering the Burden.
Chapter 34: Where Do We Go from Here?
The Save Changes dialog box is based on a bad assumption. The very presence of the dialog assumes that saving and not saving are equally probable. The dialog gives equal weight to these two options, even though the yes button is pressed orders of magnitude more frequently than the no button. As Idiscuss in Chapter 11, this is a case of putting might on will. The user might say no, but the user will almost always say yes.
There is another odd thing about the dialog, and Mom will probably wonder about it. Why does it ask about saving changes when you are all done? Why didn't it ask when you actually made them? The connection between closing a document and saving changes isn't all that natural, even though we power-users have gotten quite familiar with it.
Mom is thinking "If I didn't want those changes, I would have undone them long ago." To her, the question is absurd. The program issues the dialog box when the user requests close or quit because that is the time when it has to reconcile the differences between the copy of the document in memory with the copy on disk. The way the technology actually implements the facility associates changes with the close and quit operations, but the user doesn't naturally see the connection. When we leave a room, we don't consider discarding all of the changes we made while we were there. When we put a book back on the shelf, we don't first erase any comments we wrote in the margins.
Computer geeks are very familiar with the connection between saving changes and closing or quitting. They don't want to lose this ability because it is familiar to them, but familiarity is a really bad design rationale. We don't want to keep repairing our car just because we are familiar with the shop. We don't want to keep getting root canals just because we are familiar with the drill.
As experienced users, we have learned to use this dialog box for purposes for which it was never intended. There is no other easy way to undo massive amounts of changes, so we just use the Save Changes dialog and answer it with a no. If you discover yourself making big changes to the wrong file, you use this dialog as a kind of escape valve to return things to the status quo.
AXIOM: Disks and Files Make Users Crazy
Even though the file system is an internal facility that shouldn''t-by all rights-even affect the user, it creates a large problem because the influence of the file system on the interface of most programs is very deep. The most intractable problems facing user interface designers usually concern the file system and its demands. It affects our menus, our dialogs, even the procedural framework of our programs, and this influence is likely to continue indefinitely unless we make a concerted effort to stop it.
Currently, most software treats the file system in much the same way that the operating system shell does (Explorer, File Manager). This is tantamount to you dealing with your car the same way your mechanic does. Even though this approach is tragically bad, it is an established, de facto standard and there is considerable resistance to improving it.
The implementation model of the file system runs contrary to the mental model almost all users bring to it. In other words, they picture files or documents as typical documents in the real world, and they imbue them with the behavioral characteristics of those real objects. In the simplest terms, users visualize two salient facts about all documents: First, there is only one document, and second, it belongs to the user. The file system's implementation model violates both of these rules: There are always at least two copies of the document, and both belong to the program.
Saying that someone is "computer literate" is really a euphemism meaning that he has been indoctrinated and trained in the irrational and counter-intuitive way that file systems work, and once you have been properly subverted into thinking like a computer nerd, the obvious ridiculousness of the way the file system presents itself to the user doesn''t seem so foolish.
Every data file, every document and every program, while in use by the computer, exists in a minimum of two places at once: on disk and in main memory. The user, though, imagines his document as a book on a shelf. Let's say it is a journal he is keeping. Occasionally, it comes down off the shelf to have some words added to it. There is only one journal, and it either resides on the shelf or it resides in the user's hands. On the computer, the disk drive is the shelf, and main memory is the place where editing takes place, equivalent to the user's hands. But in the computer world, the journal doesn't come "off the shelf." Instead a copy is made, and that copy is what resides inside the computer. As the user makes changes to the document, he is actually making changes to the in-memory copy, while the original remains untouched on disk. When the user is done and closes the document, the program is faced with a decision. It must decide whether to replace the original on disk with the changed copy from memory. From the programmer's point of view, equally concerned with all possibilities, this choice could go either way. From the software's implementation model point of view, the choice is the same either way. However, from the user's point of view, there is rarely a decision to be made at all. He made his changes already; now he is just putting the document away. If this were happening with a paper journal in the physical world, the user would have pulled it off the shelf, pencilled in some additions, and is now replacing it on the shelf. It's as if the shelf suddenly spoke up, asking if he really wants to keep those changes!
Right now, the seriously computer-holic readers are beginning to squirm in their seats. They are thinking that I'm treading on holy ground, and a pristine copy on disk is a wonderful thing and that I had better not be advocating getting rid of it. Relax! As I said before, there is nothing wrong with our file systems. I am only advocating that we hide its existence from the user. We can still offer to him all of the advantages of that extra copy on disk without exploding his mental model. I'll show you how.
The other big advantage is that software user interface designers won't have to incorporate clumsy file-system awareness into their products. We can structure the commands in our programs according to the goals of the user instead of according to the needs of the operating system.
We no longer need to call the left-most menu the "File" menu. This older nomenclature is a bold reminder of how the technology pokes through the facade of our programs. We can label this menu after the type of document we are processing-for example, we can call it "Spreadsheet," "Invoice," or "Picture." Alternatively, we can give it a more generic name like "Document," which is a reasonable choice for horizontal programs like word processors or spreadsheets.
Changing the name and contents of the "File" menu violates an established standard. I recognize the impact of this proposal and don't make it lightly. I have tremendous respect for standards, unless they are wrong. This one is wrong, and it's existence makes life more difficult than it has to be for every user of computers, particularly newcomers and casual users. The benefits will far outweigh any dislocation the change might cause. There will certainly be an initial cost as experienced users get used to the new presentation, but it will be far less than you might suppose. This is because these power-users have already shown their ability and tolerance by learning the implementation model. For them, learning the better model will be a slam-dunk, and there will be no loss of functionality.
The advantage for new users will be immediate and big. We computer professionals forget how tall the mountain is once we''ve climbed it, but everyday newcomers approach the base of this Everest of knowledge we sit atop and are severely discouraged. Anything we can do to lower the height can make a big difference, and this step removes a considerable obstacle.
DESIGN TERM: Unified File Model
The program will automatically save the document. At the very least, when the user is done with the document and requests the close function, the program will merely go ahead and write the changes out to disk without stopping to ask for confirmation with the "Save Changes" dialog box.
In a perfect world, that would be enough, but computers and software can crash, power can fail, and other unpredictable, catastrophic events can conspire to erase your work. If the power fails before you have pressed close, all of your changes will be lost as the memory containing them scrambles. The original copy on disk will be all right, but hours of work can still be lost. To keep this from happening, the program must also save the document at intervals during the user session. Ideally, the program will save every single little change as soon as the user makes it. In other words, after each keystroke. For most programs on modern computers, this is quite feasible. Only certain programs-word processors leap to mind-would find difficulty with this level of saving (but the solution would still not be impossible). Most documents can be saved to the hard disk in just a fraction of a second, so generally this is not a problem. Still, this is a sensitive area, because the program will hesitate noticeably in a very disturbing way. Word has a facility for automatically saving files to disk, and I never use it for that reason. The problem is caused by the save facility's logic, not because the principle of automatic saving is bad. Word automatically saves the file according to a countdown clock, and you can set the delay to any number of minutes. If you ask for a save every two minutes, for example, after precisely two minutes the program stops accepting your input to write your changes out to disk, regardless of what you are doing at the time. If you are typing when the save begins, it just clamps shut in a very realistic and disconcerting imitation of a broken program. It is a very unpleasant experience. If the algorithm would pay attention to the user instead of the clock, the problem would disappear. Nobody types continuously. Everybody stops to gather his thoughts, or flip a page, or take a sip of coffee. All the program needs to do is wait until the user stops typing for a couple of seconds and then save.
This automatic saving every few minutes and at close time will be adequate for everybody except the really twisted computer-freaks who have been using computers since Bill Gates was just a thousandaire. I include myself in this group. I'm so paranoid about my computer crashing and losing data that I habitually press the ctrl-s key after every paragraph I type, and sometimes after every sentence. (Pressing ctrl-s is the keyboard accelerator for the save function.) I'll typically save a document-like a chapter in this book-more than 1,000* times before it's done! There is no way in the world I would even use a program that didn't provide such manual save capabilities, and all programs should have them. I just don't think that my compulsive behavior should be forced on new or occasional users who are writing the occasional letter or spreadsheet and haven't begun writing a book yet.
Using the revision number feature of Microsoft Word, I print the exact number of saves at the bottom of all of my drafts. I'm not exaggerating.
Right now in Word, the save function is prominently placed in-your-face on the primary program menu. The save dialog is forced on all users when they ask to close the document or to quit or exit the program. These artifacts must go away, but the save functionality can remain in place exactly as it is now.
We computer geeks are conditioned to think that close is the time and place for abandoning unwanted changes if we made some error or were just what-if-ing. This is not correct, though, because the proper time to reject changes is when the changes are made. We even have a well-established idiom to support this. The undo function is the proper facility for eradicating changes. We have bent and contorted our thinking so much to accommodate the implementation model that I often hear people bleat in protest over losing the ability to refuse a request to "save changes."
In Chapter 30, "Undo," I'll talk about some more sophisticated variants of undo that allow us to create multiple versions of a document. Currently, savvy computer users who understand the technology can accomplish this by working cleverly with the file system. A better interface could offer these desirable features directly and explicitly.
When you answer yes to the Save changes dialog, virtually every program then presents you with the "Save As" dialog box. A typical example is shown in Figure 8-2.
Neither the typical user nor the unified file model recognizes the concept of manual saving, so, from their point of view, the name of this dialog box doesn't make much sense. Functionally, this dialog offers the user two things. It lets you name your file, and it lets you choose which directory you wish to place it in. Both of these functions demand intimate knowledge of the file system. The user must know how to formulate a file name and how to navigate through the directory tree. I know of many users who have mastered the name portion but who have completely given up on understanding the directory tree. They put all their documents in whatever directory the program chooses for a default. All of their files associated with a particular program are stored in a single directory. Occasionally, some action will cause the program to forget its default directory, and these users must call in an expert to find their files for them. My next door neighbor, Bill, calls me about every six months to help him find his Lotus 1-2-3 files. The first time he called, I asked him where he normally keeps his spreadsheets. He answered innocently "In 1-2-3." Bill's mental model is very different from the software's implementation model and, ultimately, Bill is right.
The Save As dialog needs to decide what its purpose is. If it exists to name and place files, then it does a very bad job of it. Once the user has named and placed a file, he cannot then change its name or directory. At least he can''t with this dialog that purports to offer naming and placing privileges. Nor with any other tool in the application itself.
Beginners are out of luck, but experienced users learn the hard way that they can close the document, change to the Explorer, rename the file, return to the application, summon the Open File dialog, and reopen the document. In case you were wondering, the Open File dialog doesn''t allow renaming or repositioning either.
Forcing the user to go to the Explorer to rename the document is a minor hardship, but therein lies a hidden trap; its teeth sharp and its spring strong. The bait is the fact that Windows easily supports several applications running simultaneously. Attracted by this feature, the user tries to rename the file in the Explorer without first closing the document in the application. This very reasonable action triggers the trap, and the steel jaws clamp down hard on his leg. He is rebuffed with a rude error message box shown in Figure 8-3. He didn't first close the document-how would he know? Trying to rename an open file is a sharing violation, and the operating system summarily rejects it with a truly frightening and unhelpful error message box.
The innocent user is merely trying to name his document, and he finds himself lost in an archipelago of operating-system arcana. Ironically, the one program that has both the authority and the responsibility to change the document''s name while it is still open is the application itself, yet it refuses to even try.
I suspect that the latter option will only occur to those who are already experienced with the implementation model of file systems. That is, of course, how we would do it today with the Save As dialog: you have already saved the file as Alpha; then you explicitly call up the Save As dialog and change the name. Alpha will be closed and put away on disk, and the new copy will be the version being edited. This action makes very little sense from the single-document viewpoint of the world, and it also offers a really nasty trap for the user.
Here is the completely reasonable scenario that leads to trouble: Let''s say that I have been editing Alpha for the last twenty minutes and now wish to make an archival copy of it on disk so I can make some big, but experimental, changes to the original. I call up the Save As dialog box and change the file name to "New Alpha." The program puts Alpha away on disk leaving me to edit New Alpha. Ahhh, but Alpha was never "Saved," so it gets written to disk without the changes I made in the last twenty minutes! Those changes only exist in the "New Alpha" copy that is currently in memory-in the program. As I begin cutting and pasting in New Alpha-trusting that my handiwork is backed up by "Alpha"-I am actually trashing the sole copy of this information.
Everybody knows that you can use a hammer to drive a screw or a pliers to bash in a nail, but any skilled craftsperson knows that using the wrong tool for the job will eventually catch up with you. The tool will break or the work will be hopelessly ruined. The Save As dialog is the wrong tool for making and managing copies, and it is the user who will eventually have to pick up the pieces caused by the developer's laziness.
If the file system is going to show the user a file that cannot be changed because it is in use by another program, the file system should indicate this to the user. Showing the file name in red, or with a special icon next to it would be sufficient. A new user might still get that awful message in Figure 8-3, but at least some visual clues would be present to show him that there is a reason why that error cropped up.
Not only are there two copies of all data files but, when they are running, there are two copies of all programs. When I go to the Startbar's Start menu and launch my word processor, a button corresponding to Word appears on the Startbar. But if I return to the Start menu, Word is still there! From the user's point of view, I have pulled my hammer out of my toolbox, only to find that my hammer is still in my toolbox!
I'm not saying that this should not be the case. After all, one of the great strengths of the computer is its ability to have multiple copies of software running simultaneously. I do think that the software should help the user to understand this very non-intuitive action, however. Maybe the Start menu could make some reference to the already-running program.
Besides rendering the document as a single entity, there are several goal-directed functions that the user may need, and each one should have its own corresponding function.
It is very tempting to envision the dialog box that accompanies this command, but there should be no such interruption. The program should take its action quietly and efficiently and sensibly, without badgering the user with silly questions. Make a copy. In the user's mind, it is a simple command. If there are any anomalies, the program should make a constructive decision on its own authority.
If the user wants to explicitly place the document somewhere in the file-system hierarchy, he can request this function from the menu. A relative of the Save As dialog appears with the current document highlighted. The user can then move the file to any desired location. Essentially, all files are placed automatically by the program, and this dialog is used only to reposition them.
From the user''s point of view, the physical format of the document-whether it is rich text, ASCII, or Word format, for example-is a characteristic of the document rather than of the disk file, so specifying the format shouldn't be associated with the act of saving the file to disk. It belongs more properly in a "Document Properties" dialog.
Overriding the physical format of a file is a rare occurrence. Saving a file is a very common occurrence. These two functions should not be combined.
The physical format of the document should be specified by way of a small dialog box callable from the main menu. This dialog box should have cautions built into its interface to make it clear to the user that the function can involve significant data loss.
The milestone function (description follows) tells how a file-centric vision of undo can be implemented so that it works well with the unified file model.
The difference between them is that the milestone copy is managed by the application after it is made. The user can call up a "Milestone" dialog box that lists each milestone copy along with various statistics about it, like the time it was recorded and its length. With a click, the user can select a milestone copy and, by doing so, immediately return to it as the active document. The version that was current at the time of the reversion will be milestoned itself, for example, under the name "Displaced by Milestone of Alpha 12/17/97, 13:53."
As I said earlier, we can label the menu after the type of document we are processing. For example, a spreadsheet might label its left-most menu "Sheet." An invoicing program might label it "Invoice." I designed a patent management program for a client, and in that program we called it "Patent."
Alternatively, we can give the left-most menu a more generic label like "Document." This is certainly a reasonable choice for broad programs like word processors and spreadsheets, but is less appropriate for narrower programs like the patent manager. Conversely, those few programs that do represent the contents of disks as files-generally operating system shells and utilities-should have a "File" menu, because they are addressing files with a studied ignorance of their contents.
Reasons number two and three are certainly useful but are not the exclusive domain of disks. Other technologies work as well or better. There are varieties of RAM that don't forget their data when the power is turned off. CMOS memory is solid state, yet it retains its setting without external power.
Networks and phone lines can be used to physically transport data to other sites, often more easily than with removable disks.
Reason number one-cost-is the real reason why disks exist. CMOS is a lot more expensive than disk drives. Reliable, high-bandwidth networks haven't been around as long as removable disks, and they are still more expensive.
Disk drives have many drawbacks when compared to RAM. Disk drives have always been much slower than solid-state memory. They are much less reliable, too, since they depend on moving parts. They consume more power and can take up more space, as well. The real whammy when it comes to disks, though, is that computers, the actual CPU, can''t really read or write to them! Data must first be brought into main, solid-state memory by the CPU's helpers before the CPU can work with it. When the processor is done, the helpers must once again step in to move the data back out to the disk! This means that all processing involving disks is necessarily orders of magnitude slower and more complex than working in plain RAM.
AXIOM: Disks are a Hack, Not a Design Feature
The time and complexity penalty for using disks is so severe that nothing short of enormous cost-differential could compel us to rely on them. Disk drives are a cost-saving hack. Mind you, there is nothing wrong with using this sophisticated technology to save money, but keep in mind that the technology isn't there to provide us with services we couldn't get in other ways. This means that any changes we make to our interfaces to adjust to the disk technology are likely to be inappropriate from a goal-directed point of view.
So we can see that disks are not a law of nature; they are not architectural features that make computers better, more powerful, faster or easier to use. Instead, they make computers weaker, slower and more complex. They are a compromise, a dilution, an adulteration, a corruption of the pure architecture of digital computers. If early computer designers could have economically used RAM instead of disks, they would have done so without hesitation. Whatever other problems RAM exhibited could have been overcome with technologies simpler than the complexity of disk drives.
The difference between RAM and disk is merely a matter of economics, much like the way you go to a lending library instead of personally owning copies of every book. This means that wherever disk technology has left its mark on the design of our software, it has done so purely for implementation purposes and not for any goal-directed design rationale. While this difference should be of interest only to programmers, in reality, it is imposed on nearly every program and users are forced to master it. Any construction that supports disks is for the convenience of the programmer and the computer, and not to help the user.
The pervasiveness of the file system in our thinking and our design of software is as though refrigeration technology dominated the design of every room in our houses. Certainly, the invention of cheap mechanical refrigeration affected our domestic lives, but we don''t turn our houses into shrines to Freon. Yet this is largely what we have done on our desktop computers.
It is one thing to weave a technology invisibly into our lives. It is another thing altogether to allow our lives to be dominated by that technology. Refrigeration plays a big part in our lives in many ways, including food preparation, the production and storage of some medicines and air conditioning, yet we don''t usually find ourselves expressing our desires in terms of it. We don't go into a restaurant and say, "I'll have the salmon. It's been refrigerated, hasn't it?" We don't say, "You'll love working here, it's air conditioned." Omnipresent technologies don''t have to intrude on our conscious thoughts to work well for us. Unfortunately, this realization hasn't yet dawned on the computer industry, and we remain sadly dependent on the file-system model.
Neither of these arguments holds water, though. The first one is irrelevant because new programs written with a unified file model can freely coexist with the older implementation model applications. The underlying file system doesn't change at all. In much the same way that toolbars have invaded the interfaces of most Windows applications in the last few years accompanied only by cheers and encouragement, the unified file model could also be implemented.
The second argument is more insidious, because its proponents are placing the user community in front of them like a shield. What's more, if you ask the users themselves, they will reject the new solution because they abhor change, particularly when that change affects something they have already worked hard to master-like the file system. In the '80s, the Chrysler company showed car-buyers early sketches of a dramatically new automobile design: the minivan. The buyers were asked if they would be interested in this new vehicle, and the public uniformly gave a thumbs-down to the new design. Chrysler went ahead and produced the Caravan anyway, convinced that the design was superior. They were right, and those same people who rejected the design have not only made the Caravan the best-selling minivan, but have made the minivan the most popular new automotive archetype since the convertible.
People will gladly give up painful, poorly designed software for easier, better software even if they don''t understand the explanations. After all, users aren''t software designers and they cannot be expected to visualize the larger effect of the change. Saying that users want to keep their familiar file-system model is like saying you want to break your leg again so you can return to the hospital because the food was so good the last time you were in there.
Posted March 7, 2000
About Face has an 'in your face' style that some readers won't appreciate, but I found it easy reading. While reading it, page after page I just found myself amazed at how easily we get used to a user interface which simply isn't intuitive or actually user-friendly. His ideas are eye-opening, although you probably can't use all of them, because we have to follow certain standards. But at the very least, you will understand why some of those standards are useful and some of them are just plain idiotic. This isn't a step-by-step guide on how to design an interface, and after reading it you will understand why such a guide would be useless anyway. Ablout Face is a serious text for people who actually want to think about what makes user interfaces work, and what to consider when designing one. Despite the seriousness and depth of coverage, the book is refreshingly readable.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.