Book Review
Tom Zillner, Editor
Information Architecture for the World Wide Web
by Louis Rosenfeld and Peter Morville. Sebastopol, Calif.: O'Reilly, 1998. 202p. $29.95 (ISBN 1-56592-282-4).
Information Architecture, published in 1998, is a relatively old book. In Internet time, that's at least a couple of generations ago. I think it's worth attention because it's a classic volume that will help anyone interested in designing a Web site from the ground up or attempting to fix a Web site that is not as usable as it might be.
This is a book by librarians (although they've migrated into the field of information architecture) but it is not a book that is primarily for librarians. The language of the librarian creeps in a bit, most notably when the authors discuss controlled vocabulary, but the real meat is not masked by librarian-speak. Rosenfeld and Morville are subtler than that. They present important concepts that are familiar to librarians but couched in plain language that uses plenty of examples.
The book hits the ground running. Rosenfeld and Morville recommend that the people who will be building a Web site get together in what they call "Consumer Sensitivity Boot Camp," in which they air both the things they hate and like about the Web. Ultimately the goal is to produce lists of things that work and don't work and use this as a background for the actual design and production of the site.
The book then pulls back from an active start to describe the role of the information architect and some suggestions for who might take on this role. Because many people are unfamiliar with information architecture and architects, it is a good idea to provide some coverage of these terms as well as contrasting the role of the information architect with the roles of others on the design team. It's important to note that this book targets both the large commercial project where information architects might be part of an outside consulting firm and the smaller project consisting of just a few people and a miniscule budget.
Creating a Web site starts with determining an organization scheme. An example of a organization scheme is the alphabetical arrangement of a telephone book or the layout of a supermarket. These are two very different schemes, suggestive of the wide range of possibilities. It should ordinarily take some time to determine the best organization scheme or schemes for a Web site. A different but related task is looking at possible organization structures for the site. An example of an organization structure is the hierarchy, the most commonly used structure in site design. Other examples of Web site organization structure include hypertext, where there are "content chunks" connected via links. There are pros and cons to each structure and these are well covered by Rosenfeld and Morville. An interesting aspect of the discussion of organization structures is a seeming bias toward a relational database model. Although one can glean some of the benefits of such a model from the discussion of database implementation, it's not clear that the author's explication of this model provides a solid rationale for its use.
If this all sounds a bit complicated that's because it is, but it's important to have a grounding in organization schemes and structures before taking any further steps in the design process. The next step is to consider possible navigation systems to employ. Hierarchical navigation systems are the norm, starting out at a home screen and filing down to subsidiary pages through the use of top-level links. Rosenfeld and Morville point out that this sort of navigation is often of limited use and other navigation methods should be considered, such as global navigation, where it is possible on any given page to navigate via tools similar to navigation bars. Local navigation is the use of additional tools for a sub-site of the larger site and it is a complement, not a replacement, for global navigation.
The authors also address labeling systems. It really takes a librarian (or an information architect who has a librarian's training) to appreciate the importance of labeling systems. There are many species of labels within Web sites, but they should all be consistent and clear with each other and fit into a cohesive whole. While such a directive may sound vague and unclear, the authors do a good job of explaining the importance and application of labeling systems within a Web site. In this chapter, they discuss controlled vocabularies and thesauri and the value of their use in selecting appropriate labels. The authors even mention Library of Congress Subject Headings, although they point out that given its goal of describing "the universe of knowledge," the subject headings are wildly inappropriate for use as a thesaurus. The key is to find a narrowly focused thesaurus specific to the information the Web site will carry. Other types of tools to construct labeling systems are also covered. All in all, this chapter well deserves the twenty-five pages devoted to it.
Similarly, there is a comprehensive chapter on selecting indexing and searching systems. While most of us tend to throw in a search engine that's linked from any page and performs a simple search on the entire site, this isn't necessarily desirable. In fact, the chapter starts with a discussion of instances when you should not make your site searchable. Following are sections discussing searching behavior and search interface design. The important point of this chapter is that indexing and searching are not one-size-fits-all propositions; real work is required to determine how people will use your Web site and to construct a scheme that matches their behavior.
In these beginning chapters, which account for a good portion of the book, emphasis is placed on the foundation pieces of information architecture. The authors then move from these foundation pieces to actual practice. The first step in creating a Web site is research. It's important to stay with this process rather than leap into construction. This is a common mistake, particularly where budgets are small or where there is a rush to get "something" up, no matter how ill thought out that something might be.
Research must include face-to-face meetings. Other types of communication just don't work when discussing and working on an inherently visual medium. Rosenfeld and Morville recommend that the first item on the agenda for the first meeting be a critique of existing Web sites. This critique cannot effectively take place via phone or e-mail. What the participants say is partly a matter of consensus reached through exploration rather than just a yea or nay vote. The critique also is an ice-breaker, getting the members of the team better acquainted. If there is just one person responsible for the site, that one person should put together a team of people who have a vested interest in the site's content, whether they are colleagues in other departments of the same institution or users from outside the organization.
The meetings should include the definition of goals, intended audience, and content. All of this is easy enough to understand from most people's experience and the clear explication of the authors. Content inventory completes the first stage of the design and implementation process. This inventory is developed from wish lists and a setting of priorities regarding information to be included on the site.
The next steps in the process fall under the heading of conceptual design. As with the rest of the book, the reader may find these activities are covered in extensive detail, but as usual the devil is in the details. Rosenfeld and Morville discuss the respective merits of high-tech white boards that capture what's written for subsequent viewing and printout versus flip charts with a bit of levity. The authors' state, "We're guessing many of these gadgets are more trouble than they're worth. Sorry for the skepticism, but what do you expect from librarians?"
Metaphor exploration is also examined. I am skeptical of the heavy-handed use of metaphor in our computerized and netted life. The desktop metaphor is useful, but it's unclear if we will ever escape it to something that better suits our increasingly Internet-centric lives. Categories of metaphor are presented and one example provided is of the Internet Public Library's (IPL) reference center (http://www.ipl.org/ref). The center is graphically represented as a room in a library, with the friendly librarian behind a desk and books labeled with hotlinks to various subject areas. This mainly works well, but the addition of a link to a multi-user object oriented environment (MOO) results in a possibly jarring addition of a sign pointing to another room. Unlike the authors, I think this metaphor works just fine. But we've all seen plenty of cases where metaphor clutters a site with graphics. Judicious use of graphics in the service of a metaphor that assists the user in navigating the site is wonderful, but metaphor is easily abused.
Scenarios are presented as another part of the conceptual design process. They are simply descriptions of how various sorts of users would use the site. I say "simply," but the construction of realistic scenarios can be a daunting task. For one thing, if you don't have enough outsiders working with you to put together the site plan, it is very easy to make ill-conceived assumptions about users. Perhaps the most common tendency is to assume that users are very much like oneself, but other equally suspect assumptions may be made. This is the stage where relative outsiders may ask hard questions that result in a better set of working assumptions underlying scenarios.
One thing that Rosenfeld and Morville underemphasize is the involvement of users at some early point in the process of design and construction. Scenario building is a great place to begin user involvement, but even earlier is better. Users often traverse and utilize a site in ways never envisioned by architects and designers.
Next in the process are architectural blueprints. This is the point at which the information architect puts together a high-level diagram of the site. The high-level blueprint "shows pages, components within pages, groups of pages, and relationships between pages." Sounds more like a detailed blueprint, but that will be even more in depth and occurs at the last design stage. Prior to this the graphic designer comes forward with page design ideas leading to page prototypes and then templates. Both the high-level blueprints and the page design need to be approved by the committee formed at the project's beginning.
At the prototype stage the graphic designer comes to the fore and mounts pages for evaluation and critiquing. This is one of the first of the tangible "deliverables," and it can dazzle. As Rosenfeld and Morville suggest, this is a time when esthetics take center stage. But its important to look at the prototype with something of a jaundiced eye. The graphics can play an important role in complementing the content or they can overpower or confuse the user. It's best to use a graphic designer with Web experience instead of breaking in someone from the print world. It's also important to not spend an overly long time on this phase. I have been involved in a corporate identity project where weeks were spent getting interested parties to agree on a logo. I am sure this same phenomenon can rear its ugly head in Web prototyping. Try to get participants to focus on how the graphics work for the site and worry less about the esthetics of the graphics themselves.
As mentioned previously the production stage is the point for detailed blueprints, as well as content mapping and a Web page inventory. For a small site this is fairly easy to put together, although small sites tend to have fewer staff committed to the project. For large projects there needs to be a small cadre of people dedicating much of their time to the site's planning and production. It's a lot of work. And then there comes the actual production of pages. Templates can help, but it's still hard work.
Information Architecture for the World Wide Web is certainly worth a read. It's a few years old, but has aged more gracefully than many others of its ilk by concentrating on the essentials. Anyone who creates a site is an information architect whether they know it or not. It's better to make choices consciously rather than unconsciously. I think that a weakness of the book is a failure to explore user testing more extensively, but this is something that is missed by most books in this category. All in all, a book to read in its entirety and use as a guide along the way.
2102 Books