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 just spent the last two hours pulling my hair out trying to get Single-Table Inheritance (STI) working with associations in ActiveRecord. After essentially walking through all of the possible ActiveRecord options in this setup, I finally stumbled upon a configuration that seems to work. So this post is an attempt to help the next poor bastard who is Googling in earnest for a solution to a similar problem.

So let’s start with the domain model. I’m too spent at this point in the evening to port this to one of the standard examples. Instead I’ll expose you to the domain of my particular problem. The app I’m working on is one that tracks (non-financial) lending transactions between two individuals. The parties involved, the item in question and when it’s due are all tracked in the Transaction model (and transactions table). A Transaction has a number of states it walks through, using the acts_as_state_machine plugin. These state transitions are triggered by opaque-looking URLs that are sent via email to either party. These are one-time use actions that once consumed are no longer available. When an Action instance is created it also has a before_save callback that generates a unique ID (used in the URL) using Digest::SHA1.

So my plan was to have my Transaction class write one or more Action records for each possible action based on my state transitions. Take a look at the state diagram below:

I want to encapsulate the actual work to be performed within the Action instance the user invokes by following the link in their email. So my plan is to use STI to have different sub-classes of Action that operate on a transaction and march it forward to its next state polymorphically.

Now STI may appear to be total overkill for this problem, but here are my reasons for going this route:

• I want to have these opaque IDs written down somewhere to associate a specific action with a URL
• When the action is complete, I want to remove the record so it can’t be performed again
• The state for a given Transaction can have more than one possible action. I want a separate for each action.

Whew. Okay, clear so far?So my initial code looked something like this:

require “digest/sha1“

class Action < ActiveRecord::Base

  belongs_to :transaction
  before_save :create_guid

  def create_guid
    sha1 = Digest::SHA1.new
    sha1.update transaction_id.to_s
    sha1.update type.downcase
    sha1.update DateTime.to_s
    self.guid = sha1.hexdigest
  end
end

class ReturnAction < Action
  def execute
    transaction.return!
  end
end

class AbortAction < Action
  def execute
    transaction.abort!
  end
end

class DisputeAction < Action
  def execute
    transaction.abort!
  end
end

It seemed like a good idea at the time, but the strange thing was that no matter which incantation I tried, I simply couldn’t create a new Action instance and have it write a record to the database. This simply didn’t work:

ReturnAction.create! :transaction_id => 1

There were no errors on the returned object. No exceptions were thrown. No queries to the database and certainly no insert statements executed. Just complete and utter silence. Out of desperation, as much as anything else, I removed the belongs_to declaration from the Action class and instead declared a has_many on the Transaction class. Voila! It worked like a champ.

After a bit of thought, the has_many association makes complete sense to me in the case where we want to create new Action instances for a particular Transaction. However, if you look in the code above, the execute methods of each sub-class are referring to a transaction object/method—which I no longer have. However I don’t necessarily need the full-blown belongs_to association here. I can just fake the bits I want in the parent Action class like so:

class Action < ActiveRecord::Base
  def transaction
    @transaction ||= Transaction.find(self.transaction_id)
  end
end

So none if this is particularly earth-shattering. Sorry folks, no great gems of philosophical wisdom today. Just one man’s small accomplishment blown completely out of proportion.

You like command-line parsing, but you hate all of the bloat. Why
should you have to create a Hash, then create a parser, fill the Hash
out then throw the parser away (unless you want to print out a usage
message) and deal with a Hash? Why, for Pete’s sake, should the parser
and the parsed values be handled by two different objects?

Changes:

0.0.6 / 2008-07-10

* Fixed a bug with getting the ‘remainder’ when only flags are declared.

*

In addition to technical geekery and social commentary, one of my favorite intellectual pursuits is the study of military history. It’s one of my many interests that makes me so very thankful that I met my wife when I did or I would never have had a date in my adult life.

I am not a pro-war person. Anyone who reads good military history will often find that the best historians are quite anti-war. I had the opportunity to see Rick Atkinson speak in Seattle last winter as he was promoting his book, Day of Battle. He has written several titles about both WWII and Iraq and said that all of his books as anti-war and hopes his readers understand that. No historian has summed that notion up as well as John Keegan in his introduction to The History of Warfare.

To study war is not necessarily to glorify it. To be sure, a good bit of the military history bookshelf is filled with martial hagiography (see Ambrose, Stephen), but to those who study the history with more than a simple fascination of the technologies and armies there is a rich depth of human experience and tragedy to explore.

Like most men (and I’m sure that 99.9% of all military historians are male), I began with that very boyish fascination with all things violent and martial. As I grew older I realized that this was a silly childish interest. I either needed to stop reading about this subject, or I needed to understand it better. I chose the latter in an attempt to cull meaning from so many centuries of meaningless slaughter.

Humans go to war for a variety of reasons–most of them not good. Greed, hatred, and lust for power have fueled more than their fair share of conflict and tragedy. However that doesn’t mean that I think all war is useless. There are some things worth fighting and dying for, but those moments are few and far between in human history. While I cannot condone military action in most of the cases in which it occurs, I believe that it is an inevitable part of the human experience. We were simply bred to beat each others brains out. This is a depressing and tragic conclusion, but I believe that human history is on my side when I make that statement.

So what’s the point of reading military history? If all we are going to do is make the same mistakes over and over again what possible good can from studying the past? Despite my pessimistic outlook on the short-term chances of humanity straightening itself out, I think in long-term we may learn from our mistakes. Military history is nothing if not a study of mistakes. Yes the Hannibals, Napoleons and Pattons of history get the accolades, but there isn’t nearly as much to learn from their successful campaigns. We need to look at the spectacular failures too.

For example, we can learn far more from the fateful decisions of both Napoleon and Hitler to campaign in the Russian winter. While the technical reason for their defeat was weather and logistics, the true cause of their downfall was hubris. It wasn’t that neither failed to comprehend the risks, but rather they felt that their leadership and the elan of their troops transcended reality. Can anyone else think of a recent example where a leader ignored the facts on the ground in pursuit of their own personal policy? Hmm? Anyone?

Another fine example is the book I’m currently reading, Mr. Atkinson’s aforementioned The Day of Battle. The Italian campaign is an oft-forgotten part of World War II. This is due in no small part because there was very little to celebrate in that campaign. No gutsy fortitude like Guadalcanal or Stalingrad, no tragedy like Poland or Saipan, just lots of dumb decisions that required a tremendous amount of cannon-fodder to achieve victory.

Few campaigns offer such a textbook example of group-think gone horribly wrong as the Allies in Italy during World War II. From Churchill and Roosevelt, to Eisenhower, to the theater commanders, everyone in the chain of command was eager to cast what they saw with their own eyes in terms of what they desired, not what the actual realities on the ground were. While we may not be in a war in our day-to-day work, each of us can certainly come up with examples where group-think led everyone to bad conclusions.

The other valuable outcome of studying military history to come to a better understanding of just what the cost of war truly is. Obviously anyone who has not experienced combat cannot imagine the horrors of that experience. I thank my lucky stars that I never had to go to war. But I feel that it’s disingenuous to rail against the horrors of war without making an attempt to understand them.

I attended the University of Oregon and there are few places on earth that have a stronger innate anti-war bias. I have no problem with the pursuit of peace, but to do so in ignorance serves no one. It’s vital that we all understand what the consequences of going to war are. I fear that the cavalier attitude with which the United States has prosecuted the Iraq War and insulated the public from the horrifying facts on the ground only serves to keep us ignorant of the true costs of war. This is not a game of cops and robbers–people are dying daily for questionable causes, to say nothing of the long-term political consequences. But I digress…

One final reward of the study of military history is to recognize how leadership within a corporate, in the purest sense of the word,  setting can work. I don’t mean the famous generals such as Grant, Lee or Washington. Rather, a kind of leadership that few successfully execute consciously. Instead it is the Joshua Chamberlains of the world that provide insightful, meaningful case studies of what true leadership is. Most of us don’t work in groups of one thousand or more, but instead in “squads” of ten or less people. Learning how Captains and Sergeants command, push and prod their troops and maintain esprit de corps is worth the time of anyone who is interested in exercising any form of leadership.

It’s rare that at the end of a good military history read I don’t feel the need to weep. Maybe I’m a sucker for heartache but I can’t help but feel just a teeny bit smarter after turning the last page of a well-written piece of military history. So before parting, let me leave you with a short list of great military reads (in no particular order) that I’ve come across over the years:

1. The Peloponnesian War – Thucydides
2. The Civil War (Trilogy) – Shelby Foote
3. At Dawn We Slept – Gordon Prange
4. Just about anything by John Keegan
5. The Best and the Brightest – David Halberstam
6. We Were Soldiers Once…And Young – Harold G. Moore
7. The Rise and Fall of the Great Powers – Paul Kennedy
8. Diplomacy – Henry Kissinger

This week I stumbled upon Stephen Celis’ awesome bit of shell-fu, gemdoc, which allows you to quickly get to the HTML docs for installed gems via command-line. Unfortunately I abandoned bash years ago for zsh and Stephen’s shell bits needed a little porting. For me, zsh, is a bit like swiss-army knife where about 95% of it is a mystery to me, but the 5% I use I couldn’t live without. So simply switching back to bash is a no-go.

My setup is little-bit complicated, but I believe the following, stripped-down, recipe should work:

GEMDIR=$(gem env gemdir)
OPEN=$(whence xdg-open || whence open)

gemdoc() {
  ${OPEN} $GEMDIR/doc/`$(which ls) $GEMDIR/doc | grep $1 | sort | tail -1`/rdoc/index.html
}

_gemdocomplete() {
  reply=( `$(which ls) $GEMDIR/doc` )
}

compctl -K _gemdocomplete gemdoc

Update 6/25/08-10:30: Updated to work for both Penguins and Macs.

I’ve spilled a lot of (virtual) ink in this blog, but almost none of it about what I do all day. That’s because I’ve been working at a startup in “stealth mode” for darn near two years and haven’t been able to really say much about it. Until today.

Today at Evri we’re launching the beta version of our site. If you head to the home page and signup, you’ll get yourself a free set of brand-new shiny credentials that will give you the keys to data-surfing heaven.

The company blog post does a good job of highlighting what we have available, but for the truly lazy I’ll give you the quick highlights.

First, is the home page which gives you a look at entities and their relations as we understand them currently. We start out with lists ranking the top people, places and things. In addition to popularity, you can also see who is rising and falling in popularity over time. All of these lists are clickable and enable our super-whizzy widget which provides a nice way of pivoting between entities, all the while getting related content.

This is one of my favorite parts of the product, as it’s really easy to just get lost wandering around from link to link to see how things are related. It’s like a big six-degrees-of-Kevin-Bacon game, except that you can do with just about anything. Part of that link-hopping experience is visiting specific pages about each entity.

Here you can find more detailed content about an entity. Currently these details comes from Wikipedia, but we anticipate adding several other specific sources of structured content. And of course, these pages link you to other pages, so between the hub-and-spoke visualization and the detail pages you can spend quite a bit of time just data-grazing.

So take it for a spin and have some fun exploring! Give us your feedback (a link is at the top of each page) and let us know what you like and don’t like. Most importantly, stay tuned. This is just the beginning for us, we have some pretty exciting stuff in the works and you won’t want to miss out.

Things have been a bit nutty the last few days–as they are for any release–but it will be worth it for the satisfaction of finally lighting this candle.

Enjoy!

While on vacation last week, my wife and some friends of ours solved the age-old problem of melting the chocolate and the marshmallow in a s’more. You stuff a chunk of chocolate (we prefer good old-fashioned Hershey’s waxy American milk chocolate) inside the mallow and then toast the entire unit.

Do you see where this is going? No? How ’bout this?

Amen sisters and brothers. Now that’s a properly-melted s’more.

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 I see a forecast like this, I gotta think that life just isn’t fair sometimes…