Previous Page
Next Page

7.6. Embedded Navigation Systems

Most large web sites include all three of the major embedded navigation systems we saw back in Figure 7-1. Global, local, and contextual navigation are extremely common on the Web. Each system solves specific problems and presents unique challenges. To design a successful site, it is essential to understand the nature of these systems and how they work together to provide context and flexibility.

7.6.1. Global (Site-Wide) Navigation Systems

By definition, a global navigation system is intended to be present on every page throughout a site. It is often implemented in the form of a navigation bar at the top of each page. These site-wide navigation systems allow direct access to key areas and functions, no matter where the user travels in the site's hierarchy.

Because global navigation bars are often the single consistent navigation element in the site, they have a huge impact on usability. Consequently, they should be subjected to intensive, iterative user-centered design and testing.

Global navigation bars come in all shapes and sizes. Consider the examples shown in Figure 7-7.

Figure 7-7. Global navigation bars from Dell, Apple, and Amazon

Most global navigation bars provide a link to the home page. Many provide a link to the search function. Some, like Apple's and Amazon's, reinforce the site's structure and provide contextual clues to identify the user's current location within the site. Others, like Dell's, have a simpler implementation and don't do either. This pushes the burden of providing context down to the local level and opens the door for inconsistency and disorientation. Global navigation system design forces difficult decisions that must be informed by user needs and by the organization's goals, content, technology, and culture. One size does not fit all.

It's often not possible to identify the global navigation system from the main page of a web site. The main page is sometimes the sole exception to the omnipresence of the global navigation bar. In some cases, designers choose to show an expanded view of the global navigation system on the main page. In other cases, the main page presents a variety of navigation options, and it's impossible to tell which ones have been carried throughout the site without exploring further.

This is the case with Microsoft's main page, as shown in Figure 7-8. There are three distinct navigation bars, and it's unclear whether any or all of them constitute a global navigation system. However, check out a few subsidiary pages, and it becomes obvious that only one is truly global. The other two are simply the designer's way of exposing important dimensions of the site's structure on the main page.

Figure 7-8. Microsoft's main page navigation

As Figure 7-9 shows, Microsoft's global navigation bar is very compact, and for good reason. This global navigation bar represents a massive investment in screen real estate, occupying a prominent position on several hundred thousand pages. These pages exist within dozens of subsites that are "owned" by powerful business units and functions within Microsoft.

Figure 7-9. Microsoft's global navigation bar

Despite convincing user-centered design arguments, it is still not easy to drive consistency throughout the subsites of modern, decentralized organizations. Most large enterprises are lucky if they can get the company logo and a simple global navigation bar implemented on 80 percent of their pages.

7.6.2. Local Navigation Systems

In many web sites, the global navigation system is complemented by one or more local navigation systems that enable users to explore the immediate area. Some tightly controlled sites integrate global and local navigation into a consistent, unified system. For example, the New York Times web site presents a global navigation bar that expands to provide local navigation options for each category of news. A reader who selects "Business" sees different local navigation options than a reader who selects "Sports," but both sets of options are presented within the same navigational framework (see Figure 7-10).

Figure 7-10. Local navigation at

In contrast, large sites like (Figure 7-11) often provide multiple local navigation systems that may have little in common with one another or with the global navigation system.

Figure 7-11. Local navigation at

These local navigation systems and the content to which they provide access are often so different that these local areas are referred to as subsites,[] or sites within sites. Subsites exist for two primary reasons. First, certain areas of content and functionality really do merit a unique navigation approach. Second, due to the decentralized nature of large organizations, different groups of people are often responsible for different content areas, and each group may decide to handle navigation differently.

[] The term subsite was coined by Jakob Nielsen in his 1996 article "The Rise of the Subsite" to describe a collection of web pages within a larger site that invite a common style and shared navigation mechanism unique to those pages. See

In Microsoft's case, it makes sense to provide different ways to navigate the Jobs Area, the Support Database, and the Product Catalog. These local navigation systems are aligned with user needs and the local content. Unfortunately, there are many bad examples on the Web where the variation between local navigation systems is simply a result of multiple design groups choosing to run in different directions. Many organizations are still struggling with the question of how much central control to exercise over the look and feel of their local navigation systems. Grappling with these local navigation issues can make global navigation systems look easy.

7.6.3. Contextual Navigation

Some relationships don't fit neatly into the structured categories of global and local navigation. This demands the creation of contextual navigation links specific to a particular page, document, or object. On an e-commerce site, these "See Also" links can point users to related products and services. On an educational site, they might point to similar articles or related topics.

In this way, contextual navigation supports associative learning. Users learn by exploring the relationships you define between items. They might learn about useful products they didn't know about, or become interested in a subject they'd never considered before. Contextual navigation allows you to create a web of connective tissue that benefits users and the organization.

The actual definition of these links is often more editorial than architectural. Typically an author, editor, or subject matter expert will determine appropriate links once the content is placed into the architectural framework of the web site. In practice, this usually involves representing words or phrases within sentences or paragraphs (i.e., prose) as embedded or "inline" hypertext links. A page from Stanford University's site, shown in Figure 7-12, provides an example of carefully chosen inline contextual navigation links.

Figure 7-12. Inline contextual navigation links

This approach can be problematic if these contextual links are critical to the content, since usability testing shows that users often tend to scan pages so quickly they miss or ignore these less conspicuous links. For this reason, you may want to design a system that provides a specific area of the page or a visual convention for contextual links. As you can see in Figure 7-13, REI designs contextual navigation links to related products into the layout of each page. Moderation is the primary rule of thumb for guiding the creation of these links. Used sparingly (as in this example), contextual links can complement the existing navigation systems by adding one more degree of flexibility. Used in excess, they can add clutter and confusion. Content authors have the option to replace or complement the embedded links with external links that are easier for the user to see.

Figure 7-13. External contextual navigation links

The approach used on each page should be determined by the nature and importance of the contextual links. For noncritical links provided as a point of interest, inline links can be a useful but unobtrusive solution.

When designing a contextual navigation system, imagine that every page on the site is a main page or portal in its own right. Once a user has identified a particular product or document, the rest of the site fades into the background. This page is now his interface. Where might he want to go from here? Consider the REI example. What additional information will the customer want before making a buying decision? What other products might he want to buy? Contextual navigation provides a real opportunity to cross-sell, up-sell, build brand, and provide customer value. Because these associative relationships are so important, we'll revisit this topic in Chapter 9.

7.6.4. Implementing Embedded Navigation

The constant challenge in navigation system design is to balance the flexibility of movement with the danger of overwhelming the user with too many options. One key to success is simply recognizing that global, local, and contextual navigation elements exist together on most pages (consider the representation of a web page shown in Figure 7-14). When integrated effectively, they can complement one another.

Figure 7-14. Navigation can drown out the content

But when designed independently, the three systems can combine to monopolize a great deal of screen real estate. Alone, they may each be manageable, but together on one page, the variety of options may overwhelm the user and drown out the content. In some cases, you may need to revisit the number of options within each navigation bar. In others, the problem may be minimized through careful design and layout.

In its simplest form, a navigation bar is a distinct collection of hypertext links that connect a series of pages, enabling movement among them. They can support global, local, and contextual navigation. You can implement navigation in all sorts of ways, using text or graphics, pull-downs, pop-ups, rollovers, cascading menus, and so on. Many of these implementation decisions fall primarily within the realms of interaction design and technical performance rather than information architecture, but let's trespass briefly and hit a few highlights.

For example, is it better to create textual or graphical navigation bars? Well, graphic navigation bars tend to look nicer, but can slow down the page-loading speed and are more expensive to design and maintain. If you use graphic navigation bars, you need to be sensitive to the needs of users with low bandwidth connections and text-only browsers. People who are blind and people using wireless mobile devices are two important audiences to consider. Appropriate use of the <ALT> attribute to define replacement text for the image will ensure that your site supports navigation for these users.

And where do the navigation bars belong on the page? It has become convention to place the global navigation bar along the top of the page and the local navigation bar along the lefthand side. However, all sorts of permutations can be successful. Just make sure you do lots of user testing, particularly if you deviate from convention.

What about textual labels versus icons? Textual labels are the easiest to create and most clearly indicate the contents of each option. Icons, on the other hand, are relatively difficult to create and are often ambiguous. It's difficult to represent abstract concepts through images. A picture may say a thousand words, but often they're the wrong wordsparticularly when you're communicating to a global audience.

Icons can successfully be used to complement the textual labels, however. Since repeat users may become so familiar with the icons that they no longer need to read the textual labels, icons can be useful in facilitating rapid menu selection. In Figure 7-15, Scott McCloud combines text and images to create a global navigation system that balances form and function. But can you guess what lies behind icons b through e? On this comic creator's web site, the mystery icons provoke curiosity and create a playful experience. On a business web site, they would simply be frustrating.

Figure 7-15. Navigation with integrated text and images

How about the increasingly common use of DHTML and JavaScript rollovers to show the navigation options behind a category or menu option (as shown in Figure 7-16)? Well, it depends. On one hand, this prospective view on steroids can make valuable use of limited screen real estate, enhancing the scent of information and often reducing the number of pages and clicks, while simultaneously adding a dynamic, interactive feel to the web site. On the other hand, rollover navigation can be difficult to do well. Usability and accessibility often suffer due to poor design and implementation. Also, the use of rollover navigation is no substitute for the careful selection of the omnipresent major categories and labels, which lend themselves to rapid visual scanning. You can't expect the user to "mine sweep" her mouse cursor over every option.

Figure 7-16. Audi's rollover navigation

And finally, what about frames? In the 1990s, designers went a little crazy with frames, implementing navigation bars and banner advertisements alike inside non-scrollable panes. We don't see too many frames these days, and that's a very good thing. Even beyond the technical design and performance problems, frames tend to cripple usability. After all, the Web is built upon a model of pages, each of which has a unique address or URL. Users are familiar with the concept of pages. Frames confuse this issue by slicing up pages into independent panes of content. By disrupting the page model, the use of frames frequently disables important browser navigation features such as bookmarking, visited and unvisited link discrimination, and history lists. Frames can also confuse users who are trying to perform simple tasks such as using the Back button, reloading a page, and printing a page. While web browsers have improved in their ability to handle frames, they can't remove the confusion caused by violating the page paradigm.

Previous Page
Next Page