Once Past the Front Door

Have you ever visited a web site where the homepage is well laid out, but the pages lower down in the hierarchy are nothing but a confusing mess? What went wrong? We'll look at why this sometimes happens and the steps you can take to avoid it.

People talk about a growing homogenization of web page design. Conventions have been set: navigation is on the top and side. A link to the homepage is in the top-left corner. Such inconsistency allows people to become instantly comfortable with new sites.

In the library world, we're increasingly seeing similar conventions develop. I remember the first site I ever worked on. It had only four categories: "Library Information," "Research Resources," "What's New," and a link to the telnet version of the library's catalog. Considering the variety of materials that library users are likely to need, this library-centric arrangement is certainly limiting. But a lot has happened since then.

Today, a library homepage that doesn't sport the obligatory "Books" or "Journal Articles" link is pretty unusual. Increasingly, librarians have looked at what their public wants and are transforming their homepages with the terms users themselves employ. It explains why links to renewal and reserve, library hours, and much more are popping up directly on homepages nationwide. It explains why services are being broken down not according to administrative unit (old school) but by bite-sized morsels that the public is likely to ask for. It explains the freshness and color successful sites feature to appear more user-friendly and service-oriented.

This didn't happen overnight. The path from "Library Information" and "Research Resources" to "Books," "Articles," and "Renewal" is littered with the remains of a thousand arguments over what exactly the library should be doing with its online presence, for whom, and in what way.

That's why we should give the utmost credit to a library web site that's managed to get its homepage in order. It's a sign of both an understanding of users and a terrific restraint on the part of the institution. But what happens once we step past that well-laid-out, well-appointed, capacious homepage?

It's chaos! It's as if we stepped onto the Holodeck of the Starship Enterprise and the aliens have taken over.

Of course, this just doesn't happen on library sites. In fact, library web sites are often a model of consistency compared with some examples from commerce and industry. It wasn't too long ago (1998) that finding a product on the Sears Roebuck site was one of the hardest things you could do on the web.

To this day, my alma mater (New York University) buries the library link not simply in a page called "Resources & Services" but in one of a series of lists (libraries are under Other Services), almost completely unrelieved by formatting or grouping to aid the searcher.

Apparently the model is: knock yourself out on the homepage, then "veg out" on the rest of the site. The departments we miffed by keeping them off the main page expected entire operations to be represented at least one page down. What you ignore on the top level of the site comes roaring back no matter how inappropriate for the secondary pages.

Here's an example: there's this wonderful site; it sports all the requisites of a modern, user-friendly library web site. But try to get "Research Help." People go to "Research Help" because they need help to do research—how's that for a concept. Yet what they find here is a list of the school's institutes and programs. A student looking for information on Art and Censorship might expect an alphabetical list of research guides, with one near the top marked "Art." But here the student first has to find the Blah Blah Blah Institute of Fine Arts and only under that entry is there a link to the Art Research Guide. This isn't a Help section, it's a college bulletin (and for research, it's about as helpful).

Such institution-centric approaches are common. A professor I worked with once thought it would be great if we arranged a research guide by department course number. The students would select their course number to find the information they needed. This made perfect sense to the professor. After a few discreet tries, I succeeded in demonstrating that department course numbers are probably the last things students have committed to memory. I was lucky.

Scott Andrew LePera, front end scripting wizard and author of the weblog scottandrew.com, says that standards are so important to web developers said that web development is the hardest thing of all. While he had technical difficulties in mind, no one involved on the content-end would say they've been given the easier task.

After all, it's the cumulative effect of a thousand different decisions that determine whether a site will sink or swim. It's hard to be unrelenting in only allowing content that truly meets the needs of our users. Determining this is problematic anyway since it relies less on scientific method than on a feeling for the material, for the medium, and for our audience.

Some things we can test for, some things we should test for. Will the addition or exclusion of a link tank our site? Probably not. What often ends up happening is that the easiest thing is to err on the side of inclusion—web publishing being so cheap.

This reasoning alone is responsible for much of the ballast on an otherwise good site. Add to this the "it could be useful" school, and we have the twin-headed monster that all web administrators confront. The question is where to draw the line?

All pages have weight, i.e., the cumulative size in kilobytes of the page's text and images. However, weight can also be expressed as the number of options or links a user has on a page. These, along with the instructions (if any) that explain the options, form the cognitive weight of the page.

Libraries begin with a set amount of links per page—usually around seven. It is rather quickly discovered that this is far too low and that number must be doubled. There is no law dictating how many links there should be on a page. Our users' familiarity with the information is what best determines whether we can have a lot or a little. The states of the union, a list that practically everyone is familiar with, can be thrown up any which way.

Another example is to run a long list of subject headings. Users will wade through subject headings, safely ignoring them until they find one that most closely matches what they're looking for. They are familiar with lists. What's more, the system doesn't require knowledge of the other terms to find the one you need. In cases like this, we can be generous with the proportions of our page because we're leaning on our users' knowledge to supply a bit of the navigation.

This falls apart, of course, when the list (or its arrangement) is unfamiliar, or when it doesn't contain compelling terms that leap out and grab the user.

Users don't read. And why should they? Guides and directions are huge bores. I don't read such things so why should I expect my users to do so? In cases where users are unfamiliar with the material, we have to make it perfectly clear what they must click on in order to get what they need. A long list followed by an endless explanation simply doesn't cut it.

My favorite library blooper is the interlibrary loan form that doesn't start out as a form at all. Rather it asks a series of questions: "Did you look in our OPAC to see if we don't already own the book? Did you really look? Did you really, really, really look?" Or this introduction to e-reference: "Please tell us what year, program, and major you are. Indicate the library resources (up to nine) that you've already consulted." Up to nine?

At their worst, instructions and electronic finger-wagging can be punitive. Libraries may have gotten away with this in the dark, sealed-off world of traditional service, but in the open sunshine of web-based media, it's simply not effective. It is a barrier to use, suggestive of an unfriendly site, and an open invitation for users to seek help elsewhere on the Internet.

Let's face it, when people take advantage of our services, sometimes they are going to use them incorrectly. We don't cover ourselves by obliging them to run a gauntlet of policy statements or by asking them questions not essential to the service at hand. On the homepage we don't require them to understand our institutional context. Why force it on them on a later page, the moment they wish to avail themselves of one of our services?

Here's another way of thinking about it: we're all familiar with "click-wrap" agreements for software. Imagine how they would have to be redesigned if companies actually meant them to be comprehensible. A horrifying thought and hardly a model for libraries to follow. Being policy- and instruction-light encourages use, is less confusing, and places us favorably in relation to the competition. The bottom line for services? Better to be abused than never used.

The much vaunted argument that the web is just for information rules out any need for visual design. At least that's how the observation is routinely misused. If there ever were a site where users go for information, it would be a library web site.

Yet for precisely this reason, we must have a firm grip on the visual display of information or it risks being unintelligible to our users. Simply starting with an <h> and working our way down to a couple of <p>'s with a few <ul>;'s and <ol>'s thrown in for good measure is not enough.

The business of separating content from presentation is not to eliminate presentation. We're making signs on the web, not inscriptions. We have to look at pages critically and squeeze out whatever key terms they have. Those terms should be so compelling that our users will get to the information they need. We make those terms work, in part, by how we position them on the page—by the prominence we give them. This is completely a question of visual display and labeling.

Labeling is a science in itself. Louis Rosenfeld and Peter Morville in Information Architecture for the WWW (O'Reilly, 2002; 2d ed.) remind us that "a site serves as an intermediary that translates messages in content form from the site's owners and authors to users and back again." To avoid confusion, we design labels that "speak the 'same language' as a site's users while reflecting its content."

Fixing the terminology isn't simply a top-level function. It applies to pages lower down in the hierarchy as well as to individual pages themselves. One reason users have difficulties transitioning from top-level to lower-level pages is because the labeling scheme isn't doing its job—or it's not meaning the same thing to content provider and user.

That's where testing comes in. The techniques used to develop the original top-level architecture can be reapplied all the way down the hierarchical structure. We can use all the old friends, from card-sorting to prototyping, to make sure that lower-level groupings make sense.

Our original user surveys and testing, for example, might indicate a great need for a help section. That doesn't mean we're free to load everything we might find helpful. Instead, we have to gird ourselves for another round of testing and interviews—this time to figure out what our users imagine "help" to be. Once determined, we have to test the arrangement or groupings of materials. Our goal is to create an effective architecture for the subsection.

After this is done, we can begin to think about arranging the subsection in a visually significant way. Visual display doesn't cease to be a consideration simply because we're lower down in the hierarchy.

There is a whole world of examples from the better commercial web sites. We can learn from them. How do they do it? Is the information they offer any less complex than what we have? Don't you believe it! It's just that the good ones have honed down the presentation to the absolute essential elements and expressed them in a user-friendly and engaging way. Of course commercial services have far more resources than libraries do. Yet we can all take advantage, by way of example, of what their better funding provides.

The biggest challenge is the drain on our time. Our only consolation (besides the excellence of our product) is that many have trod this same path. The techniques are cheap, well known, and widely discussed. Methodologies and test materials can be found in any number of places. Good places to start are such information architecture megasites as Info-Design (www.bogieland.com/infodesign), iaslash (www.iaslash.org), and Boxes and Arrows (www.boxesandarrows.com).

In a way, we have to design to the last page. That means we must make organization and layout manifest throughout the entire web site and not simply down to the first or second level.

Sometimes we have no choice in what we put up—such is the drawback of working in a collaborative environment. But we can even the odds if we're prepared to demonstrate how certain methods and approaches are better than others.

One of these is abiding by the priorities of our users. Acknowledging these priorities and centering our efforts on meeting them is the beginning of all successful web organization. I sometimes think that the design of our web sites ought to read like the executive summary of our user survey results. Increasingly this is happening, to the great benefit of our present and future users.