Ted

Matt on I am a PC campaign: "Of course not. "

Matt on Candace Gingrich: A Letter to My Brother Newt Gingrich: "I love that this is happening..."

Jan-Paul van den Bos on How to Sync Entourage, iPhone, and iCal: "At first it seems if setting..."

Rick Hightower on How to Sync Entourage, iPhone, and iCal: "Thanks. This helped a lot. I..."

Joy on How to Sync Entourage, iPhone, and iCal: "Hi - in iTunes, I don’t..."

Matt on Don’t want to be in there.: "Well, the fact that it passed..."

Josh on Movies.app - Find movie showtimes, reviews, and tickets on your iPhone: "Movies is great, but I think..."

I picked this book up based on my interest in the way that software is designed and the best and not so best ways that software is put together. The subtitle is “Why high-tech products drive us crazy and how to restore the sanity.”

The book is a bit of a diatribe against programmers and software developers, who in the post-green-screen era of computers are not really fit to be interface designers. This is reflected in the design of so many technologies we use, from the alarm-enabled key fobs we have for our cars now (even though no one needs the panic button - it was just added because there was space for another feature), to the veritable VCR.

I really like the analogy given about technology being like a dancing bear - we are amazed that the bear dances at all, even though it doesn’t dance very well at all. I actually experienced this myself when I installed this “panoramic photo software” that came with a digital camera I bought. I was familiar with a similar function that I used to use on Canon cameras that worked really well. This version, in comparison, was really clunky, but I am supposed to be happy because I can make a panorama at all. You get the point.

The solution(s) seem to revolve around getting true interaction designers involved and separating them from the programmers, and having the programmers subscribe to the design philosophy and code around that. Mr. Cooper gives a few nice examples of how he’s done this, and recommends others do it, by creating user “personas” and designing to them. This makes sense to me completely.

He and I depart ways, though, in the level of discomfort he levels at programmers’ role in designing software. The implication here is that programmer-types will never understand what it is to be a user of a system; they will always design for themselves. Therefore, we must hire an army of interaction designers to understand this for them, and they will specify the interface down to the nth degree in huge design documents.

I don’t think this is the answer either, in the era of methodologies such as Agile, which prioritize the customer and a cross-functional approach to software development. I think when we say “you are good at X, you do X and don’t interact with the customer,” I think we set ourselves up for intellectual couch potato-hood.

All of that said, for someone looking to find out how we got where we have around software, I think this is a worthwhile read, for historical significance.

Sorry, the comment form is closed at this time.