This book is written by an "interface expert" from Apple. The title should be more specific, since the book restricts itself to interfacing with able-bodied sighted users of desktop machines (not aircraft etc). Most of it is represented in this quote:

"...that we should provide users with as many choices for configuring the system as possible... is complete rubbish. I wish I could find the people who came up with that ludicrous idea and throttle the life out of them."

This man wants war! Maybe I should do something nasty with my white cane, or make him use a Mac with a sight impairment simulator. Is his "20/80 rule" his excuse for why we can't do so much as change all the fonts and colours, let alone anything else? Avoiding featuritis is one thing; making a discriminatory barrier is another. The very people who would benefit most from technology are being excluded from it precisely because they are minorities not worth considering, or relegated to using messy third-party adaptations that are incomplete and often expensive.

Making an interface fully configurable does not deter novice users as Bickford claims it does. He says himself (on page 243) that you can have sensible defaults that can be tweaked, but only after lots of commandments to the contrary. X Windows (which is never mentioned in the book) is about the most configurable GUI there is, but many use it happily without knowing this. Some applications still make mistakes like respecting the user's black background but insisting on black text, but it's streets ahead of GUIs that make you spend ages squinting before you can begin (if indeed you're allowed to change anything at all) and can rarely restore someone's previous configuration afterwards.

Bickford advocates hard-coding fonts and colours, and despite the mention of using 'standard' schemes, no mention is made of reading them from the system. It also advocates hard-coding keyboard shortcuts (or the lack of them), metaphors that can get silly, and abolishing technical error messages (non-technical messages can be uninformative or misleading, and error numbers work wonders when you're helping someone with a foreign-language version of a program; I'm all for readable messages but don't take the information out). It advises leaving extra space in dialogues for translation but fails to suggest dynamic layout (like HTML forms). The chapter on web design never mentions ALT tags, but advocates Java. And the book is full of "instead of this, do that" commands that assume you can only have one possibility.

There are some good points. The book is readable with some interesting anecdotes, and the author does consider tunnel vision (although only in the context of the restricted attention of fully sighted people). And he does say "use moderation", that "good interface" does not mean "looks pretty" and that "you are not the user". But in almost the same breath he invites you to "dream" without considering the differences of others.

Bickford says

"if it's not all right, it's all wrong" , which is precisely how I feel about his book.

As this was a fairly aggressive review, Silas emailed it to the author for comment. The following is Peter Bickford's reply and Silas' reply. If you are wondering why I have allowed so much space it is because I consider the issues raised to be important. - Francis Glassborow

Peter Bickford Replies:

Hi Silas, Thanks for the preview, and I'm sorry you didn't like the book. In fairness to myself, I think you're miss-characterising most of what I have to say. True, the book doesn't have much to say on the subject of disability access; that being said, I think you might have interpreted much of my railing against complexity as some sort of campaign against allowing for disabled access. This is certainly not my point. Extraordinary situations (vision impairment, etc) require novel solutions. Proposing what those are, unfortunately, was beyond the scope of this book, which was meant as more of a general interface guide.

A few years back, my editor suggested I do an article on designing for people with disabilities, and how this often plays into good interface design in general. Initially, I was quite interested in taking up this line, but as I thought further about the issue, it seemed that the point was far from clear. XWindows' extreme configurability, for instance, gives it distinct advantages for certain types of disability access. It's also a very good example of an overcomplicated interface whose configurability often spells unnecessary complexity for the casual user. Although I don't think I ever stood for such things as "hard coding fonts" as you say, I do believe that uncomplicating an interface is often a matter of providing a few, clear options for doing things than a million preferences, config options, and init settings.

Although we can come at the issue from different perspectives, I think we can both agree that a good interface is one that is designed with its users' needs in mind. A Unix expert has different skills and needs than a secretary, and a visually impaired person is likely to have different priorities for software design than someone without those disabilities. (Your own arguments for flexibility even at the cost of precise layout control [in your HTML example] or simplicity [in your command keys example] is a classic example of this. Neither of us is wrong here - we're just serving the needs of different users.

Point-of-view differences aside, I think you misstate what I wrote when you accuse me of advocating hard-coding of fonts, keyboard shortcuts, etc., as well as my position on error messages.

I do state that you should use the system standard fonts (which are, of course, read from current system settings). My point on the 'hard coding' of keyboard shortcuts is that developers need to respect the established standards for the command keys; what a user does later in customising them is their own business.

As far as error messages, the point is that using error numbers in error dialogs is convenient crutch for the developer, but does little good for the user. The proper path is to put a useful message in the user's own language in preference to any sort of codes. If the user speaks conventional English, the message should be in conventional English; if the user speaks Farsi, the message should follow suit. Very few users, other than programmers, get more information out of "File System Error -39" than they would out of "You've run out of disk space on drive X." Fundamentally, the book is about controlling the explosion of complexity in mainstream software. It sounds like you were looking for a discussion of interface from a different angle. I think it makes sense to say that this wasn't the book you were looking for, but treating its contents as if they were about disability access is leading you, I'm guessing, to think I'm arguing things I'm not.

Best wishes,
-Pete

Silas Replies:

Hi Pete,
Thanks for your message. Please be assured I'm not deliberately miss- characterising you or anything, but if I misunderstood what you said, then others might too. I understand that you were not deliberately setting out against disabled people in particular; nevertheless the publication of a book like this will make the world a lot harder for us. I wanted to take the opportunity to point that out clearly (I wouldn't really do anything nasty with my white cane, but you wouldn't really throttle anyone, would you?).

Unfortunately if you say you're writing for mainstream interfaces and don't make them configurable, this could result in many inaccessible applications and OSs. In a network or corporate environment, allowing one user to have a different set of software (or type of computer) is very often not an option, so unless the mainstream software is accessible, problems can occur. And yet a book on generalinterface design doesn't need to go into the gory details of accessibility, as long as the flexibility is there. To illustrate: If you built a house for yourself, you can make the stairs however wide or narrow you want. But if many other people were going to use it, or you made a design for a house that is to be built millions of times all over the world, you'd have to make sure those stairs are wide enough for a stairlift, or a lift can be installed, or something, because sooner or later someone (probably quite a few) is going to come along in a wheelchair. You don't have to actually design that stairlift, and a book about designing houses does not have to go into the details of stairlifts. It just needs to make sure you leave the flexibility there so the user can configure it should the need arise.

I don't understand what makes you think X Windows' complexity would be too much for casual users. The complexity is hidden unless you want to know about it. I know loads of people who use X Windows every day without even knowing what a window manager is. To reconfigure the system they have to edit various files in their home directory, so they're hardly likely to be clicking around some dialogue boxes one day and panic at finding the stuff.

About hard-coding the fonts, you had examples like "Have you got 12-point headings in some places and 11-point in others?" and that sounds like hard coding to me. There's a subtle difference between "use the colours from the system properties" and "use grey like everyone else does" (or whatever it was you said - sorry I haven't got the book with me at the moment). By the time you get to the keyboard shortcuts, any notion that the user can actually customise these things (e.g. because of a motor problem) seems to be against what you keep saying about complexity.

I agree that putting an error message in the user's own language is a good idea. The problem comes when that user needs more help, and the only person s/he can ask doesn't speak that language. This has happened many a time here in Cambridge, where there are students from over 70 countries using just about every localised OS on earth. Often the user's attempted translation of the message does not shed light on the problem (e.g. "Disk is not controlled"), and the *addition* of a number that can be looked up on the Web would be ideal. The world is getting increasingly international and I wouldn't be surprised if this situation started arising in many companies etc in the near future.

Fundamentally, the book is about controlling the explosion of complexity in mainstream software. Perhaps you can think of a better title than "interface design" for the next edition? Aircraft, ATMs, household appliances etc all have interfaces, but your book is (mostly) about GUIs. (Not to mention "interface" in the sense of RS-232 et al....) And it's not just about GUIs, it's specifically what you just said (well, complexity in the interface rather than complexity in the software).

Silas