Dr. Dobb's Journal November 1998
No engineers were harmed in the production of Web Site Usability: A Designer's Guide by Jared Spool et al; according to the book's front page anyway. Having read the book twice in as many weeks, I want to ask the authors, "Yeah, but what about their egos?" This slim book, privately published by User Interface Engineering, is an empirical study of what makes web sites more or less usable. The authors tested nine sites, ranging from Disney and the '96 Olympics to Travelocity and Edmund's car and truck price guides, in a variety of simple ways. One test, for example, was to see how easy it was for people to figure out whether it was cheaper to fly to Nevada or England. Another was to find out whether you could buy a Honda Accord for under $15,000.
The results were startling. Disney and C|net, with their graphical menus and high-priced layout, fared worst; Edmund's, which pretty much sticks to point-form lists, did best. As they examined their findings more closely, the authors came to some surprising conclusions:
All of this is covered in the first 20 pages; the remaining 135 pages of the book examine these points, and many others, in more detail. The writing is clear, the observations are pointed and believable, and most of what Spool and his colleagues say can immediately be put into practice. In short, Web Site Usability is excellent value for the money, and an excellent example of how professionals should use empirical study, rather than guesswork and prejudice, to guide their work. My only complaint is that it's hard to figure out from the text how many (or how few) testers the editors actually used.
Louis Rosenfeld and Peter Morville's Information Architecture for the World Wide Web complements Web Site Usability nicely. An information architect is someone who is responsible for organizing data to make details findable, patterns apparent, and complex ideas clear. The card catalog in the library I worked in after school when I was a teenager, and the table of contents and index of a book, are the most venerable bits of information architecture around, but relational databases and the Web are catching up fast. The difference between good and bad information architecture is as hard to pin down as the difference between good and bad physical architecture, but it is also as immediately noticeable, and has at least as much influence on productivity and enjoyment. A well-structured web site is like a quiet, comfortable cafe; most, unfortunately, have more in common with reform school cafeterias.
Thankfully, the motherhood and blackberry pie part of Information Architecture is fairly short. Most of its 10 chapters are spent describing what information architects do, and how they can tell if they're doing it right. There's a whole chapter on "Designing Navigation Systems," which talks about how links should be structured, rather than how to change their color or make them say ouch! when they're clicked. There's another chapter on "Labeling Systems," and another on searching, which includes a discussion of how to understand the ways in which users actually conduct searches. This chapter even suggests that it doesn't always make sense to make pages searchable; while this is technologically heretical, it may make perfect sense from a usability point of view.
Information Architecture closes off with a short case study, a six-page (unannotated) bibliography, and a brief but useful index. As with most organizational books, much of what it says will seem obvious in retrospect, but 10 minutes of random surfing ought to be enough to convince anyone that the Web would be in less danger of drowning in its own cancerous success if more designers -- and managers -- paid attention to this book's precepts.
Unlike the previous two books, Lincoln Stein's Official Guide to Programming with CGI.pm is chock full of technical details and Perl widgetry. CGI.pm is a Perl module for creating and processing HTML. Instead of dozens of lines of print statements and regular expressions, you can simply load CGI.pm and ask it for parameter values, button states, and the like. CGI.pm doesn't make web scripting painless -- it can't make any of the decisions that so concern the authors of Web Site Usability and Information Architecture, for example; but it's like having a power saw instead of a dull hand-held. After finishing its discussion of the basics of CGI.pm, some advanced features, ways of extending the module, and the reference guide, I had only one question: Who decided that this book was "official" and that others on the same subject were not?
I suspect the answer is "someone in marketing," and I further suspect I'd get the same answer if I asked who was responsible for calling the next book: Jesse Liberty's Clouds to Code. I lay awake for over an hour one night after noticing the possessive in the title, trying to figure it out; guess I should have checked whether they were serving decaf at dinner before having thirds...
That oddity aside, Clouds to Code is readable, enjoyable, and informative. It is a semifictionalized account of the design, development, and deployment of an automated calling system. There are no embarrassing "slice of life" dialogues, and no discussion of the office politics of the rich and infamous. Instead, Liberty describes how he and his colleagues set about creating a particular piece of software. The chapter titles reflect the project's progress: "Conceptualization," "Analysis," "High-Level Design," "Low-Level Design," "Implementation," "Getting to Feature Freeze" (which has sections ranging from "Prioritizing" to "Implementing the IPC in COM"), and "Delivering Version 1.0." Each chapter is a healthy mix of the abstract, such as how to get management buy-in when you have to cut features to meet a deadline, and the concrete. What's more, the concrete bits are refreshingly up-to-date: Diagrams, for example, are (mostly) done using the recently standardized Unified Modeling Language (UML).
Where Steve McConnell's Rapid Development is a survey, Clouds to Code shows what good software development looks like in practice. Its only weakness is an unavoidable one: Any concrete description of code development has to present real code. That code is inevitably going to be uninteresting to most people, and go stale pretty quickly. I would have devoured this book when I was 20 or 25; I still got a lot out of it at 35, and enjoyed getting a glimpse into a good craftsman's mind.
I didn't enjoy the last two books in this month's review as much as the first four, but that's not necessarily the books' fault. Raphael Finkel's Advanced Programming Language Design reminded me of a Victorian naturalist's description of his most recent expedition up the Orinoco. The book is dedicated to Finkel's father, "Who first tickled my interest in programming languages by announcing that he was learning a language that could be read and written, but not pronounced."
I was fascinated by some of the ideas in this book, such as how different notions of what a "type" is can have a profound influence on how easy or difficult it is to do certain things in a programming language, or how coroutines can be used to replace more traditional control structures. Some of it, however, fell under the heading of "more detail than I needed" -- figuring out how to achieve the appearance and effect of CLU iterators in C using macros might be a real intellectual challenge, but that doesn't mean it's worth sharing. And in some parts, such as the discussion of concurrent programming, I got the feeling that the author's descriptions were secondhand; his discussion was shallower and less incisive than the earlier parts of the book. While it's probably worth reading for ideas if you're designing a new language, it's probably not worth reading if you're simply curious.
Tim Mikkelsen and Suzanne Pherigo's Practical Software Configuration Management was a disappointment. It has always struck me as odd that there are hundreds of books about building compilers and operating systems, which relatively few programmers ever do, but very few on everyday activities like setting up and maintaining a code base or packaging software so that it can be installed by people who aren't intimately familiar with it. Based on its table of contents and the "Hewlett-Packard Professional Books" imprint on its cover, I had high hopes. Unfortunately, PSCM is slow moving and shallow. There is, for example, little discussion of how version control systems actually track changes, or of how they track and store branches when several versions of a program are being developed concurrently. While most users probably don't care, sooner or later every CVS administrator has to unbreak a repo, at which point that kind of information is suddenly worth its weight in overtime. PSCM also devotes far too much space to a feature-by-feature comparison of various commercial and public-domain tools. Yes, this information is valuable, but only if it's fresh; a web site updated twice a year would have been far more useful.
DDJ