The book does exactly what it claims to: it explains user interface design to programmers who have little familiarity with the subject. The book is probably old hat to someone who has done a reasonable amount of reading on UI design, but it is still interesting. If I were to recommend a book for quick tips for UI design, there is a good chance I would recommend this one. It has the same basic advice as other books I have read without the theory or flights of fancy (::cough:: Raskin ::cough::). I love theory and flights of fancy, but sometimes getting to the point is convenient, and this book does just that.

Joel Spolsky is an exceptional programmer: one who can communicate. User Interface Design for Programmers is clear, accessible, and engaging. It makes the case for user-centered design and offers good rules of thumb to achieve such designs. It does this in terms that will be readily accessible to most programmers.

However, it falls down for me in terms of depth. Other books such as The Humane Interface, The Design of Everyday Things, and The Inmates are Running the Asylum cover Joel's points regarding the limits of human capacity, designing for all types of users, persona, and so on with greater depth and rigour. For the professional software developer, these books should be considered essential reading.

The book is also a little too anecdotal for my taste. Although the anecdotes are illuminating and convey sound principles, it does make the book feel like part of a conversation down at the pub.

Nonetheless, User Interface Design for Programmers has the big advantage over weightier works in that it might actually be read by "run of the mill coders" because it is short and focused solely on their concerns. For this reason, I think this volume would be of particular value to team leaders, architects, and similarly "leaders" who want to give their programmers an introduction to this topic. ( )

"A woman came in to test the software. When she wasn't able to complete the assigned task, she actually broke down in tears"

That's pretty bad!

This book was an easy, fun read. ( )

I should start by saying that I liked most of Joel's other articles for hist insightful comments and opinions. Most of his essays are very focused and contain little filler content or "dictionary" type explanation of trade jargons.

I liked this book for similar reasons. Some points may seem obvious after you read it, but simplicity is where the beauty lies. Joel supports his arguments with his personal experience which are to the point. The logics in the book flows well and reads like a mathematical proof. Important points are called out clearly.

Although I liked the book, I don't agree with all of his arguments and opinions. For instance, his comments on web UI seems out of date. We are in the web 2.0 era and many obstacles can be overcome with newer technology. So many of his concerns and solutions are irrelevant.

Joel begins by establishing the central pillar of UI design: "A UI is well designed when the program behaves exactly how the user thought it would." and "all other rules of UI design are corollaries."

Some other points:
- Program model should fit the user model.
- User will assume the simplest model possible.
- Do not abdicate your responsibility by forcing the user to make unnecessary decisions.
- Many signs (e.g. No bicycle on bus) are historical records. They do not serve a real purpose now.
- Use affordance to guide user (e.g. no handle on door to indicate PUSH)
- Use metaphor, but make sure real world metaphor obeys laws of physics in the real world.
- Design for extremes, so they are useful in border cases, AND easier to user under normal situations.
- Assume users dont read anything. (e.g. don't rely on explanatory text)
- Assume users can't use the mouse well. (e.g. implement auto-snap)
- Assume users can't remember anything. (e.g. implement auto-complete)
- Usability tests test *learnability*, NOT usability.
- Testing a few users is enough, and keep in mind that the tests can't reflect real world usage 100%.
- Days are seconds: days of coding a feature that users will only experience a few seconds. So what makes perfect sense to you may not make any sense to the user.
- Months are minutes: months of feature creep may only add unnecessary complication to the user.
- Seconds are hours: unnecessary or poorly designed UI that cause delays seem like hours to the user.
- Be careful with heuristics. 5 good guesses can easily be offset by 1 wrong guess. Incorrect heuristics annoy the user much more. ( )

I really wanted to like this book a great deal but I'm afaid it didn't quite live up to my expectations. Expectations, I might add, which were based on having been a long time fan of the author (via his blog/web site).

It's hard to put my finger on what put a dent in my reading experience but if I had to try I think it would be that a number of things the author says sound a lot like personal opinion (e.g. using Courier over Ariel, even given that the one is more "readable" than the other), which is understandable given the subject matter. The other thing is the absence of acknowledging that although there may be a better way to do something it's not necessarily going to be the one that gets used (i.e. the author's "designing for extremes" argument, there's a reason not everything is made to mil-spec ratings and we don't all use Dvorak keyboards). For example the multi line tab control - I disagree that moving the tabs to the bottom of the control would have made it easier for a user to use as it would have ended up being another form of the Outlook Bar which the author also bashes (a point I happen to agree with him on). Another passage in the book which made me smile was where the author encourages the reader to think about internationalisation and even brings up the case of the Australian spelling "dialler" which in America would be spelt "dialer" and then not two pages on uses, what I assume is an American cultural reference of: "Murphy Bed" which is something I (a non American) have never heard of (but guess as, given the context, being those beds you see in movies which flip up into the wall).

The one thing that dates this book quite badly is the chapter on designing for the web (which is ironic given that it contains a section titled "Historical Note"). Web speeds have increased dramatically since this book was written which knock one of the legs out of his argument for designing simpler pages so as to provide quick responses. Most online email sites now support the saving of draft emails and rich text like editing and the technology around drop down menus has improved in leaps and bounds and true modal dialog boxes are now possible. Internet users have also become more web-wise and have no problem using image based buttons now (I guess this all points to the "usable" vs "learnable" argument the book makes).

This book certainly offers up a lot of useful information but it's not a definitive list of what to do and what not to do (and I don't think there could be one). It's more of a guide on how to think about UI design and, in my opinion, sometimes some of the stuff applies and sometimes it doesn't.

Having said all this, this book is definitely worth reading as it does explain a lot with regards to GUI design and providing you can get past the author's geek humour (and asides) will definitely help you as a programmer. ( )