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.

When talking about building software, few sentences set off more red flags than those beginning with “it would be nice if..”. I don’t mean some variation of this phrase, I mean exactly this phrase. It’s like those words are a specific code-phrase for “speculative features coming your way!”

What the heck is “nice” anyway? The very language of that statement does nothing more than imply; it makes no assertions and offers no proof. A piece of candy is nice. So are flowers and a new house. But those things all require widely varying levels of planning, effort and cost. So “nice” isn’t a very precise word and certainly fails us when we try to evaluate what goes into our product and what stays on the sidelines for further evaluation.

In a geek-heavy setting, such as my workplace, I often observe this phrase used as a desire to establish authority in a conversation. This happens when features are proposed not so much for their value, but as a way of showing how deep and nuanced the proposer’s understanding of the domain is. For example in a brainstorming session we had recently about new visualizations for rich data structures, a lot of IWBNI ideas were proposed that were fairly baroque and hard to imagine being interesting to a wider audience. In this instance instead of focusing on the goal, making sense of a big pile of information, the exercise turned into a demonstration of various participants’ grasp of market dynamics, web trends and cutting-edge features. You can imagine how useful the final set of ideas were.

Another issue with IWBNI features is that they are often very implementation-focused. For example if you are working on a web service that is consumed by other services, you might want to track usage statistics to generate a regular report to see who is using it. The real feature is tracking usage, but that original need can easily be obscured by an overly-specific implementation. Ideas for these features often emerge out of the system constraints that are a result of the system design, not necessarily a natural outcome of the problem domain. Differentiating between these two is probably one of the hardest things to do in any kind of design.

It’s vital to differentiate between these because IWBNI features seem especially prone to calcifying the current implementation. Back to our web services example, let’s say we implement this usage report, which dumps a text file every hour of usage statistics. We love that feature so much that we hook it up to our automated monitoring system as it seems like a nice way to monitor the “heartbeat” of the system. However, down the road we discover that we need a maintenance window that makes the file unavailable for a period of time that causes the monitoring system to alert us. Now we have a choice: we can patch up the monitoring to manage this exception, or we can re-think just how important the text-file interface is.

In this case I would argue that the text-file dump might instead be replaced with a simple web-request. When the system is in its maintenance mode, it could still answer questions about general availability (which is what we were originally interested in) without tying a more specific feature, usage, to monitoring. I don’t think that making the monitoring script more sophisticated is the right answer. More complexity there means a higher likelihood of breaking and it spreads some very implementation-specific details to other parts of the system.

The features and attributes of a system can be viewed like walls in a house. Some are load-bearing and some are not. The load-bearing features are those that without which, the house would simply fall. In your applications these are features that are the very essence of the software. An application like Quicken has an awful lot of walls. The load-bearing features of Quicken are the ledgers and reconciliation process. Without these, the other features of Quicken are irrelevant.

However features like downloading transactions over the internet or viewing pie-charts are mostly decorative. This doesn’t mean they are without worth, but they are not as essential as the load-bearing features. These could be removed and Quicken’s essence would still be preserved. Quicken is certainly more useful with these features, but those aren’t the features that generally drive users to use it. (NB: This is not to say Quicken is a well-designed application. But I’ll save that for another post…)

You can move the decorative walls around to change the space of a room without major fuss. Moving a load-bearing wall is a fairly major operation and has a huge impact on the character of the house and requires extra planning so that the house doesn’t collapse during the change. The danger of IWBNI is that it’s easy to confuse these features with essential “load-bearing” ones. Worse yet, the compound of multiple IWBNI features can end up as a load-bearing walls that are difficult to move. Revisiting our web services example, if more features like the text file were piled on and external parties began to rely on these, it would become much more difficult to move these in the future. It’s not difficult to imagine getting to a point where the original role of the web service is obscured by all of the other tangential bells and whistles.

Sometimes IWBNI features are user- or domain-driven. These seem like they might have a better chance of withstanding the litmus test. More often than not these ideas end up obscuring the core of the application, but these can be, relatively, easy to test with tools like mockups, user interviews and usability testing. In supporting services it’s much harder to evaluate these features. How do we do usability testing for a web service? Does the variable for a request belong in the path or as a query parameter? How do we figure out what consumers want? This is tricky because in this case we’re designing something by geeks, for geeks. This doesn’t mean that it’s okay to pile on a bunch of implementation details and stop thinking about separating our load-bearing features from our decorative ones. But it does mean that we have to be extra vigilant about the IWBNI features and view them with a particularly suspicious eye.

So I think this is the real trick–whether you are a visual designer, information architect or software developer–is to separate the essential from the decorative. Being able to sort features in this way gives you a chance to properly evaluate the cost/benefit tradeoffs. Without this I believe it is much more difficult to clearly see the value of a feature and its overall impact on the system.

So let me offer up a challenge: treat IWBNI as a codeword for something requiring exceptional scrutiny. When something is proposed as a IWBNI feature, regard it with a suspicious eye. When you feel yourself proposing a IWBNI feature, think long and hard about whether or not it is really “nice” or whether it might “essential” or “superfluous”. And for goodness’ sake, don’t get hung up on your IWBNI features. If they’re “nice” they probably aren’t a core feature anyway. You’re a smart, creative person and you’ll have other ideas in the future.

And finally, let’s remember the most common trait that nearly all IWBNI features share…

YAGNI*

* Ya ain’t gonna need it

How many times have you excitedly tried to show your parents some project you’re working on and gotten a confused or indifferent response? My reaction has often been to dismiss this disconnect as the result of a generation-gap, but a recent experience has led me to rethink that.

At work, we’re getting very close to start unleashing our product on the world and so I was doing a little demo for my mom. At first this started to feel like other times when I’ve showed her things I’ve worked and she’ll focus on some seemingly insignificant detail or re-imagines the application in terms that seem very specific to her world. I felt my usual generation-gap defenses warming up and I started to wrap up the demo. No point in going any further, right?

But after a few more moments I was able to demonstrate enough compelling features that she was engaged. More importantly I became engaged in her reaction to the system. The barrier between us where each side couldn’t really grok the other seemed to fall. I was able to have a better understanding of how she might look at it, instead of how I’ve been looking at for the past year and a half.

So perhaps it’s trite and obvious to state that one can benefit from giving yourself the time and patience to understand your users. But I think it’s especially true when dealing with other generations. If you can come up with something that crosses those barriers like my impromptu demo did, by George you’re probably onto something.

I’m a fussy guy when it comes to fonts. I like them a certain way because I have strong opinions about which fonts look good and because I spend a lot of time throughout the day looking at them. I like being an avid reader, a software developer and a guy with 20/20 vision. As a result I spend more time than most fiddling with the fonts on my machine to get them just so.

At work I have a MacBook Pro hooked up to a large Dell flat-screen LCD monitor. The screen real estate is fantastic, but it has a weird effect on my terminal program. Here’s a snapshot of what the Monaco font looks like when I start iTerm (or Terminal.app) while attached to the Dell:

Here’s a screenshot of what iTerm looks like when I launch it without the Dell attached:

See how much thicker the letters are in the second shot? I much prefer the latter setup because it’s easier on my eyes. Also I find the variation in the thickness of the lines (probably a result of anti-aliasing with the Dell) in the first screenshot distracting. But that’s just my font-related OCD kicking in. It bugs me enough that if I have to start iTerm again, I’ll unplug the Dell, wait for my Mac to figure out I have one screen, relaunch iTerm and then plug the monitor back in. Yup, it matters that much to me.

It seems stereotypical that dudes who write Ruby on Macs love big fonts. Meeting other Ruby dudes with Macs was certainly my first exposure to terminals set to 18-point type. Before then I felt like 14 was pushing it. But then I realized that there really isn’t that much I can look at at once. I used to be one of those guys that would get four terminals going simultaneously in 10-point type. Just look at me, I’d think to myself, I am soooooo productive. Now I’m on the other side of the fence. I’m a big-font guy.

In part this is because I know that I can get distracted too easily. Having a bunch of stuff open at once only opens me up to more opportunities for something to steal my attention. These days I really don’t need to exacerbate my ADD so cutting down on what I have to look at is generally a good thing. I’ve actually returned to using virtual desktops just to partition my running applications. Oh yeah, I turn off all those notifications too. It was fun for awhile, but now it’s just irritating.

I like to keep the fonts pretty big. I don’t like reading from a screen nearly as much as I like reading from paper. I can feel a sort of mental fatigue set in after reading too much online. One way I’ve found to combat that fatigue is to simply increase the font-size. Honestly I can’t read five paragraphs at once…I can read only read one so I really don’t need to cram a bunch in a single space.

I think I’m not alone in my preference for big bold, stripped-down fonts. I’ve seen an increasing number of web applications that go with a real stark, big-font look. One of my favorites is GitHub:

I think it’s pretty clear what you’re supposed to do here. Very little extraneous BS, just direct to the point. Give them a login and a password, they’ll give you GitHub. It couldn’t possibly be any simpler. Oftentimes you see the login box relegated to a corner of the screen with the remaining 80-90% devoted to some kind of market-ese with stock photos of trim, athletic, happy people who are ostensibly using the same product. What a total waste of space.

Size isn’t my only bone to pick with fonts. I’m also quite particular about which faces I like. In general I’m not a big fan of serif fonts. I find the clutter of the extra lines distracting, so I generally stick to sans-serif fonts as much as possible. Among sans-serif fonts I have two favorites: Monaco for fixed-width and Gill Sans for variable width.

Fixed-width fonts are popular in programming because the code just lays out better to our eyes. It could be that with things like blocks and indentation, programmesr have a natural tendency to scan code horizontally and vertically in rows and columns. Vertical scanning would be much more problematic with a variable-width font.

However for general reading, I like Gill Sans as a variable-width font. I like it so much that whenever I setup a new desktop, I go fiddle with the font settings in Firefox to get ‘em the way I like ‘em. I even go so far as to trump a site’s stylesheets just to keep my font. Sometimes this results in pretty weird looking pages, but more often than not it turns out okay.

However, I realize that not everyone likes the same font I do. Because I do some web development I need to be able to view sites the same way as the poor unwashed masses view them. For that I take advantage of Firefox’s profiles which allow me to have my font-fascist settings for general browsing and factory default font-settings for testing.

So there it is. I like big fonts and I’m not ashamed to admit it. Sure it might look like I’m reading the code-equivalent of the large-print section from the library. But hey, I still have great vision and you small-font people aren’t processing any more at once than I am.

UIs are, essentially, collections of widgets. These widgets act as visual and manipulative proxies between the user and the underlying conceptual model. If we think of the ultimate UI as being one which minimizes the mental distance between what the user wants to do and what they have to do to accomplish it, perhaps the ideal interface would be like the fictional jet-fighter, Firefox. What could possibly be more direct than thinking, fire that missile, and seeing that missile burst forth from under the wing? Unfortunately, since most of us work on slightly less fantastic technologies than those portrayed in the movie, we have to figure how to work best within our milieu. This is the real challenge of what we do. How can we take the crude medium of computer software and diminish the distance between thinking and doing?

Yesterday I checked out a site that plays in the same space as a project I’m working on. These sorts of things are bit like going to the dentist, you don’t necessarily look forward to it, but you do it because it’s good for you. It’s not that I’m trying to ignore what is out there, but for a side-project there is a certain bliss in being ignorant of what else is out there–especially when there really isn’t any money at stake. But I was a good boy and checked it out. I went in fearing the worst–that these guys would have nailed the concept and the interface, and there was simply no reason to put any more time on our version. After about fifteen minutes I was pretty convinced that we could come up with a more compelling user experience.

Like mom always said, if you don’t have anything nice to say, say it anyway–just don’t name names. So let me try to provide some detail on what I found without tipping my hand. This app had all the right rounded-corner-drop-shadow-muted-blue patina that any self-respecting Web 2.0 app should. But digging a bit under the surface revealed a pretty face on what was essentially a Windows for Workgroups-era application mentality. The user flow felt like it was driven from the underlying relational data model, not necessarily from sensible use cases. As I filled out wizard form after wizard form, I couldn’t help imagining each one mapping to a particular table in a database. In addition, each form had several tabs with a mix of required and optional features to be identified by the user. The tabs were clearly meant to further sub-categorize the input, however because of the limited real-estate in a tab, only single-word descriptions were available. I had to click on each tab to see if I needed fill anything out in there or not. Too much clicking to satisfy the data model, not enough payoff for the user to keep it up.

Then I ran into something called “templates”. I can’t help but wonder if templating concepts aren’t a smell rather than a feature. In the case of this application, it wasn’t really clear what the benefits of templates would be. Normally templates are there to avoid repeating work and providing a model of re-use. Looking at this “feature”, I couldn’t help but wonder why I should care. If templates are so damn important, do I really want to use an app in which templates are a necessity? Again, too much work, no clear payoff. Humans serve the machine. Bah!

So why would somebody put something like templates in? The answer is re-use. Software developers simply love re-use wherever they can get it. I can imagine the developers and product team sitting around reviewing this complicated system they’ve built and finally having to address the fact that the complexity makes it hard to use. Templates to the rescue! We can reduce the user’s work-load with reuse! Ugh. It’s only an economic win if I really care to continue the app. Otherwise the real problem lies in the original interaction model.

The Golden Age of Perfect Software is nowhere on the horizon so building software will continue to be a type of gruesome sausage-making for the foreseeable future. One of the great lies about software development is the false economics of reuse. The theory goes like this: if applications can be built by assembling more-powerful, higher-level components together, the overall cost of software development should decrease. At face value this theory makes a lot of sense. I’m sure many of us can think of time we have wasted (or seen wasted) on building rounder wheels. Why should anyone spend time working on a library of sorting algorithms when for 99.999% of all cases the sorting routines available with your platform are adequate?

The problem is that the component-based thinking doesn’t always match the needs of the application. Sure we may have built it more cheaply than if we had written it from scratch, but we have to ask ourselves how much did we compromise in that effort? Software is a notoriously tricky business and the number of failures greatly outweigh the number of successes. Google wasn’t built in one shot. Heck, the first version of Google Reader was so badly panned, they threw it away and wrote another one. Apple is on the tenth major version of the OS software and fifth major revision within the latest family. Let’s not kid ourselves, we’re much more likely to get it wrong than get it right. So let’s just assume that it’s possible that none of the available, reusable components is going to suffice for your needs. That doesn’t have to be your starting assumption, but we have to keep the possibility in the back of our minds.

This leads to a second point I’d like to make about re-use. Many UI toolkits come with a pretty rich array of widgets that are used to build nearly every application out there. This is true of native clients as it is of web applications. If our goal is to minimize the conceptual distance between the user’s mental model of the application (remember, the developer’s mental model is almost irrelevant) and what they need to do to meet that model, then restricting ourselves only to what the widget palette offers will be fraught with compromise. Developers may see applications built as collections of widgets, but users often don’t. It’s quite possible that using the “standard” widgets for your application greatly increases the mental distance between thinking and doing for the user. When this happens the user is serving the application–not the other way around. Uh oh. Wrong turn. Back up. Try again.

Don’t misunderstand me. I’m not saying that every application has to be written from the ground up because there is no hope in getting the interaction right by reusing off-the-shelf components. That’s ridiculous. We’d never get anything done if we approached our apps like that. Rather, my point is that we can’t necessarily limit ourselves to the widget sets and conventions of our platforms. In doing so we may leave the user out in the cold. However, visual or interactive exceptionalism for the sake of differentiation invites similar risk. Dressing up your app to stand out is akin to putting lipstick on a pig. If you app is compelling, dressing it up will be unnecessary.

Let’s return to our anonymous whipping boy…er, sample web site. Not only did the wizards and multiple-layers of object hierarchy force me to learn the tool’s model (one I don’t care about), but the expression of those wizards (the widgets) similarly required me (the user) to play along, rather than getting me to the payoff. Some applications are very sophisticated and will require more of the user, but that’s not the case for this one. Indeed the selling point is how easy it is to use and how user-focused it really was! Boo, hiss. F-.

So while the wizards had a very consistent and recognizable look and feel to them, they did a horrible job of getting me to where I wanted to be. I can’t help but feel that this application was built with a primary focus on a relational data model and component reuse. This ended up with fat proxies between me and what I wanted to get done–an increase in the mental distance between thinking and doing. This is the real shame. Increasing that distance is the primal sin of application design.

One final note: a lot of the inspiration for this post came from a fantastic post by Cathy Shive on, what she terms, “Administrative Debris”. I interpreted “debris” as that which increases this conceptual distance I keep harping on. Her post, unlike mine, provides a lot more visual examples to get the point across. I would highly recommend reading her article to get another angle on these ideas.

On Super Tuesday, I forwent attending the usual Seattle Ruby Brigade meeting and stayed at home glued to the radio and TV keeping up on the primary and caucus results across the nation. I love the Public Radio/TV talking heads, but I was really lacking the overall picture. So I warmed up the Internet tubes and started searching for some helpful at-a-glance snapshot of the state of Super Tuesday.

Here then, is an amateur’s critique of the various infographics I tripped across. What I was looking for was something that would tell me:

• Margin of victory for each candidate
• Percentage of precincts reporting
• The number of delegates available
• The number of delegates each candidate won
• Clear indication of races that have finished, and those that have not.
• I want as much information as I can get in a small space
• I don’t want to navigate through data

The New York Times

So let’s start with New York Times. This tabular graphic came from the New York Times front page:

This one came the closest to the goals I was looking for. The Times doesn’t waste any space on images of either the candidates or the states themselves (something a lot of other graphics couldn’t avoid). I get just about everything I’m looking for on my list, except for the delegates.

From the front page, I followed the “Full Coverage” link to this pictorial table which shows the breakdown by state. The conversion of images to black and white for candidates that have dropped out is a nice visual touch. I don’t mind this too much because the table would still be quite readable without them. This table is essentially the same information as the previous one, except that it shows all of the states and has the additional bonus of indicating states whose primaries haven’t happened yet.

And then, of course, we have the ubiquitous geographic map. This view was predominant one across most of these sites. Many sites touted these things as “interactive” which amazes me that it could be considered a possible selling point. I’ll take “informative” over “interactive” any day of the week thank you.

The Washington Post

This little tidbit was at the bottom of each party’s news column on the Washington Post Politics page. I’m not so hot on the geographic map, but the fact that it was placed at the bottom of a text column instead dominating the page (as many of the maps do) earns this a few points.

Next, we turn to the Post’s “Super Map”, which is a glut of hyperactive mouse-oriented popups. It looks promising, but the popup comments came up too easily and weren’t easily dismissed. While this map gives us some notion of the delegates each state has, I can’t tell which candidate got what portion of delegates. Also states that have declared winners don’t show any margin of victory details. This map takes up the entire screen and doesn’t really earn the space it takes up.

At the bottom of the map was a little trend-line chart for the Democrats. Care to guess when Edwards dropped out of the race?

National Public Radio

This is the table from the front page of National Public Radio’s page. This table gives me most of the things I’m looking for with no space wasted on unnecessary graphics. While we get delegate information, the lack of percentages is unfortunate. This is the only tabular display I found that ordered the per-state results in the chronological order in which the polls will close.

This table was a nice compact little sidebar on NPR’s Super Tuesday coverage page. This is probably the best delegate information I found out of any of the sites surveyed here.

CNN

I have to come clean and admit that I simply can’t stand CNN. It’s always on and has so little useful content. The election coverage I’ve seen to-date has some of the glitziest, lowest-density graphics in their live broadcasts of any I’ve seen. The touch displays are merely a cover up for the fact that the content is empty and newscasters cannot improv. However, I have to give CNN credit with this tabular display. Not fantastic, but at least no wasted space on graphics.

However, this table falls short on a number of counts. The biggest problem is the need to paginate through results. Requiring mouse-overs to get popups on a map is one thing, but clicking through a list of data to find what you’re looking for is simply inexcusable. This is a particularly obnoxious example of failing to making the data dense enough.

From the “Full Coverage” link:

I find the stylized map insulting. The northern border of the United States is not a flat. The state borders don’t line up neatly in rows. Not only does this map have the same faults of the others (low data density, too much interaction required), it’s also simply wrong.

USA Today

The USA Today made it’s name in glitzy, over-wrought graphics and typing the URL in the browser bar I fully expected some useless 3D pie-charts and other such non-sense. I was pleasantly surprised to find this box on the front page:

This is a surprisingly informative view. The densely-packed links dispense with state navigation via map. I don’t mind navigation here so much because I can quickly get to any state. I don’t have paginate through results and I don’t have to float over states whose shapes I can’t remember to find them. Instead, clicking on a well-known state abbreviation link in the navigation bar gives you a nice detailed breakdown:

The inclusion of the advertisement in the outlined space of the first graphic works to draw your attention, but is really a turn-off. It’s only because I was giving each site one click that I continued navigating through the site. Normally, I would have left the site for that reason. To be fair, I understand the these sites have to support themselves with advertising. But putting an ad in the middle of a graphic depicting who we pick as our president in one of the most critical times of our history really cheapens the subject being covered.

MSNBC

Sigh…

By now you’ve probably figured out that I think the inclusion of visual geographic information is superfluous. The state images take a third of each state’s space for information. Other than the letter and color, which indicate the candidate and party, this space doesn’t help me. I can tell that the box is about California because it is titled “California” at the top. The inclusion of state images seems like a weak attempt to “spice up” the presentation of the data.

This graphic gives us the usual percentages, including the percentage of precincts reporting, and the total delegates which is helpful. However, since each state apportions delegates differently, we can’t really tell how important a margin of victory is in a particular state. I can’t really harp on MSNBC for this, nobody included that level of detail in the graphic summaries.

Information Design

There is a growing trend of geeks getting hip to the principles of usability and user experience design. The idea is that when developers start taking a more user-centric approach to their development, their design of their applications will be influenced more by the user’s needs and less by the internal mechanisms or frameworks upon which it is built. As a kind of agile, post-modern, less-is-more kinda guy I think this is a wonderful approach.

However I think this user-centric approach can be taken far beyond point-and-click interfaces. I’ve noticed that when developing a so-called “back-end” feature, an awful lot of developers tend to work inside-out. The approach often starts with how something will be done and, based on that process/function/algorithm, the rest of the design accretes until enough connective tissue is in place to connect the feature to the rest of the application. One danger in this thinking is that the implementation can drive the design in such a way that precludes other implementations. But an even more insidious problem is that the inside-out approach can leave the end-user with a pretty lousy interface. I’ll borrow Joel Spolsky’s Iceberg Analogy here and say that your clever little algorithm is far below the water-line. Please…I beg of you…please spend some time on your interface.

The inside-out approach often manifests itself as a lack of refinement on the visible edges of a feature. For software with an obvious visual interface this is relatively cut and dried. However for other features this is less clear, but just as important. Let’s take the simple example of a command-line utility that does some internal housekeeping. An inside-out approach typically yields a core bit of code that has just enough command-line option parsing to connect a terminal to the core bit. But having a few command-line switches for configurability isn’t enough. Here are few things to consider to make that visible 10% of your feature rock:

• Implement a standard “help” option like --help and provide terse but descriptive prose. The output should be able to answer “what does this thing do?”
• Useful documentation of command-line parameters. What is this parameter for? Is it required? Is their a default value?
• Provide sensible defaults. If the typical use-case is run against developers own machines, even if it’s run differently in production, for Pete’s-sake make localhost the default. Don’t make the thing you do the most often, the most painful.
• Provide a “pretend” or “dry-run” mode. Show what would happen without committing the user to the final consequences.
• Handle termination gracefully. Don’t just let your app barf all over itself when someone kills it with CTRL+C
• Provide useful output for long-running jobs. Consider the interplay between this suggestion and the previous one.

Even though your “customers” are perhaps internal team-members, that’s no reason to short-change them with some lousy tool that only works under the narrowest of circumstances. This is just plain rude to the rest of your team. Do you pee in their coffee cups in the morning? No? Then don’t stick them with bad tools. So then let me enumerate a few things that will guarantee you a fast-track onto my rake-whacking-list:

• Failures without explanation or entrails left behind to debug.
• Cryptic messages (success or failure).
• Not playing nicely with standard input and output streams so that your utility can work nicely in a shell.
• Printing a bunch of debug output that I can’t turn off.
• Lack of sensible defaults. Please don’t make me type the same option over..and over…and over…

Since this horse ain’t quite dead yet, let me flog it just a wee bit more. If you’re with me this far, then perhaps you’ve bought off on the idea that the 10% of your non-visual apps deserves first-class treatment. Hold on…I’ve got one more for you. In addition to spending the time to polish the user-visible features you also need to test them. I don’t mean the regular WOMB (works on my box) manual testing. I mean automated, unit-tested features. Yes…even for things like command-line parsing. If you want to call yourself a craftsperson, don’t slack on this. Do it right. If you think unit-testing takes too long then you need to get better at it, not ignore it altogether. In my book you can’t possibly be so brilliant that you can design beautiful algorithms or object models but can’t test-drive something as simple as configuration parameters. Sorry…you just can’t.

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.