Donald Norman's Design of Everyday Things provided some of the most illustrative examples I have seen in a long time. The only downside is that the rest of the book was comparably fluff and certainly lighter. Part of the struggle I had with this book is that he shifts so frequently from his concepts to dwell on a multi-page example—having only finished a fragment of a page with the new concept. It didn't help that many of his references were vastly outdated, in particular the desire for a portable, handheld computer that could manage his calendar. That's what perplexed me the most with this book. I got the exact same experience (a sort of a blast from the past) reading the allegedly more current edition as I did with the 1989 edition. Honestly, if he really felt that such a dated book needed an update, he simply could have written a new one. As past students of CHI would note, it's not as though he is adverse to writing. I figured that if he left the book as it stood in 1989 and then wrote a sequel of sorts to it, similar to Levy's addendum to Hackers, we could still gain the perspective that 1980s Norman wanted to impart while building on new ideas that Norman realized. That said, considering Norman's dramatic reversal of his stance in his book on emotional design, a simple afterword would not suffice; the entire book would need to be rewritten (and not just by substituting LaserDiscs for DVDs).
I was astonished at how much Norman was willing to repeat himself. In the end, it boiled down to the fact that his main idea on behavioral design has only so many facets. That is, it is easy to see a design that fails (for proof, see just about every page in the book), but it is much harder to discover one that works and still somehow meets everyone's criteria. As a point of amusement, Norman claimed that an outline-based word processor generally increased repeated chunks of text. He may not have used such software, but it certainly appeared as much from his frequent loose rephrasings of previous chapters. Worse still, some of his definitions for terms repeated endlessly throughout the book (notably without a glossary) were only vaguely defined. For a man obsessed with usability, his book didn't seem to be as much.
His general attitude throughout the book was wholly patronizing, which I did not enjoy. Every time he claimed a non-functional design probably earned an award, I more and more saw Norman as a hipster of sorts, decrying the efforts of “try-hards.” He tends to ignore the fact that plenty of innovative, functional designs also have a certain elegance to them. That the designer wanted more than just a boring object is hardly a reason to shun it. Nonetheless, his disillusionment hangs heavily over the book, suggesting that awards as a whole are a sham. Certainly, some award-winning designs are completely unusable and some snubbed ones are simple to understand conceptually, but these categories are anything but mutually exclusive, which is something that the author insists must be the case. On the other hand, I cannot help but wonder if the world of the fairly recent past did indeed have Norman's claimed level of disjointedness. I would like to think that in the numerous years since this book was first published, the categories for awards also consider usability.
What really struck me the most was the insistence that programmers should not be user interface designers. As a diehard Linux user, being forced to use a system that does not function in the way that I understand it to makes no sense. Of course Linux distros have interface designers, but the key difference to me is that they tend to think like programmers. Terminal windows? Geared towards programmers. The GIMP? Makes no sense if you aren't a programmer. OpenOffice? Horrible if you only know Microsoft Office, wonderful otherwise (especially if you are a programmer). Maybe it takes a different way of thinking, reinforced through many, many late nights of coding, but I am willing to bet that a UI design who only has experience with the computer illiterate would struggle immensely to build a UI for a group of programmers. Sometimes it really does take a man on the inside, so to speak, to get the optimal result.
No comments:
Post a Comment