It takes a brave author to give a book this title and keep it at 150 pages. The number of jokes about the proportionality of the “good parts” to the size of the book are endless. Be that as it may, when I saw this book at the Powell’s stand at RailsConf ‘08, I figured anything written by Crockford on the subject of JavaScript was probably worth taking a look at.

Given the diminutive nature of the the book, I suspect the author was attempting to do for JavaScript what Kernighan and Richie did for C with their book. I found an abused first edition copy of that C book and it taught me more about C than any other book. It is a triumph of restrained, focused technical writing (for other examples check out any of Kent Beck’s books). At times I felt that some chapters in “The Good Parts” were superfluous, but I imagine that they were included for completeness if nothing else. For example, the second-longest chapter in the book is about the grammar of the language. While important, it seems disproportionately large to rest of the contents.

If you have any exposure to JavaScript a good part of this book will be a review for you. However, there are three chapters worth reading for any JavaScript programmer. Chapter 3, Objects, discusses the properties of objects in JavaScript and covers everything from enumeration, to prototypes to attributes. Do you know why property enumeration is usually worthless as a debug tool? That’s because of the prototype mechanism. If you use typeof filters and the hasOwnProperty method, you can significantly cut down the properties you dump on an object. I never knew that before.

Chapter 4, Functions, is the real money-maker of the book. This is the chapter that I put the most post-its in and will certainly be one I’ll have to revisit. Here Crockford goes into the different ways functions can be invoked and what the consequences are of each invocation style. There is a lot of good functional programming material here. He also discusses how Functions are intimately tied to Objects. Take heed, thar be dragons!

Chapter 5, Inheritance, closes the loop on Functions and Objects. It explains the important differences between JavaScripts prototype-based inheritance model and the class-based model used in many other popular object-oriented languages. Like the previous chapter, this will be one that I’m sure I’ll have to re-read in the future.

It’s taken a long time, but JavaScript seems to finally be growing up a bit. Given how truly awful it was to use it in the Early Days on more than one browser, it’s a bit surprising that it has come to dominate the web landscape. Now it seems to be finally getting (begrudging) respect from the rest of the software community. Unfortunately to be effective, you really need to learn some of the deep voodoo that, to me, is a bit counterintuitive. Is the prototype approach really all that innovative? I’m not sure. Arguing that it’s better than inheritance is like saying that something is better than poking yourself in the eyes with a sharp stick—faint praise indeed. But I do love passing around functions as objects with complete abandon. When I finally grokked this part of JavaScript, things really clicked for me.

Is this book a must-read? No, probably not. If you’re doing any serious JavaScript in the browser you’re probably using one of the popular JavaScript frameworks out there that hide some of the yucky details of Function/Object interaction. But, lacking a decent language spec (and the ECMA spec sucks rocks), it’s not a bad resource. It certainly won’t take up much space in your bookshelf.

2.5 stars out of 5.

Alan Cooper’s About Face is one of those pillars of UI/UX design, the reading of which is a rite of passage. I figured few books would be more appropriate as a capstone to my long list of design-oriented reads. It is nearly an institution in and of itself. Last night I turned the final page and ticked a pretty big 560-page book off of my reading list.

There was enough material in this book that I adopted a new habit of using small post-its to mark important passages. This was helpful not only in referring back to earlier material in the book, but also in cementing some of the concepts in my head. This practice was so useful I’ve started doing it with other books too.

You may have noticed that the post-its don’t really kick in until about 2/5 of the way through the book (Chapter 10 to be specific). I’ll be honest and admit that the first nine chapters felt like a rehash to me. That’s not to say they are without value, but they are a bit long-winded and, at times, excruciating in detail.

So let me go ahead and get my beefs with the book out of the way. If you guessed that a book on its third edition that is nearly three inches thick would have some opinions you would be right. I don’t have a problem with opinions—that’s why I bought the book. But I did find the tone a bit much. Haughty, imperious, self-righteous and overbearing might be good descriptions too. There is a definite Moses-coming-down-from-the-mountain-with-fresh-tablets feel to this book. Mr. Cooper and his cohorts are here to set you straight. Don’t let it turn you off. Think of these guys as that cranky-but-humorous guy you work with. He’s a riot as long as you don’t take what he says too seriously.

Secondly this is a long book. I’m not convinced it really needed to be this long. There’s an awful lot of repetition spread throughout the chapters. All of that is nit-picking really. This was an incredibly informative book. Again, the number of stickies you see should give you some idea of the value that I got from it. There is a lot a person can learn here.

A big part of Cooper’s philosophy is the focus on Goal-Oriented Design. The first part of the book spends a significant amount of ink describing the concepts of personas, goals and user research. As a developer I couldn’t help but feel that a lot of this was Big Design Up Front. “Just let the arch-priests of interaction design get it all working and then hand it off to the developers”, they say. Hmmm, my experience tells me otherwise. To be fair, the authors attempt to address in the afterword of the book. But still…

Once goal-oriented design is out of the way, the book picks up significantly by covering such concepts as the “excise” (tax) that systems place on humans, how people get into “flow” and how bad software can remove them from it or prevent it. One of my favorite little gems is a discussion of possible vs. probable. While it’s possible that a user may want to choose one option over another, in cases where one option is disproportionately chosen over the other (the probable) use a default with an override. Think of how many times you’ve had to answer the same question over and over. It’s pretty irritating, no?

Another great section is the discussion of metaphor. Of the book’s numerous examples, the ones demonstrating bad metaphor really shine. General Magic’s Magic Cap interface is an absolute nightmare of conflicting messages and unnecessary navigation. What do these icons mean? If I rub the lamp do I get three wishes? If I push the rubber stamp am I getting notarized or checking out a book? Just what the hell is going on here?

Cooper describes Magic Cap’s failure as an over-reliance on global metaphor, where the system is essentially trapped in its slavish adherence to its metaphor. The rubber-stamp is there because real desks have rubber-stamps. But the need to be consistent with the desk metaphor weakens the interaction.

Cooper proposes idiomatic design as the alternative to metaphors. User interfaces have been around long enough that a large number of interactions have already been figured out. Users are already familiar with them and, generally, don’t require additional ramp-up to recognize them. Obviously there are a lot of bad idioms out there too so, like anything in life, take that advice with some degree of moderation.

If there’s one over-arching theme to the book it’s that there are basically three groups of users you have to consider: beginners, intermediates and advanced users. The first and last groups are usually the smallest with the bulk of your user population consisting of perpetual intermediates. Beginners generally graduate quickly to intermediates. From there it’s a much larger jump to advanced users. However, a lot of interfaces are often geared towards beginners. I would suspect (with little evidence to back this up) that a lot of this has to do with too much focus on customer-acquisition.

Without a means for potential intermediate users to shed their training wheels, users can get quickly frustrated. However you can’t build a power-user-only application either. Very few users run the gauntlet from beginner all the way to the advanced user. So the trick to is spend the correct amount of effort on features that match the proportions on your users.

With this idea in mind the final eleven chapters of the book provide a fantastic, detailed look at how the principles described above apply to common visual idioms. For example, in the chapter devoted to menuing systems, the authors describe not as the sole interface, but a “pedagogic vector” for beginners. When combined with shortcut keys and accelerators, menus provide a way for beginners to graduate to intermediates and beyond.

Another important theme in the last section is just how far software really needs to come to meet users. The authors review example after example of “computer-first” design where the user seems be treated as a necessary irritant. One of my favorite passages in the entire book is on the topic of wizards: “Programmers like wizards because they get to treat users as peripheral devices.”

Another chapter is devoted just to disk storage and how most of our idioms around disk storage should really be the computer’s problem, not the users. At first this kind of talk seems like the crazy guy in Hyde Park, but after some reflection I think he’s right. There is an awful lot of software that couldn’t care less about the user. We can do better than this. We should do better than this.

One technical detail of the book that I just love is how they integrate images with captions. A particular pet peeve of mine is when images and captions seemed to be dropped into the text in willy-nilly fashion with little regard to the reader’s flow. When figures that are referred to in the text aren’t placed close to the text, I have to context switch and try not to lose my place. I either have to remember to look at the figure soon, or I have to switch to the figure immediately and then find my place back in the text. It drives me nuts. Whoever did the layout for About Face 3 obviously thought about the usability of the text. God bless you, whoever you may be.

While I’m pretty sure that I wouldn’t want to have to talk to any of these guys at cocktail party (I doubt I’d get a word in edge-wise), they put together an incredibly informative book. I’m pretty sure I’ll need those sticky notes in the future to revisit a number of concepts presented here.

5 out 5 stars.

I’ve been on a usability/design kick for about the last six months. Somehow I stumbled across a link to Robert Hoekman Jr’s site which was described as great design books for programmers. I fully recognize the fact that I really don’t have that little spark that good designers have, but I’d like to be better at it than I am. So I’ve been eager to find usability and design books that work for visually-clumsy folks like me. Robert Hoekman’s pair of books, Designing the Obvious and Designing the Moment were wonderful additions to my growing design-for-code-dorks library.

The covers of both books were what initially piqued my interest. Both have very simple white covers. Unlike a lot of design books, this one isn’t about showing off a bunch of pyrotechnics on the cover (see Jenifer Tidwell’s Designing Interfaces which includes a colored version of O’Reilly’s usual animal lithograph). I figured anyone willing to put such a sparse cover on the page was pretty confident about the content inside. I also really liked the fact that the form-factor of both books is smaller than the usual trade paperback and comes in at a very economic 200 pages, or about 1/4″ thick.

Alright, I’ll admit that I was taken in by the author’s use of my favorite font, Gill Sans. I just love this font (it’s the font this blog is set to if you don’t override CSS) because it’s clean and elegant with a minimum–or complete absence–of decorative fuss. Unlike the Pragmatic Programmers or O’Reilly the publisher, New Riders, doesn’t seem enforce a particular font style for their books. Therefore I think it’s safe to assume that the author made a conscious decision to use this font which, at a microscopic level, supports many of the notions of simplicity and cleanliness presented in the books.

Designing The Obvious

His first book, Designing the Obvious focuses on translating from what a user needs to creating workable screen-flows. While I’ve knocked out several smaller design books, I’ve been slowly making my way through Alan Cooper’s seminal About Face in which the concept of goal-oriented design is introduced. Hoekman’s book is the second text I’ve come across that offers a contrasting opinion on goal-oriented design the author calls task-oriented design. Whereas Cooper’s approach is to begin design by understanding a user’s goal within the larger context of their lives or career aspiration, task-oriented design is focused on more immediate desires.

A goal-oriented design might start with something like “Anna is a small-business owner who wants to balance career and family. She needs particular help with payroll for her small three-person company.” A task-oriented design might start with “A user with a small-company must be able to setup employees with a minimum of fuss: perhaps just name, address and social security number”. Hoekman even titles one of his chapters “Understand Users, Then Ignore Them”.

Each chapter is tightly-focused on a single concept and few supporting ones. For example, the chapter titled “Turn Beginners Into Intermediates, Immediately” spends a thrifty thirty-five pages outlining the basic distribution of user expertise (hint: the big fat blob in the middle are the intermediate users) and then enumerating several concrete examples of how to serve the intermediates, how to get the beginners to immediates as quickly as possible, and how to keep the advanced users still engaged.

The ability of Hoekman to outline a concept and back it up with several concrete examples is the real strength of the book. This is not a patterns or recipe book. Similarly it’s not a grand philosophical tome (see Cooper, above). Instead it’s a very practical work intent on getting the ideas across, but leaving plenty of room for the reader to explore on their own.

The fact that he gets such a rich amount of information is such a small package is a testament to the author’s well-thought, lean design approach.

5 out of 5 stars

Designing The Moment

Hoekman’s second title focuses specifically on web application design. Unlike his previous book which is more philosophical and abstract, Designing The Moment is much more concrete. With thirty-one chapters spread out over 220 pages, each chapter is tightly-focused. Those chapters are split up into seven major sections.

The first section is titled Getting Oriented and focuses on getting the user oriented with your site. He delves into how users’ eyes flow over a page, navigation, links and dealing with common web paradigms like tag clouds.

The second section, Learning, provides specifics about getting users “over the novice hump”. This theme was an important one in his first book and here he offers several ways to teach your users about your site.

The third section, Searching, walks you through the pitfalls of search interface design. A common theme in both books is that of a poke-yoka, which means to fool-proof in Japanese. The term was originally derived from Toyota’s Production System which was developed in the ’80’s (note: Toyota is currently kicking serious rear-end in the car biz). Here he uses the term poke-yoka device to mean any mechanism that will help prevent the user from hurting themselves. This is not about treating users as idiots but rather hiding ugly implementation details away from the users if at all possible. For example, you if need users to enter a phone number in a particular format, design a form that makes so that users enter phone numbers in that format. Don’t just give them a text field and then complain when they don’t get it right.

Moving on we get to fourth section, titled Diving In, where we really start to get into the nitty-gritty details of things like media player controls, form layout, wizards, and validation. This is the longest section of the book and meatiest. Again, Hoekman nails the concepts with well-chosen representative examples and solutions.

The fifth section, Participating focuses on the mechanics of features commonly associated with “social-networking” web applications. This chapter ranges from concrete implementation recommendations like how to build user profiles, to more abstract, strategic concepts like how to embrace user feedback and how to channel your most vocal users.

The sixth section, Managing Information, provides some tips on helping users digest your site’s contents. Tips here include how to effectively use syndication, dealing with tags and folksonomies, where drag-and-drop is appropriate and dealing with system notifications.

The final section, Moving On, embraces I concept I first saw articulated in 37Signals’ Getting Real . Don’t build your apps as walled gardens where you make every attempt to keep your users from leaving. This ain’t Vegas you aren’t a casino. Yes, you want to give users another chance to reconsider and you certainly want to know why they’re leaving, but don’t be a jerk about it. This section offers some guidelines for parting ways with your users. I think to design something without this in mind is to the fact that not everyone is going to dig what you’ve built. Let them go easily and don’t make things worse by making parting a painful experience.

I loved this book as much as Hoekman’s first title. Both are handy references I’ll keep nearby.

5 out 5 stars.

Stephen Few’s Information Dashboard Design is the latest in a series of books I’ve been reading about visual design and the display of quantitative information. It’s a surprisingly heavy book for being relatively skinny (~200 pp), but is printed on gorgeous high-quality paper. This O’Reilly book feels much more like a coffee-table book than the usual animal-cover books for which they are famous.

Dashboards are one of those phrases that the synergy-loving, tassle-loafer, khaki-loving business-types really like. I was worried at first that this book would be targeted more toward the executive officer crowd and less about helping designers. The first two chapters didn’t ease my concerns with lots of discussion around designing for executive goals and summaries. However once we got past the introductory chapters, the book really picks up…

Chapter 3: Common Mistakes

This chapter highlights a litany of common dashboard design mistakes. These aren’t just limited to visual tips, but also includes important concepts like providing context through comparison and scaling displayed data appropriately. The examples given here are fairly egregious examples of bad dashboard design, but acclimate the reader to critical review.

Chapter 4: Tapping Into The Power of Visual Perception

This is where the fun begins as you learn some of the science behind visual perception. Few describes how shape, position, color, hue and encapsulating marks all affect how we process and perceive data visually. This is one of three chapters that a designer will return to again and again for review.

Chapter 5: Eloquence Through Simplicity

Here we head to a particularly Tufte-ian territory with the consistent refrains of “maximizing data ink” and “removing non-data marks”. While the words make sense, the concepts are driven home with some great examples. My favorite part of this chapter was the rectangle depicting which screen regions get the most attention and why. After you see it, it’s obvious and yet you’ll easily be able to recall many examples you’ve seen that violate these principles.

Chapter 6: Effective Dashboard Display Media

The party continues with a detailed survey of the most common graphical visual idioms. The common chart styles like line plots, bar graphs and scatter plots are explored as well as the more exotic ones such as radar graphs, stem-plots and even strategic icon placement. This chapter serves as a great foundation for the final chapters where you will use your newly-acquired visual vocabulary to perform a detailed critique of a number of sample dashboards. Oh and if you take nothing else from this book, remember this: pie-charts are useless.

Chapter 7: Designing for Usability

This is the shortest chapter of the book, but the two great takeaways from this chapter are encouraging useful comparisons and avoiding senseless ones. If unrelated data-sets are placed too closely or use the same visual representation, it may encourage meaning comparison. Conversely using different styles for data that should be compared simply makes the user’s job harder.

Few dives into a few tips around making an esthetically pleasing dashboard without resorting to decorative gew-gaws that clutter the display. In particular things such as using a muted color palette, designing for high resolution and picking the right fonts (a particular sticking point for me) are all ways to be informative without distracting the user.

Chapter 8: Putting It All Together

This is easily the best part of the book. However I wouldn’t suggest skipping the other chapters in a effort to get to the payoff. I think the reader would best be served by reading this book in sequential order because the principles and concepts covered in the earlier chapters help to give the reader a visual vocabulary for what comes in this chapter.

The begins by showing a dashboard the author designed designed for a competition designing dashboards for a mock business. The dashboard is concise, dense without being cluttered and draws focus to important items quickly. In contrast the author shows eight other dashboards that contestants submitted for the same mock business. Each one has a number of defects, some easy to find and others less so. It’s definitely worth studying these dashboards with a careful eye prior to reading the author’s criticism.

The chapter ends with three more dashboards targeted to other audiences: the CIO, tele-sales and marketing. Each shows off the other motifs highlighted in earlier chapters. However they all have a consistent style–one that is clear, concise, dense but uncluttered. The prospective designer would be well-advised to spend some quality time studying these examples to distill them into principles for their own designs. This chapter really caps the book off well.

Finally…

Information Dashboard Design is a well-written book full of useful information. The high-level principles are well-described and the catalog of details motifs make this book worth having.

4 out of 5 stars.

Peter Morville & Louis Rosenfeld

504 pages
2006 O’Reilly Press

I’ve recently become fascinated with some of the “softer” edges of my profession such as user interaction, visual design and information architecture. These are difficult topics to write about because their abstract nature makes it hard to provide useful, tangible information while not treating the subject as a simple set of boiled-down “how-tos”. A couple of weeks ago I picked up this book as a way to delve into more formalized information structure and theory. By and large this book did a good job of rounding-out those areas of knowledge for me.

This book is in its third edition and I couldn’t help feeling at times like the authors were trying to justify that. While the table of contents lists six “parts”, I really felt the book was broken up into three major sections: the first is essentially a multi-chapter treatise on what IA is and why it’s important. The second section is some of the nuts-and-bolts theory, and the third section is about implementing IA with a couple of case studies. Of the three sections, the middle one was the most useful to me and, in my opinion, carried the others.

I understand why the authors would feel compelled to write the first section—the intended audience is no doubt large and would certainly contain a number of skeptics. However I found the voice of these chapters to be a little too earnest and tried to hard to justify the profession. At times I wondered if the authors really had confidence in what they were talking about because they spent so much time justifying their statements. I was a bit surprised at the defensive posture of the opening chapters and can’t help but wonder if other readers won’t start wondering what kind of uphill battle am I in for?

Part two is where I felt like I learned the most—this is the real selling value of the book. Most of the information in this part of the book wasn’t new to me, but this section clearly articulated concepts I had previously only understood in abstract, internal terms. Concepts such as the inverse relation between relevance and recall, labeling, taxonomies, different relation types and thesauri were helpful to learn about in concrete terms. If nothing else, I feel like I’ve become more conversant in these topics.

Part three, by comparison, felt like a bit of a letdown. It was dedicated mostly to strategy and tactics around implementing IA within an organization. I won’t argue that the information covered isn’t worthwhile, but it didn’t seem particularly exclusive to information architecture and therefore, in my opinion, was given far too much ink relative to the content-packed middle section. I also felt like the two case studies given at the end of the book lacked the clarity and energy of the middle section of the book. These did not feel like a particularly satisfying, put-it-all-together summary of the concepts covered.

In all, the core information specific to IA was very enlightening and I can imagine that I’ll be thumbing through those chapters again. Also, I’m not sure I’ve read a professional trade paperback with quite so many cross-references (hint: that’s a good thing). Kudos to the authors for giving the reader lots of pointers to related materials. I just wish I could buy a version that only contained the 120 or so pages that I found most useful.

3 out of 5 stars.

Esther Derby and Diana Larsen

A new book from the Prags rolled into the office this week called “Agile Retrospectives”. I glanced at the title, saw the word “Agile”, looked at the size of the book (about 1/4”) and decided it was worth a read. I’ll admit that when I started the book I thought the title was “Agile Perspectives”, but quickly realized that the book was much more focused than just a loosely-related set of essays on Agile software methodology.

This book is focused entirely on one subject: the techniques of retrospective meetings as an Agile practice. This is something I’ve done at other places, but usually not in a very structured fashion. Once I realized what the book was about I was ready to pick up a few tricks to sharpen the focus of future retrospectives.

At times I felt a natural urge to recoil from the touchy-feely corporate speak that pervades the book. I’m just not a corporate rah-rah kind of guy and the thought of having posters up to remind us all to have S.M.A.R.T. goals (Specific, Measurable, Attainable, Realistic and Timely) makes we want to run out the

room screaming. But I’ll cut the authors some slack—they are self-described “facilitators” and anyone who puts themselves in that role is going to be living and breathing that vernacular.

At times this book reinforced the chronic, pseudo-scientific navel-gazing that strikes me as a particularly American corporate obsession. But taken as a whole, the book is worth a read if you are part of a team that is consciously striving to improve all the time. Some of the exercises struck me as a little childish, but overall there were some good tips.

For example, many of the techniques focused on quick, simple ways to measure team attitudes about the state of the team. While the actual measurement may not particularly scientific, they can serve as a rough guides for the team mood and dynamics. One important thing to note here is that sometimes anonymous measurement is really important to get honest evaluations from team members.

Is it worth a read? I think if you’re looking for some concrete techniques to improve retrospectives this books is worth a look.

3 out of 5 stars.

Steve Krug

This book served as an amuse-bouche for my foray in to the softer side of application development: usability, design and information architecture. I have to give big kudos to the author for keeping the book focused and short. He has a pretty succint thesis to get across and doesn’t pad the book unnecessarily to add weight. It’s worth considering that the publisher probably printed the book on really high-quality paper to make the retail price fall in line with other professional titles. Hmmm…

There is nothing terribly earth-shattering about the contents–the cover pretty much covers it. However, I did enjoy the sections covering user-testing, especially the part about doing it on the cheap. I think the mystery of usability has created a market for boutique firms that provide these services at a premium. Once people get hip to DIY usability-testing, I would forsee a “market correction” in the future.

3 out 5 stars.

Leonard Richardson & Sam Ruby

I picked this book up from the Powell’s booth while at RailsConf 2007. I had been following the online manuscript for a while and as soon as I saw that the book was in print I snapped it right up. I wasn’t the only one either. REST was a very hot topic at RailsConf and I saw a lot of other attendees with a copy under their arm.

I’ve been keenly interested in REST for about the last year and a half. I’ve read

Fielding’s dissertation a couple of times and read some good blogs, but really felt like REST was missing a more accessible, canonical resource. After completing this book, I think I’ve finally found one.

The author’s do an excellent job of distilling the principles of REST and describe an imlementation of it they term Resource-Oriented Architecture (ROA) which has specific recommendations. I’m pretty sure that my copy will be referred to time and again and that I will probably eventually re-read its contents. I only wish the authors had done more to address using REST in human-facing web applications, not just web services.

4 out 5 stars.