
continued discourse on IA
Commenting on our previous post on Information Architecture (IA), Gene Roche provides a link to a Princeton PDF containing a plan for "creating website Information Architecture and Content" from the ground up. (Thanks Gene.)
The Princeton folks have a very detailed plan for (re-)creating a web site. If we weren't fortunate enough to have mStoner guiding us through this process, I think we could do quite well from the Princeton guidelines. In fact, before I go further, let me be clear—the document as a whole is very impressive, and rich in specifics for implementation. But...
I must take issue with the definition (or at least the implementation) of IA provided in the Princeton PDF as presented both in the glossary (p.40) and in the section, "What's Next?" (p.25). In fact, when I reached page 25, my disappointment was audible as I read:
You have now developed the information architecture for your site.
Granted, there are 18 more pages after this point (if you include section heads in the page count). Even so...
When I reached this point in the reading, I had the vivid memory of sitting in a Master's-level education course here at William and Mary in which the professor (Robert J. Hanny, Ph.D., now Emeritus) paced through the room asking each student in turn to define "curriculum"—and, with rare exception, responding to each student in turn:
Are you going to New York or by train?
My professor's point was that many of our definitions confused the "what" of our curriculum with the "how" of our teaching methods.
Likewise, it seems to me that Information Architecture is easily confused (or equated) with a set of elements of implementation for the web redesign process:
- We need a site map.
- We need two levels of navigation.
- We need a wireframe.
- We need a consistent design and "visual presence."
In writing the previous post, it was not my intent to slam Black and Decker as a company.
As the Technical Director for a local high school theater department, I used a number of very nice B&D power tools—my favorite being a corded variable speed drill. The grip above the motor fit my thumb and index finger, allowing me to apply pressure directly along the axis of the bit, while leaving my ring finger over the trigger, and my middle finger over the forward/reverse switch. Not the traditional way to grip a drill? For driving hundreds of drywall screws through lumber without pre-dilling, this works great! Sadly, B&D no longer makes this drill. Lowes sells a DeWalt D21008K that is pretty close, though—picture it in hunter green, without the clippy-thing on top.
As I selected blackanddecker.com as the example of contrast for the previous discussion, let's put them under the microscope once more. This time, let's apply Princeton's checklist (with appropriate university-to-corporate allowances) to blackanddecker.com and see how it stands up:
- Did the blackanddecker.com development process result in tasks, products, and sections of the web site being sorted logically?
- Seems like it to me. The navigation systems seem well-thought-out and reasonably complete. Almost any product or task can be reasonably found by category (ignoring search for the moment).
- Does blackanddecker.com use a dual navigation scheme?
- Yes—both task based (where to buy, contact us, product registration) and product based (power tools, lasers, etc.).
- Does blackanddecker.com have a consistent "visual presence"?
- Sure. Whether you are fond of orange-and-black or not, the B&D logo and colors are consistently applied throughout. Likewise (beauty being in the eye of the beholder) the site makes pretty good use of visuals, with Flash elements on the product based navigation, and product images on most product pages.
In fact, going through the Princeton checklist, it looks like blackanddecker.com is a great site! So they must have a great Information Architecture, right? Yet in the previous article, we set the site up as the quintessential example of poor IA. What gives?
Actually, the disclaimers we inserted in the previous post make two points:
- IA is necessary for long-term sustainability, whether of navigation and menus, site map, visual presence, the content itself (as it grows and evolves), or the search feature.
- The B&D site may indeed have a good IA underneath, and simply a poor search feature implemented on top of it. If this is the case, making the search feature better should be attainable; while doing so would be much harder if the underlying IA is less robust.
The fact of the matter is that we cannot know the extent of the IA present behind blackanddecker.com without some inside information. But we can say, as we did last time, that the current implementation of the search feature makes little use of IA. Additionally, we can say that without a strong IA, improving the search feature is difficult. Finally, we see that IA is not simply the combination of a defined list of features present within a single site.
So what have we learned from this example about the nature of IA?
There are a few points I'd like to draw from this:
- IA is not the sum of a list of desirable features
- Adding logical navigation, Section 508 compliance for accessibility, a good search feature, etc. would be wonderful improvements to our existing web site. The lack of these features generate the greatest criticisms of our site. But fixing all of these features doesn't take the place of (and is not equivalent to) a robust, foundational Information Architecture.
- IA does not magically produce all of these features
- If the sum of the features simply add up to their sum, and nothing more, then will it be true that the "something more" (IA) will produce all of these features? Sadly, no. It would be nice if menuing and navigation, search, usability, accessibilty, etc. all just happen for us. But the reality is that each of these still takes art, skill, user-testing, and hard-work. So what value does IA provide? Well...
- Without IA, these features must be addressed independently, and are generally less robust
- Over the long-term, things change. Having no common IA implemented within these various features, maintainability and sustainability are threatened as each feature must independently implement all changes over time
- A strong underlying IA lays the groundwork for adding features and managing change
- There are certainly features that "good" web sites share (usability, accessibility, findability, searchability, navigatability). There is no doubt that maintaining and sustaining a web presence requires work. Content is created, edited, and removed over time. New features may be needed as technologies and usage patterns evolve. Other features may be dropped. The Information Architecture itself should be robust and flexible enough to adjust to these over time. As adjustments are needed, as feature changes, and as content comes and goes, the IA provides a common starting point for change. With solid IA, the changes can be addressed holistically—each feature and change implementing a common underlying architecture for a unique purpose.
Are you going to New York or by train?
So what is Information Architecture, and how is it incorporated? Traditional architecture (of buildings) is intangible—more than just a style (gothic vs. post-modern) or a set of blueprints and building plans. It is both the sum of all of the things that go into the process, as well as, an art and science of practice and practitioners providing frameworks of thought and design. Likewise, when we look back at the definitions of IA in our previous post, we see this same nature.
Hopefully these monographs begin to illustrate why the re.web project has placed such heavy emphasis on the less-visible, foundational processes of the College's redesign process. Information Architecture doesn't answer the burning questions of "What color will the homepage be?" or "Will my department/program/office have a link on the homepage"—although it will inform those decisions. It is a springboard into the specific implementation details, but not simply a sum of the details.