Information Architecture for the World Wide Web

Content preview·Buy reprint rights for this chapter

What is it about buildings that stir us? Regardless of whether we consider ourselves architectural connoisseurs or just plain folks, we all encounter different physical structures every day. Each building affects us emotionally, whether we realize it or not.

Just this evening, I spent time in a dark, smoky bar with original tin ceilings and exposed brick walls. The bar has been around forever, as have some of the patrons, but I chose to spend time sipping beer there rather than in the neighboring gleaming microbrewery that opened last year. The new place has a wider menu of beers, better food, and non-smoking sections, but tonight I preferred the old joint with the great graffiti on the bathroom walls.

After the bar, I went to a café to read. Ann Arbor has about 25 cafés, 10 of which are within walking distance of each other, and they're all decent places. So why did I go to this one? It has a great nook with soft chairs and a low ceiling, providing an almost totally enclosed space where I can have the privacy I want.

And now I'm back at the office. Our space is located in an old building that originally was a mechanic's garage. What was once the oil pit is now a sunken-level workspace for graphic designers. Exposed timber beams lift the roof high over an eclectic space conducive to creativity. After the garage closed, the building was a greasy spoon; my office is where the kitchen used to be. Repurposed every decade or so, our building has worn many hats over time and overflows with history. Back in 1918, the builder could never have conceived that it eventually would be occupied by a Cajun restaurant or a travel agency, much less an information architecture firm.

Why so much talk about the impressions that physical structures make on us? Because they are familiar to us in ways that web sites are not. Like web sites, buildings have architectures that cause us to react. Buildings and their architectures therefore provide us with great opportunities to make analogies about web sites and their architectures.

Buildings and their architectures are diverse. Consider the extent of architectural ground I covered in my brief evening jaunt. Buildings look different—or are architected differently—because they must cater to so many different uses, users, and moods. Warehouses, strip malls, and Chinese restaurants look and work the way they do because they are designed for varying uses. Drinking beer with friends, reading quietly, and working all require different environments to succeed. Web sites are the same; we visit them to learn about alternative medicine, play games, or vent our frustration. So each web site requires a different architecture, designed with its particular users and uses in mind.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Regardless of your level of experience producing web sites, you should revisit Consumer Sensitivity Boot Camp before beginning a new site or new phase of an existing site. Why? Well, if you are an experienced site developer, you're probably too jaded to remember what it's like to be a new user (this has certainly happened to us). If you're new at this, then it's likely that you're so excited by design and technical options that you're too distracted to worry about the user. If you work for a large organization, its personality, jargon, and self-perspective may be so instilled in you that you can't begin to imagine what an outsider encounters when confronted by your corporate culture. So now is a good time to run through our Consumer Sensitivity Boot Camp exercise.

Start by assembling the people who will work on developing the site. If this is just you, bring some other folks on board so you have a broader set of perspectives to draw on. So pull together some friends, coworkers, or anyone with at least a little experience using the Web.

Just about everyone in the group knows from their own experiences that using a web site has both good and bad aspects; the secret is to unlock those sentiments by forcing the participants to articulate them. Do this by asking your group (and yourself) to brainstorm answers for the following two simple questions:

What do you hate about the Web?
What do you like about the Web?

Usually we start with the hate question, because, interestingly (and sadly) enough, it's almost always easier for people to talk about negatives than positives. In group settings, it's a great way to break the ice. As the participants spew their venom (or offer their niceties), jot each point down on a white board or flip chart.

Once these issues are aired, run through the positives and negatives. Discuss any natural groupings that you notice. We almost always find that the issues raised fall into three general areas: 1) Technical (e.g., effective use of interactivity, bandwidth/download issues); 2) Look and Feel (e.g., complementary aesthetics and functionality, the importance of good copyediting); and 3) Something Else (e.g., finding information sites, site navigation issues). Interestingly, these Something Else issues often directly relate to information architecture. As this is likely the first time the participants have ever been introduced to the concept of information architecture, we like to emphasize strongly that it really does exist and does merit the same consideration as more obvious, tangible areas such as graphic and technical design.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Maybe you don't really want to go to Consumer Sensitivity Boot Camp. So we've decided to give you a break and share with you the types of likes and dislikes we often hear from our own clients and colleagues, sprinkled liberally with our own biases.

We found that compiling this list was quick work, as we see these design sins every day, and have committed quite a few over the years ourselves.

Section 1.2.1.1: Can't find it

You know great information is available in a certain web site. At least, that's what you've heard, but every time you look for it, you can't find it. Maybe you were even bounced out of the site altogether through some external link. Sites like these often provide no index, table of contents, or site map, and no search facility. Even worse, the labels they use for their information are obscure; they may mean something to someone else, but not to you. Another problem can be when the content is moved around repeatedly, so that something here today is gone tomorrow.

Even when users aren't looking for particular information within a site, they can often be befuddled by a poor navigation system. A common example of this phenomenon is navigational headers and footers that are inconsistent from page to page. Another example: backgrounds and color schemes that radically change from page to page within the same site. Users may wonder if they are even using the same site at all.

Section 1.2.1.2: Poor graphic design and layout

It's becoming almost passé to complain about web sites with huge image files that take a long time to download, but people tend to hate a host of other graphic design-related problems. Pages crowded with text, links, graphics, and other components make it harder for users to find information on those pages. Many designers forget that white space is as important a component of a page as anything else. Crowding results in long pages that require scrolling to get to important items.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Information Architect: 1) the individual who organizes the patterns inherent in data, making the complex clear; 2) a person who creates the structure or map of information which allows others to find their personal paths to knowledge; 3) the emerging 21st century professional occupation addressing the needs of the age focused upon clarity, human understanding and the science of the organization of information.

—Richard Saul Wurman

Now that you know right from wrong from the web consumer's perspective, you're in a much better position to develop a web site. But besides needing a sophisticated knowledge of what works for consumers of the Web, what's actually involved in creating a web site?

Obviously, you need HTML pages. Maybe you'll grab a good HTML book or a decent HTML editing package. Maybe a high school kid can do the trick for peanuts. What about the copy for those pages? It needs to come from somewhere—perhaps existing brochures and documentation; perhaps it needs to be written from scratch. You'll also need some graphic design expertise to make sure that the pages are laid out with effective use of text, white space, and attractive images. Of course you'll need a server that is connected to the Internet; this you can lease, or you can buy one of your own. If you do, just be sure to hire someone sufficiently technically astute to administer that server. Perhaps that person should also write the CGI, Perl, ActiveX, Java, and other scripts that make the site interactive. What's missing? Maybe a project manager to make sure all these folks work together to develop the site without running behind schedule and over budget.

So now you're all set to design your web site, right?

Well, not quite. What's missing from this picture is a definition of what the site will actually be, and how it will work.

This may sound obvious, but for most web sites, it's true: design and production storm ahead without any unifying principle to guide the site's development. A web site essentially can be anything you want it to be and could cost millions of dollars, take years to complete, and cost thousands of lives to develop. To avoid such overkill, it will need to be defined somehow: it will need a

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now that you know right from wrong from the web consumer's perspective, you're in a much better position to develop a web site. But besides needing a sophisticated knowledge of what works for consumers of the Web, what's actually involved in creating a web site?

Obviously, you need HTML pages. Maybe you'll grab a good HTML book or a decent HTML editing package. Maybe a high school kid can do the trick for peanuts. What about the copy for those pages? It needs to come from somewhere—perhaps existing brochures and documentation; perhaps it needs to be written from scratch. You'll also need some graphic design expertise to make sure that the pages are laid out with effective use of text, white space, and attractive images. Of course you'll need a server that is connected to the Internet; this you can lease, or you can buy one of your own. If you do, just be sure to hire someone sufficiently technically astute to administer that server. Perhaps that person should also write the CGI, Perl, ActiveX, Java, and other scripts that make the site interactive. What's missing? Maybe a project manager to make sure all these folks work together to develop the site without running behind schedule and over budget.

So now you're all set to design your web site, right?

Well, not quite. What's missing from this picture is a definition of what the site will actually be, and how it will work.

This may sound obvious, but for most web sites, it's true: design and production storm ahead without any unifying principle to guide the site's development. A web site essentially can be anything you want it to be and could cost millions of dollars, take years to complete, and cost thousands of lives to develop. To avoid such overkill, it will need to be defined somehow: it will need a definition.

That's the main job of the information architect, who:

Clarifies the mission and vision for the site, balancing the needs of its sponsoring organization and the needs of its audiences.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The information architect of a large, complex web site should be two things: someone who can think as an outsider and be sensitive to the needs of the site's users, and at the same time is enough of an insider to understand the site's sponsoring organization, its mission, goals, content, audiences, and inner workings. In terms of disciplinary background, the information architect should combine the generalist's ability to understand the perspectives of other disciplines with specialized skills in visualizing, organizing, and labeling information. As it's very difficult for someone to retain all of these characteristics, you'll have to make some compromises, but it's important to consider them as you search for that elusive information architect.

Because information architecture is largely about the big picture view of the organization, its goals, and its politics, a logical choice for the architect role is a senior person who knows the organization as a whole and who isn't involved exclusively within the activities of one department. A senior person can often think like an outsider even though being on the inside, and has enough clout to enlist other departments' resources when necessary. One drawback to choosing a senior level manager is that he or she may have so many other responsibilities that the work gets delegated out to staff, thereby negating the original goal of using a single, organizationally savvy person.

Another approach is bringing in a true outsider: a new hire or a consultant (we typically function in the latter role, but we are trying to avoid biasing our discussion too greatly). The great thing about outsiders is that they can get away with asking naive questions considered suicidal by insiders, such as "Why does your organization have two completely separate order fulfillment departments? The web site will confuse users if they can order products in two different, unresolved ways. Are there any politics going on here that we can get past to improve the site's design?"

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The information architect must communicate effectively with the web site development team. This is challenging, since an information architecture is highly abstract and intangible. Besides communicating the architecture verbally, documents (such as blueprint diagrams) must be created in ways that can be understood by the rest of the team regardless of their own disciplinary backgrounds.

In the early days of the Web, web sites were often designed, built, and managed by a single individual through sheer force of will. This webmaster was responsible for assembling and organizing the content, designing the graphics, and hacking together any necessary CGI scripts. The only prerequisites were a familiarity with HTML and a willingness to learn on the job. People with an amazing diversity of backgrounds suddenly became webmasters overnight, and soon found themselves torn in many directions at once. One minute they were information architects, then graphic designers, then editors, then programmers.

Then companies began to demand more of their sites and, consequently, of their webmasters. Simple home pages quickly evolved into complex web sites. People wanted more content, better organization, greater function, and prettier graphics. Extensions, plug-ins, and languages proliferated. Tables, VRML, frames, Shockwave, Java, and ActiveX were added to the toolbox. No mortal webmaster could keep up with the rising expectations and the increasing complexity of the environment.

Increasingly, webmasters and their employers began to realize that the successful design and production of complex web sites requires an interdisciplinary team approach. An individual cannot be an expert in all facets of the process. Rather, a team of individuals with complementary areas of expertise must work together. The composition of this team will vary, depending upon the needs of a particular project, available budget, and the availability of expertise. However, most projects will require expertise in marketing, information architecture, graphic design, writing and editing, programming, and project management.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The beginning of all understanding is classification.

—Hayden White

Our understanding of the world is largely determined by our ability to organize information. Where do you live? What do you do? Who are you? Our answers reveal the systems of classification that form the very foundations of our understanding. We live in towns within states within countries. We work in departments in companies in industries. We are parents, children, and siblings, each an integral part of a family tree.

We organize to understand, to explain, and to control. Our classification systems inherently reflect social and political perspectives and objectives. We live in the first world. They live in the third world. She is a freedom fighter. He is a terrorist. The way we organize, label, and relate information influences the way people comprehend that information.

As information architects, we organize information so that people can find the right answers to their questions. We strive to support casual browsing and directed searching. Our aim is to apply organization and labeling systems that make sense to users.

The Web provides us with a wonderfully flexible environment in which to organize. We can apply multiple organization systems to the same content and escape the physical limitations of the print world. So why are many large web sites so difficult to navigate? Why can't the people who design these sites make it easy to find information? These common questions focus attention on the very real challenge of organizing information.

In recent years, increasing attention has been focused on the challenge of organizing information. Yet, this challenge is not new. People have struggled with the difficulties of information organization for centuries. The field of librarianship has been largely devoted to the task of organizing and providing access to information. So why all the fuss now?

Believe it or not, we're all becoming librarians. This quiet yet powerful revolution is driven by the decentralizing force of the global Internet. Not long ago, the responsibility for labeling, organizing, and providing access to information fell squarely in the laps of librarians. These librarians spoke in strange languages about Dewey Decimal Classification and the Anglo-American Cataloging Rules. They classified, cataloged, and helped us find the information we needed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In recent years, increasing attention has been focused on the challenge of organizing information. Yet, this challenge is not new. People have struggled with the difficulties of information organization for centuries. The field of librarianship has been largely devoted to the task of organizing and providing access to information. So why all the fuss now?

Believe it or not, we're all becoming librarians. This quiet yet powerful revolution is driven by the decentralizing force of the global Internet. Not long ago, the responsibility for labeling, organizing, and providing access to information fell squarely in the laps of librarians. These librarians spoke in strange languages about Dewey Decimal Classification and the Anglo-American Cataloging Rules. They classified, cataloged, and helped us find the information we needed.

The Internet is forcing the responsibility for organizing information on more of us each day. How many corporate web sites exist today? How many personal home pages? What about tomorrow? As the Internet provides us all with the freedom to publish information, it quietly burdens us with the responsibility to organize that information.

As we struggle to meet that challenge, we unknowingly adopt the language of librarians. How should we label that content? Is there an existing classification system we can borrow? Who's going to catalog all of that information?

We're moving towards a world where tremendous numbers of people publish and organize their own information. As we do so, the challenges inherent in organizing that information become more recognized and more important. Let's explore some of the reasons why organizing information in useful ways is so difficult.

Classification systems are built upon the foundation of language, and language is often ambiguous. That is, words are capable of being understood in two or more possible ways. Think about the word pitch. When you say pitch, what do I hear? There are actually more than 15 definitions, including:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The organization of information in web sites and intranets is a major factor in determining success, and yet many web development teams lack the understanding necessary to do the job well. Our goal in this chapter is to provide a foundation for tackling even the most challenging information organization projects.

Organization systems are composed of organization schemes and organization structures . An organization scheme defines the shared characteristics of content items and influences the logical grouping of those items. An organization structure defines the types of relationships between content items and groups.

Before diving in, it's important to understand information organization in the context of web site development. Organization is closely related to navigation, labeling, and indexing. The hierarchical organization structures of web sites often play the part of primary navigation system. The labels of categories play a significant role in defining the contents of those categories. Manual indexing is ultimately a tool for organizing content items into groups at a very detailed level. Despite these closely knit relationships, it is both possible and useful to isolate the design of organization systems, which will form the foundation for navigation and labeling systems. By focusing solely on the logical grouping of information, you avoid the distractions of implementation details and design a better web site.

We navigate through organization schemes every day. Phone books, supermarkets, and television programming guides all use organization schemes to facilitate access. Some schemes are easy to use. We rarely have difficulty finding a friend's phone number in the alphabetical organization scheme of the white pages. Some schemes are intensely frustrating. Trying to find marshmallows or popcorn in a large and unfamiliar supermarket can drive us crazy. Are marshmallows in the snack aisle, the baking ingredients section, both, or neither?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

As you've seen in this chapter, organization systems are fairly complex. You need to consider a variety of exact and ambiguous organization schemes. Should you organize by topic, by task, or by audience? How about a chronological or geographical scheme? What about using multiple organization schemes?

You also need to think about the organization structures that influence how users can navigate through these schemes. Should you use a hierarchy or would a more structured database-model work best? Perhaps a loose hypertextual web would allow the most flexibility? Taken together, in the context of a large web site development project, these questions can be overwhelming. That's why it's important to break down the site into its components, so you can tackle one question at a time. Also, keep in mind that all information retrieval systems work best when applied to narrow domains of homogeneous content. By decomposing the content collection into these narrow domains, you can identify opportunities for highly effective organization systems.

However, it's also important not to lose sight of the big picture. As with cooking, you need to mix the right ingredients in the right way to get the desired results. Just because you like mushrooms and pancakes doesn't mean they will go well together. The recipe for cohesive organization systems varies from site to site. However, there are a few guidelines to keep in mind.

In considering which organization schemes to use, remember the distinction between exact and ambiguous schemes. Exact schemes are best for known-item searching, when users know precisely what they are looking for. Ambiguous schemes are best for browsing and associative learning, when users have a vaguely defined information need. Whenever possible, use both types of schemes. Also, be aware of the challenges of organizing information on the Web. Language is ambiguous, content is heterogeneous, people have different perspectives, and politics can rear its ugly head. Providing multiple ways to access the same information can help to deal with all of these challenges.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Just wait, Gretel, until the moon rises, and then we shall see the crumbs of bread which I have strewn about, they will show us our way home again.

—Hansel and Gretel

As our fairy tales suggest, getting lost is often a bad thing. It is associated with confusion, frustration, anger, and fear. In response to this danger, we have developed navigation tools to prevent people from getting lost. From bread crumbs to compass and astrolabe to maps, street signs, and global positioning systems, people have demonstrated great ingenuity in the design and use of navigation tools.

We use them to chart our course, to determine our position, and to find our way back. They provide a sense of context and comfort as we explore new places. Anyone who has driven through an unfamiliar city as darkness falls understands the importance that navigation tools play in our lives.

On the Web, navigation is rarely a life or death issue. However, getting lost in a large web site can be confusing and frustrating. While a well-designed hierarchical organization scheme will reduce the likelihood that users will become lost, a complementary navigation system is often needed to provide context and to allow for greater flexibility of movement within the site.

Navigation systems can be designed to support associative learning by featuring resources that are related to the content currently being displayed. For example, a page that describes a product may include see also links to related products and services (this type of navigation can also support a company's marketing goals). As users move through a well-designed navigation system, they learn about products, services, or topics associated to the specific content they set out to find.

Any page on a web site may have numerous opportunities for interesting see also connections to other areas of the site. The constant challenge in navigation system design is to balance this flexibility of movement with the danger of overwhelming the user with too many options.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

When designing a navigation system, it is important to consider the environment the system will exist in. On the Web, people use web browsers such as Netscape Navigator and Microsoft Internet Explorer to move around and view web sites. These browsers sport many built-in navigation features.

Open URL allows direct access to any page on a web site. Back and Forward provide a bidirectional backtracking capability. The History menu allows random access to pages visited during the current session, and Bookmark enables users to save the location of specific pages for future reference. Web browsers also go beyond the Back button to support a "bread crumbs" feature by color-coding hypertext links. By default, unvisited hypertext links are one color and visited hypertext links are another. This feature helps users understand where they have and haven't been and can help them to retrace their steps through a web site.

Finally, web browsers allow for a prospective view that can influence how users navigate. As the user passes the cursor over a hypertext link, the destination URL appears at the bottom of the browser window, ideally hinting about the nature of that content (see Figure 4.1). If files and directories have been carefully labeled, prospective view gives the user context within the content hierarchy. If the hypertext link leads to another web site on another server, prospective view provides the user with basic information about this off-site destination.

Figure 4.1: In this example, the cursor is positioned over the Investor Info button. The prospective view window at the bottom shows the URL of the Investor Info page.

Much research, analysis, and testing has been invested in the design of these browser-based navigation features. However, it is remarkable how frequently site designers unwittingly override or corrupt these navigation features. For example, designers often modify the unvisited and visited link colors with no consideration for the bread crumbs feature. They focus on aesthetics, attempting to match link colors with logo colors. It's common to see a complete reversal of the blue and purple standard. This is a classic sacrifice of usability for aesthetics and belies a lack of consideration for the user and the environment. It's like putting up a green stop sign at a road intersection because it matches the color of a nearby building.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

With all navigation systems, before we can plot our course, we must locate our position. Whether we're visiting Yellowstone National Park or the Mall of America, the You Are Here mark on fixed-location maps is a familiar and valuable tool. Without that landmark, we must struggle to triangulate our current position using less dependable features such as street signs or nearby stores. The You Are Here indicator can make all the difference between knowing where you stand and feeling completely lost.

In designing complex web sites, it is particularly important to provide context within the greater whole. Many contextual clues in the physical world do not exist on the Web. There are no natural landmarks and no north and south. Unlike physical travel, hypertextual navigation allows users to be transported right into the middle of a large unfamiliar web site. Links from remote web pages and search engine result pages allow users to completely bypass the front door or main page of the web site. To further complicate matters, people often print web pages to read later or to pass along to a colleague, resulting in even more loss of context.

You should always follow a few rules of thumb to ensure that your sites provide contextual clues. First, all pages should include the organization's name. This might be done as part of the title or header of the page. As a user moves through the levels of a site, it should be clear that they are still within that site. Carrying the graphic identity throughout the site supports such context and consistency. In addition, if a user bypasses the front door and directly accesses a subsidiary page of the site, it should be clear which site he or she is on.

Second, the navigation system should present the structure of the information hierarchy in a clear and consistent manner and indicate the location within that hierarchy. See Figure 4.2 for an example.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

As discussed in the previous chapter, hierarchy is a familiar and powerful way of organizing information. In many cases, it makes sense for a hierarchy to form the foundation for organizing content in a web site. However, hierarchies can be fairly limiting from a navigation perspective. If you have ever used the ancient information browsing technology and precursor to the World Wide Web known as Gopher, you will understand the limitations of hierarchical navigation. In Gopherspace, you were forced to move up and down the tree structures of content hierarchies (see Figure 4.3). It was not practical to encourage or even allow jumps across branches (lateral navigation) or between multiple levels (vertical navigation) of a hierarchy.

Figure 4.3: On a Gopher site, you could only move up or down through the tree structure of the hierarchy.

The Web's hypertextual capabilities removed these limitations, allowing tremendous freedom of navigation. Hypertext supports both lateral and vertical navigation (see Figure 4.4). From any branch of the hierarchy, it is possible and often desirable to allow users to laterally move into other branches. For example, as you explore the Programs and Events section of a conference web site, you may decide to register for that conference. A hypertext link should allow you to jump to Registration without first retracing your steps back up the Programs and Events hierarchy.

Figure 4.4: In a hypertext system, navigation links can completely bypass the hierarchy. You can enable users to get anywhere from anywhere. However, as you can see from this diagram, things can get confusing pretty quickly. It begins to look like an architecture from M.C. Escher.

It is also possible and often desirable to allow users to move vertically from one level in a branch to a higher level in that same branch (e.g., from a specific Program back to the main Programs and Events page) or all the way back to the main page of the web site.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

A complex web site often includes several types of navigation systems. To design a successful site, it is essential to understand the types of systems and how they work together to provide flexibility and context.

Although we may not typically think of it this way, the information hierarchy is the primary navigation system. From the main page to the destination pages that house the actual content, the main options on each page are taken directly from the hierarchy (see Figure 4.5). As noted earlier, the hierarchy is extremely important, but also rather limiting. It is these limitations that often require additional navigation systems.

Figure 4.5: Global Navigation Systems

A global or site-wide navigation system often complements the information hierarchy by enabling greater vertical and lateral movement throughout the entire site. At the heart of most global navigation systems are some standard rules that dictate the implementation of the system at each level of the site.

The simplest global navigation system might consist of a graphical navigation bar at the bottom of each page on the site. On the main page, the bar might be unnecessary, since it would duplicate the primary options already listed on that page. On second level pages, the bar might include a link back to the home page and a link to the feedback facility, as in Figure 4.6.

Figure 4.6: The MVAC Web site employs a very simple, icon-based global navigation system.

A slightly more complex global navigation system may provide for area-specific links on third level pages and below. For example, if a user explores the products area of the web site, the navigation bar could include

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In global and local navigation systems, the most common and important navigation elements are those that are integrated into the content-bearing pages of the web site. As users move through the site or sub-site, these are the elements they see and use again and again. Most integrated navigation elements fit into one of two categories: navigation bars and pull-down menus.

You can implement navigation bars in many ways and use them for the hierarchical, global, and local navigation systems. In simplest form, a navigation bar is a collection of hypertext links grouped together on a page. Alternatively, the navigation bar may be graphical in nature, implemented as an image map or as graphic images within a table structure.

The decision to use text versus graphic navigation bars falls primarily within the realms of graphic design and technical performance rather than information architecture. Graphic navigation bars tend to look nicer but can significantly slow down the page loading speed (although, if you're able to reuse the same global navigation bar throughout the site, loading speed will only be hurt once, since the image will be cached locally). If you do use graphic navigation bars, you need to be sensitive to the needs of users with low bandwidth connections. You should also consider those users with text-only browsers (there are still quite a few out there) and those users with high-end browsers who turn off the graphical capabilities to get around more quickly. Appropriate use of the <ALT> attribute to define replacement text for the image will ensure that your site supports navigation for these users.

However, key issues related to the architecture should also influence this decision. For example, it is usually much easier to add options to a text menu than a graphic-based menu. If you anticipate substantial growth or change in a particular area, it may make sense to employ a textual navigation bar, like the one in Figure 4.10. Cost is also an issue, since graphic navigation bars require more work to create and change than text-based bars. In many cases, you might employ a graphic bar for global navigation and a textual menu for local navigation. A good graphic designer will strike an elegant balance between form and function in creating these navigation bars.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Remote navigation elements or supplemental navigation systems such as tables of contents, indexes, and site maps are external to the basic hierarchy of a web site and provide an alternative bird's-eye view of the site's content. Increasingly, we are seeing these remote navigation elements displayed outside of the main browser window, in either a separate target window or in a Java-based remote control panel. While remote navigation elements can enhance access to web site content by providing complementary ways of navigating, they should not be used as replacements or bandages for poor organization and navigation systems. In many ways, remote navigation elements are similar to software documentation or help systems. Documentation can be very useful but will never save a bad product. Instead, remote navigation elements should be used to complement a solid internal organization and navigation system. You should provide them but never rely on them.

The table of contents and the index are the state of the art in print navigation. Given that the design of these familiar systems is the result of testing and refinement over the centuries, we should not overlook their value for web sites.

In a book or magazine, the table of contents presents the top few levels of the information hierarchy. It shows the organization structure for the printed work and supports random as well as linear access to the content through the use of chapter and page numbers. Similarly, the table of contents for a web site presents the top few levels of the hierarchy. It provides a broad view of the content in the site and facilitates random access to segmented portions of that content. A web-based table of contents can employ hypertext links to provide the user with direct access to pages of the site.

You should consider using a table of contents for web sites that lend themselves to hierarchical organization. If the architecture is not strongly hierarchical, it makes no sense to present the parent-child relationships implicit in a structured table of contents. You should also consider the web site's size when deciding whether to employ a table of contents. For a small site with only two or three hierarchical levels, a table of contents may be unnecessary.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Designing navigation systems that work well is challenging. You've got so many possible solutions to consider, and lots of sexy technologies such as pop-up menus and dynamic site maps can distract you from what's really important: building context, improving flexibility, and helping the user to find the information they need.

No single combination of navigation elements works for all web sites. One size does not fit all. Rather, you need to consider the specific goals, audience, and content for the project at hand, if you are to design the optimal solution.

However, there is a process that should guide you through the challenges of navigation system design. It begins with the hierarchy. As the primary navigation system, the hierarchy influences all other decisions. The choice of major categories at the highest levels of the web site will determine design of the global navigation system. Based on the hierarchy, you will be able to select key pages (or types of pages) that should be accessible from every other page on the web site. In turn, the global navigation system will determine design of the local and then ad hoc navigation systems. At each level of granularity, your design of the higher-order navigation system will influence decisions at the next level.

Once you've designed the integrated navigation system, you can consider the addition of one or more remote navigation elements. In most cases, you will need to choose between a table of contents, an index, and a site map. Is the hierarchy strong and clear? Then perhaps a table of contents makes sense. Does the hierarchy get in the way? Then you might consider an index. Does the information lend itself to visualization? If so, a site map may be appropriate. Is there a need to help new or prospective users to understand what they can do with the site? Then you might add a guided tour.

If the site is large and complex, you can employ two or more of these elements. A table of contents and an index can serve different users with varying needs. However, you must consider the potential user confusion caused by multiple options and the additional overhead required to design and maintain these navigation elements. As always, it's a delicate balancing act.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Labeling is a form of representation. Just as we use spoken words to represent thoughts, we use labels to represent larger chunks of information in our web sites. For example, Contact Us is a label that represents a chunk of information, including a contact name, an address, telephone, fax, email information, and maybe more. You cannot present all this information quickly and effectively on an already crowded page without overwhelming impatient users. Instead, we rely upon a label like Contact Us to trigger the right association in the user's mind without presenting all that stuff prominently. The user can then decide whether to click through or read on and get more contact information. So the goal of a label is to communicate information efficiently; that is, without taking up too much of a page's vertical space or a user's cognitive space.

Unlike the weather, no one ever talks about labeling (aside from a few deranged librarians and linguists), but everyone can do something about it. Web site designers and managers create labels for the site without even realizing it. Why? Because labeling is a natural outgrowth of creating organization and navigation systems that sites can't function without, and because labeling things comes very naturally to humans. It's too easy not to think about labeling. The point of this chapter is to get you to think about labeling before you dive in.

Pre-recorded or canned communications, including print, the Web, scripted radio, and TV, are very different from interactive real-time communications. When we talk with another person, we rely on constant user feedback to help us hone the way we get our message across. We subconsciously notice our conversation partner zoning out, getting ready to make their own point, or beginning to clench their fingers into an angry fist, so we immediately shift our style of communication, perhaps by raising our speaking volume, increasing our use of body language, changing a rhetorical tack, fleeing, etc.

Unfortunately, the Web isn't sufficiently interactive for us to know how well we're getting our message across. So, assuming we don't have extensive user testing budgets for our sites, we need to guess how the average user might best respond to our message and write it that way. "Tell 'em what you're going to tell 'em, tell 'em, and then tell 'em what you told 'em." This canned approach is completely contrary to real-time conversation, which is the way we're used to communicating. Therefore, as a form of pre-recorded communications, labeling is a great challenge for web developers.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Rock music lyrics were still pretty simple back in the early `60s. Even with folks like Little Richard screeching "A-wop-bop-a-loo-lop a-lop-bam-boo!" you could generally understand what the words meant. But the music matured so much so quickly during that decade that it soon supported the rise of a new pasttime: rock lyric interpretation. Serious brainpower was deployed to interpret what the heck it was that such lyrical giants as Bob Dylan, the Beatles, and Tiny Tim really meant.

But those innocent days of recreational head-scratching have given way to an era of abbreviated attention spans. Don't count on the Web maturing in the same way that rock music did; that is to say, web users are not likely to spend much time decoding what it was a web site designer really meant by labeling an item Info or Stuff.

Besides immeasurably affecting navigation, labeling influences your site's users in many other ways. The way you say or represent information in your site says a lot about you and your organization. If you've ever read an airline magazine, you're familiar with those ads for some educational cassette series that develops your vocabulary. "The words you use can make or break your business deals..." or something like that. This may sound silly and a bit overblown, but after visiting some purportedly professional organizations' sites that include such terms as Cool, Hot, and Stuff in their labels, you'll start to agree with those purveyors of vocabulary-improving cassettes. Your organization has probably mortgaged its future to create a professional graphic identity and presence in its industry. Poor, unprofessional labeling can betray that investment and destroy a user's confidence in an organization.

Labels can also expose an organization that, despite its best intentions, does not consider the importance of its customers' needs as important as its own goals. This is most common in web sites that use org-speak for their labels. You've probably seen such sites; their labels are crystal clear, obvious, and enlightening... as long as you're one of the .01 percent of the users who actually work for the sponsoring organization. A sure way to lose a sale is to label your site's product ordering system as an Order Processing and Fulfillment Facility. (Another way is to feature any label that includes the terms Total, Quality, and Management....)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

It's important to remember that labels, like organization and navigation systems, are systems in their own right. So it follows that labeling systems, like any other, require planning to succeed. To illustrate, let's compare two labeling systems:

Unplanned Labeling System

Faculty Skunkworks
Office for Instructional Technology 
K12 PDN Projects Web Page
Digital Libraries Project
Office of Technology Management
Extension Services
The New Media Center
Project 1999
Institute for Information Technology
English Composition Board
Technology Dissemination Office

Planned Labeling System

Arts & Humanities
Business & Employment
Communication
Computers & Information Technology
Education
Engineering
Environment
Government & Law
Health & Medicine
Places & Peoples
Recreation
Science & Mathematics
Social Sciences & Social Issues

What is the difference between these two labeling systems?

If you were a first-time visitor, you'd have little sense of what the labels in the Unplanned System represent. They were created with the assumption that users would know these programs and acronyms. We can assume that this site deals with something academic, because of the labels Faculty, English Composition, and so forth. The list does seem somewhat consistent, as it includes many terms that seem to represent organizational units, such as Office, Services, Board, Project, and Institute. However, some terms are confounding, such as K12 PDN Web Page, Project 1999, Faculty Skunkworks, and The New Media Center. It's not clear if these represent web sites, organizational units, or something else altogether. So we scratch our heads and wonder what this is all about.

The Planned System, without context, might also make us wonder. What resources do these subjects cover? But at least we're clear that these indeed are subject areas. Also, the lack of exceptions indicates comprehensiveness: each is a subject area, so all possible subjects must be covered here. This is a useful trick: although there is no proof that this list is indeed comprehensive, users will often assume that consistent, systematic labeling systems do in fact cover the full extent of the domain that they represent. Most importantly, users have seen this type of system before, so the user only needs to learn the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In web sites, labels come in two formats, textual and iconic. We typically find them used in two ways: as links to chunks of information on other pages (usually within the context of navigation systems, as index terms, or as labels for links), and as headings that break up and identify the chunks of information on the same page (much like the heading on this printed page). Of course, a single label can do double duty; for example, the link Contact Us could lead to a page that uses the title label Contact Us.

Navigation system labels demand consistent application more than any other type of labeling system. Navigation systems, as we described in Chapter 4, occur again and again within a web site. Just as users rely on navigational systems to be positioned on a page consistently and look the same throughout the site, they rely on their labels to work in a consistent, familiar way, as in Figure 5.1. Effectively applied labels are integral to building this sense of familiarity, so they'd better not change from page to page. That's why using the label Main, on one page, Main Page on another, and Home elsewhere will surely destroy the familiarity that the user needs when navigating a site.

Figure 5.1: The labels Interact, View, Browse, and Search are part of a site-wide navigation system. This labeling system uses consistent verb-based terminology.

Some conventions have emerged for navigation system labels. You should consider using these, as they are already familiar to most web users. Here is a non-exhaustive list:

Main, Main Page, Home, Home Page
Search, Find, Browse, Search/Browse, Site Map, Contents, Table of Contents, Index
Contact , Contact Us, Contact Webmaster, Feedback

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Successful labeling systems mirror the thinking and language of a site's users, not its owners. If you've done your homework and created a sound organizational system for your site, the labeling system should follow its lead. So, for example, the labeling system should be topical if the organization system is topical. But once you've established a general approach (e.g., topical, task-oriented), where should the actual labels, the words themselves, come from?

Section 5.4.1.1: The labels currently in place

Your web site already has labels by default. As you made some decisions during the course of the site's creation, you probably won't want to throw those labels out and start over. Instead, use them as a starting point for developing a complete labeling system, taking into consideration the decisions you made while creating the original system (if you can still remember them).

Capture the existing labels in a single document. To do so, you'll have to walk the entire site, either manually or automatically, to gather the labels. You might consider assembling them as a simple label table. Here's an example:

Page Title (rendered as a graphic at top of page)	Page Title (rendered with <TITLE> tags)	URL	Headings on Page
Argus Associates, Inc.	Argus Associates, Inc.	`http://www.argus-inc.com/`

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The list of terms you are working with might be raw, coming straight from the content in your site, your site's users, or your own ideas of what should work best. Or, it may come straight from a polished controlled vocabulary. In either case, it'll need some work to become an effective labeling system.

First, sort the list of terms alphabetically. If it's a long list (e.g., indexing labels), you might see some duplicates; remove these.

Then review the list for consistency of usage, punctuation, letter case, and so forth. For example, you'll remember that the label table drawn from the Argus web site had inconsistencies that became obvious right away. Sometimes we used periods after labels, sometimes we didn't. We also weren't consistent in our usage of link labels vs. the heading labels on the pages they referred to.

You might also find that the writing style varies too much from label to label. For example, one label might use an active verb (e.g., Order a Free Sample from Larry's Reptile Hut) while another may use more passive language (e.g., Larry's Reptile Hut Customer Service). This is a good time to resolve these inconsistencies and perhaps to establish conventions for usage in terms of punctuation, language, and so on.

Some terms will undoubtedly be synonyms (e.g., cancer and oncology), others will be variants on the same term (e.g., microfiltration systems and microfiltration services), and some will be related but not quite the same (e.g., stationery and letterhead). You'll need to make some tough decisions here. With synonyms, choose the term that best fits the language of your site's users. So, if they're medical professionals, use the medical term oncology rather than the more generic term cancer. If you encounter variants or synonyms, ask yourself if they are different or part of the same general concept. For example, do microfiltration systems and microfiltration services

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

This chapter emphasizes the need for labels to be familiar for users, and also that consistency and representation are the foundations for building that familiarity. Now that we have belabored that point, we'll counter it with another: labeling systems should not necessarily be representational.

What? Would you make up your mind already?

Well, let's put it this way: non-representational labeling is not something that we'd recommend using regularly. In fact, it's difficult to determine when it should be applied. Following are two examples where we think it succeeds.

Head-scratching is usually a Bad Thing. It means that some aspect of a site has confused a user and is in the way of achieving the site's main goal, namely, conveying a message. But, like everything else, even cognitive confusion has a good side: Mystery.

Consider the main page shown in Figure 5.11. What the heck is going on here? If you come to this site, you may already have a little context, knowing in advance that it's a personal site. If not, you might figure this out fairly quickly, as this text uses the first person and seems to describe a personal quest. Beyond that, this page tells nothing about what you'll find in this site.

Figure 5.11: Is it obvious where these links lead you?

But you might want to know more. The radical aspect of this page involves its use of two brief sentences and five highly generic terms as labels to draw the user into a very personal experience. The labels are almost completely non-representational, and even in context they make you wonder and want to learn more.

If these link labels were accompanied by more information, such as scope notes, the effect would probably be lost:

Label

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·

Table of Contents

Section 1.2.1.1: Can't find it

Section 1.2.1.2: Poor graphic design and layout

Section 5.4.1.1: The labels currently in place