Information Architecture Assignment

jeprej

Information_Architecture_For_the_Web_and_Beyond_----_Chapter_8._Navigation_Systems.pdf

Home >Information Systems homework help >Information Architecture Assignment

CHAPTER 8

Navigation Systems

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

In this chapter, we’ll cover:

• Balancing context and flexibility in web navigation • Integrating global, local, and contextual navigation • Supplemental navigation tools such as sitemaps, indexes, guides,

wizards, and configurators • Personalization, visualization, tag clouds, collaborative filtering,

and social navigation

As our fairy tales suggest, getting lost is a bad thing. It is associated with confusion, frustration, anger, and fear. In response to this dan‐ ger, humans have developed navigation tools to prevent us from get‐ ting lost and to help us find our way home. From breadcrumbs to compasses and astrolabes, to maps, street signs, and global position‐ ing systems, people have demonstrated great ingenuity in the design and use of navigation tools and wayfinding strategies.

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

175

Rosenfeld, Louis, et al. Information Architecture : For the Web and Beyond, O'Reilly Media, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/unt/detail.action?docID=4333758. Created from unt on 2023-02-19 06:01:03.

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

In digital information environments, navigation is rarely a life or death issue. However, getting lost in a large website can be confusing and frustrating. While a well-designed taxonomy may reduce the chances that users will become lost, complementary navigation tools are often needed to provide context and to allow for greater flexibil‐ ity. Structure and organization are about building rooms. Navigation design is about adding doors and windows.

In this book, we have split navigation and searching into individual chapters. This chapter focuses on navigation systems that support browsing; the next chapter digs deep into searching systems that are clearly components of navigation. In fact, structure, organization, labeling, browsing, and searching systems all contribute to effective navigation.

Before we dig in, we need to mention that the surface layer of navi‐ gation—that which users interact with—is changing very fast. In recent years, the proliferation of different device form factors has led designers and developers to come up with various strategies to deal with the wildly varying screen sizes and interaction mechanisms. The most popular of these strategies, responsive web design, is a subject for a book unto itself (many books, actually), so we won’t be covering it in depth here. Suffice it to say that we’ve striven to select examples that compare and contrast desktop and mobile navigation schemes, especially as they relate to IA.

Types of Navigation Systems Navigation systems are composed of several basic elements, or sub‐ systems. First, we have the global, local, and contextual navigation systems that are integrated within site pages or app screens. They may look and behave differently when rendered in desktop-class web browsers than in mobile apps, but in both cases they serve simi‐ lar purposes: they provide both context and flexibility, helping users understand where they are and where they can go. These three major systems, shown in typical desktop layouts in Figure 8-1, are generally necessary but not sufficient by themselves. (The need for global, local, and contextual navigation still exists in mobile envi‐ ronments. However, layouts tend to take different forms given the compromises imposed by the limited screen real estate in most mobile devices.)

176 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

Figure 8-1. Global, local, and contextual embedded navigation systems

Second, we have supplemental navigation systems such as sitemaps, indexes, and guides that exist outside the content-bearing pages. These are shown in Figure 8-2.

Figure 8-2. Supplemental navigation systems

Similar to search, these supplemental navigation systems provide different ways of accessing the same information. Sitemaps provide a bird’s-eye view of the information environment. A-to-Z indexes allow direct access to content. And guides often feature linear navi‐ gation customized to a specific audience, task, or topic.

As we’ll explain, each type of supplemental navigation system serves a unique purpose and is designed to fit within the broader frame‐ work of integrated searching and browsing systems.

Gray Matters The design of navigation systems takes us deep into the gray area between information architecture, interaction design, information

Gray Matters | 177

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

design, visual design, and usability engineering, all of which we might loosely classify under the umbrella of user experience design.

As soon as we start talking about global, local, and contextual navi‐ gation, we find ourselves on the slippery slope that connects strat‐ egy, structure, design, and implementation. Does the local navigation bar work best at the top of the page, or is it better run‐ ning down the left side? Should we use mega-menus or fat footers to reduce the required number of clicks? Will users ever notice gray links?

For better or for worse, we’re often drawn into these debates and are sometimes responsible for making these decisions. We could try to draw a clear line in the sand and argue that effective navigation is simply the manifestation of a well-organized system. Or we could abdicate responsibility and leave the interface to other designers.

But we won’t. In the real world, the boundaries are fuzzy and the lines get crossed every day, and the best solutions often result from the biggest debates. While not always possible, interdisciplinary col‐ laboration is the ideal, and collaboration works best when each of the experts understands something about the other areas of expertise.

So in this chapter, we roll up our sleeves, cross lines, step on toes, and get a little messy in the process. We tackle navigation design from the perspective of information architecture.

Browser Navigation Features When designing a navigation system, it is important to consider the environment in which the system will exist. On the Web, people use web browsers such as Google Chrome and Microsoft Internet Explorer to move around and view websites. On mobile devices, browsers such as Safari feature different ways of interacting with sites, including various touch gestures. These browsers sport many built-in navigation features.

Open URL allows direct access to any page on a website. Back and Forward provide a bidirectional backtracking capability. The His‐ tory menu allows access to pages visited in the past, and Bookmark or Favorites enables users to save the locations of specific pages for future reference. Although rarely used today, web browsers also sup‐

178 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

1 Modern operating systems have good guidelines for designing standard navigation mechanisms. See http://bit.ly/designing_for_ios, http://www.google.com/design/spec, and http://bit.ly/uwp_apps_guidelines.

2 For more on navigation, see James Kalbach’s Designing Web Navigation (Sebastopol, CA: O’Reilly, 2007).

port a “breadcrumbs” feature by color-coding hypertext links, a fea‐ ture that can help users to retrace their steps through a website.

Although less constrained (due in part to not having to conform to a page-based model), non-browser applications have their own navi‐ gation conventions. Different operating systems provide standard mechanisms that define how people get around inside apps. For example, most Mac OS X applications feature a menu bar with a standard organization scheme that includes the application name as the first menu item, and “File” and “Edit” menus as the second and third items, respectively (Figure 8-3).1

Figure 8-3. Most applications in Mac OS X feature a menu bar with a standard organization scheme

Much research, analysis, and testing has been invested in the design of these navigation features, and users expect them to work consis‐ tently. However, we are in a period of intense experimentation with regard to navigation mechanisms. Touch-based interfaces have made possible new ways of interacting with web content (e.g., pinching and swiping) and have obsoleted others (e.g., hovering to reveal multilevel menus). Because of the importance of navigation to the user’s experience of interacting with information environments, designers must be judicious when experimenting with new and untested navigation schemes.2

Placemaking As we mentioned in Chapter 4, transmitting a clear context—what the environment is, and what you can expect to find and do in it— makes information more easily understandable. Creating this sense of place through language and giving us clear paths to explore the environment are among the key roles navigation systems play.

Placemaking | 179

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

http://bit.ly/designing_for_ios

http://www.google.com/design/spec

http://bit.ly/uwp_apps_guidelines

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 a fixed- location map is a familiar and valuable tool. Without it, 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 be the difference between knowing where you stand and feeling completely lost.

When designing complex information environments, it is particu‐ larly important to provide context within the greater whole. Many contextual clues available in the physical world do not exist online. There are no natural landmarks, no north and south. Unlike physi‐ cal travel, hypertextual navigation allows users to be transported right into the middle of an unfamiliar system. For example, links from remote web pages and search engine results can allow users to completely bypass the main page of a website.

You should always follow a few rules of thumb to ensure that your design provides contextual clues. For example, users should always know which site or app they’re in, even if they bypass the front door and enter through a search engine or a link to a subsidiary page. Extending the organization’s name, logo, and graphic identity throughout is a fairly obvious way to accomplish this goal.

The navigation system should also present as much as possible of the structure of the information hierarchy in a clear and consistent manner, and indicate the user’s current location, as shown in Figure 8-4. Sears’s navigation system shows the user’s location within the hierarchy with a variation of the “You Are Here” sign near the top of the page. This helps users to build a mental model of the organization scheme, which facilitates navigation and helps them feel comfortable.

180 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

3 Keith Instone popularized the notion of a navigation stress test in his 1997 article, “Stress Test Your Site”.

Figure 8-4. Sears’s navigation system shows the user’s location within the hierarchy

If you have an existing website, we suggest running a few users through a navigation stress test.3 Here are the basic steps as outlined by Keith Instone:

1. Ignore the home page and jump directly into the middle of the site.

2. For each random page, can you figure out where you are in rela‐ tion to the rest of the site? What major section are you in? What is the parent page?

3. Can you tell where the page will lead you next? Are the links descriptive enough to give you a clue what each is about? Are the links different enough to help you choose one over another, depending on what you want to do?

By parachuting deep into the middle of the site, you will be able to push the limits of the navigation system and identify any opportuni‐ ties for improvement.

Placemaking | 181

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

http://instone.org/navstress

4 If you’re too young to remember Gopher, consider the category/subcategory navigation of the iOS Music app instead.

Improving Flexibility As we explained in Chapter 6, 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 limiting from a navigation per‐ spective. 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 naviga‐ tion.4 In Gopherspace, you were forced to move up and down the tree structures of content hierarchies (see Figure 8-5). It was imprac‐ tical to encourage or even allow jumps across branches (lateral navi‐ gation) or between multiple levels (vertical navigation) of a hierarchy.

Figure 8-5. The pure hierarchy of Gopherspace

The Web’s hypertextual capabilities removed these limitations, allowing tremendous freedom of navigation. Hypertext supports both lateral and vertical navigation. From any branch of the hierar‐ chy, it is possible and often desirable to allow users to move laterally into other branches, to move vertically from one level to a higher or lower level in that same branch, or to move all the way back to the main page of the website. If the system is so enabled, users can get to anywhere from anywhere. However, as you can see in Figure 8-6, things can get confusing pretty quickly. It begins to look like an architecture designed by M.C. Escher.

182 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

Figure 8-6. A hypertextual web can completely bypass the hierarchy

The trick to designing navigation systems is to balance the advan‐ tages of flexibility with the dangers of clutter. In a large, complex information environment, a complete lack of lateral and vertical navigation aids can be very limiting. On the other hand, too many navigation aids can bury the hierarchy and overwhelm the user. Navigation systems should be designed with care to complement and reinforce the hierarchy by providing added context and flexibility.

Embedded Navigation Systems Most large information environments include all three of the major embedded navigation systems we saw back in Figure 8-1. Global, local, and contextual navigation are extremely common in desktop- oriented websites. They are also present in mobile sites, but take dif‐ ferent forms than those shown here due to the constraints presented by smaller screens. Each system solves specific problems and presents unique challenges. To design a successful environment, it is essential to understand the nature of these systems and how they work together to provide context and flexibility.

Global 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 naviga‐ tion systems allow direct access to key areas and functions, no mat‐ ter where the user travels in the site’s hierarchy.

Embedded Navigation Systems | 183

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

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

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

Most global navigation bars provide a link to the home page, usually represented as the organization’s logo. Many provide a link to the search function. Some, like Apple’s and Acer’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 imple‐ mentation 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 organiza‐ tion’s goals, content, technology, and culture. One size does not fit all.

Global navigation bars are constantly evolving. For example, in recent years mega-menus and fat footers have become common design patterns for rendering global navigation structures in web‐ sites. Mega-menus are like traditional drop-down menus: usually rendered at the top of a page, they provide access to second- and third-level elements when the user clicks on a first-level element. However, mega-menus are much richer than the simple lists of links of yesteryear; they often feature sophisticated typographic layouts, images, and other cues to give the user insight into the content and structure of the system (Figure 8-8).

184 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

Figure 8-8. Adidas’s mega-menus give insights into the content and structure of the site

Fat footers are abridged sitemaps rendered at the bottom of web pages. They provide direct access to the most important sections of the site (Figure 8-9).

Embedded Navigation Systems | 185

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

Figure 8-9. Microsoft.com is a large site, with multiple subsites and sub-brands; a fat footer on many of the site’s pages gives users a consis‐ tent way to get around

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

Local Navigation Systems On many websites, 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 USA Today website presents a global navigation bar that shows local navigation options for each category of news. A reader who selects “Money” sees different local navigation options than a reader who selects “Life,” but both sets of options are presented within the same navigational framework (see Figure 8-10).

186 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

5 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.

Figure 8-10. Local navigation at usatoday.com

In contrast, large sites like GE.com (Figure 8-11) often provide mul‐ tiple local navigation systems that may have little in common with one another or with the global navigation system.

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

Embedded Navigation Systems | 187

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

http://www.useit.com/alertbox/9609.html

Figure 8-11. Local navigation at GE.com

In GE’s case, the local navigation systems seem 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 creaeting global navigation systems look easy.

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. In online stores, these “see also” links can point users to related prod‐ ucts 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.

188 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

They might learn about useful products they didn’t know about, or become interested in a subject they’d never considered before. Con‐ textual 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 website. In practice, this usually involves representing words or phrases within sentences or para‐ graphs (i.e., prose) as embedded or “inline” hypertext links. A page from Stanford University’s site, shown in Figure 8-12, provides an example of carefully chosen inline contextual navigation links.

Figure 8-12. Inline contextual navigation links

This approach can be problematic if these contextual links are criti‐ cal to the content, because usability testing shows that users often tend to scan pages so quickly that they miss or ignore these less con‐ spicuous 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 8-13, Adorama includes contextual navigation links to related products—in this case based on user views—in the layout of each page. Moderation is the pri‐ mary rule of thumb for guiding the creation of these links. Used sparingly (as in this example), contextual links can complement the

Embedded Navigation Systems | 189

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

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 8-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 unob‐ trusive 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 Adorama example. What additional information will the customer want before making a buying decision? What other products might he want to buy? Con‐ textual navigation provides a real opportunity to cross-sell, up-sell, build brand, and provide customer value. In mobile environments, contextual navigation links can tap into device capabilities to take different actions (e.g., make a call, play a song.) Because these asso‐

190 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

ciative relationships are so important, we’ll revisit this topic in Chapter 10.

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 in websites and in many content-driven apps as well. When integrated effectively, they can complement one another. 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 (consider the repre‐ sentation of a web page shown in Figure 8-14). 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.

Figure 8-14. Navigation can drown out the content

In its simplest form, a navigation bar is a distinct collection of links that connect a series of sections in the system, enabling movement among them. They can support global, local, and contextual naviga‐ tion. You can implement navigation in all sorts of ways, using text or graphics, pull-downs, pop-ups, rollovers, mega-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? It is a matter of trade-offs: in desktop-class web browsers,

Embedded Navigation Systems | 191

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

which have the luxury of space, text labels are the norm because they tend to be clearer, easier to implement, and more easily accessi‐ ble. However, in situations where screen real estate is at a premium, such as in mobile apps, iconic representations of navigation options may be a better choice.

And where do navigation bars belong on the page? Again, the answer depends on the context in which the bars will be rendered. In web pages targeting desktop browsers, the convention is to place global navigation bars somewhere at the top of pages, with local navigation structures arranged alongside the main content. In mobile web pages, navigation bars are often hidden offscreen on either the left or right side of the content; they are exposed using a menu button along the top of the screen. In mobile apps, primary navigation bars are often rendered at the bottom of the screen, within easy reach of the user’s thumbs (Figure 8-15).

Figure 8-15. The global navigation bar on ESPN’s iPhone app consists of a row of icons, aligned at the bottom of the screen; the app includes an extensive icon vocabulary to represent different sports leagues

192 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

In any case, you need to be aware of the conventions and limitations of the medium you are designing for. Any deviation from the norm should be tested with users before release.

Supplemental Navigation Systems Supplemental navigation systems (shown back in Figure 8-2) include sitemaps, indexes, and guides. These are external to the basic hierarchy of a website and provide complementary ways of finding content and completing tasks. Search also belongs to the supplemental navigation family, but it’s so important that we’ve dedicated all of Chapter 9 to it.

Supplemental navigation systems can be critical factors for ensuring usability and findability within large information systems. However, they’re often not given the care and feeding they deserve. Some product owners still labor under the misconception that if they could only get the taxonomy right, all users and all user needs would be addressed. Usability pundits feed this fantasy by preaching the gospel of simplicity: users don’t want to make choices, and they resort to sitemaps, indexes, guides, and search only when the taxon‐ omy fails them.

Both statements are theoretically true but miss the point that the taxonomy and the embedded navigation systems will always fail for a significant percentage of users and tasks. You can count on this like death and taxes. Supplemental navigation systems give users an emergency backup. Do you really want to drive without a seatbelt?

Sitemaps In a book or magazine, the table of contents presents the top few levels of the information hierarchy. It shows the organization struc‐ ture for the printed work and supports random as well as linear access to the content through the use of chapter and page numbers. In contrast, a place map helps us navigate through physical space, whether we’re driving through a network of streets and highways or trying to find our terminal in a busy airport.

In the early days of the Web, the terms “sitemap” and “table of con‐ tents” were used interchangeably. Of course, librarians thought the TOC was a better metaphor, but sitemap sounds sexier and less hier‐ archical, so it has become the de facto standard.

Supplemental Navigation Systems | 193

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

A typical sitemap (Figure 8-16) presents the top few levels of the information hierarchy. It provides a broad view of the content in the system and facilitates random access to segmented portions of that content via graphical or text-based links.

Figure 8-16. Apple’s sitemap

A sitemap is most natural for large systems that lend themselves to hierarchical organization. If the architecture is not strongly hier‐ archical, an index or alternate visual representation may be better. You should also consider the system’s size when deciding whether to employ a sitemap. For a small information environment with only two or three hierarchical levels, a sitemap may be unnecessary.

The design of a sitemap significantly affects its usability. When working with a graphic designer, make sure she understands the fol‐ lowing rules of thumb:

• Reinforce the information hierarchy so the user becomes increasingly familiar with how the content is organized.

• Facilitate fast, direct access to the contents of the site for those users who know what they want.

194 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

• Avoid overwhelming the user with too much information. The goal is to help, not scare, the user.

Finally, it’s worth noting that sitemaps are also useful from a search engine optimization perspective, because they point search engine spiders directly to important pages throughout the website.

Indexes Similar to the back-of-book index found in many print materials, a digital index presents keywords or phrases alphabetically, without representing the hierarchy. Unlike a table of contents, indexes are relatively flat, presenting only one or two levels of depth. Therefore, indexes work well for users who already know the name of the item they are looking for. A quick scan of the alphabetical listing will get them where they want to go; there’s no need for them to understand where you’ve placed that item within your hierarchy. In Figure 8-17, The United Nations website presents a comprehensive alphabetical index. Handcrafted links within the index lead directly to destina‐ tion pages.

Figure 8-17. The UN’s comprehensive alphabetical site index

Supplemental Navigation Systems | 195

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

Large, complex websites often require both a sitemap and a site index (and a search capability, for that matter). The sitemap reinfor‐ ces the hierarchy and encourages exploration, while the site index bypasses the hierarchy and facilitates known-item finding. Com‐ cast’s XFINITY website presents a simple site index alongside a site‐ map that mirrors the site’s navigation structure (Figure 8-18).

Figure 8-18. Comcast’s XFINITY site index

A major challenge in indexing a website involves the level of granu‐ larity. Do you index web pages? Do you index individual paragraphs or concepts that are presented on web pages? Or do you index col‐ lections of web pages? In many cases, the answer may be all of the above. Perhaps a more valuable question is: what terms are users going to look for? The answers should guide the index design. To find those answers, you need to know your audience and under‐ stand their needs. You can learn more about the terms people will look for by analyzing search logs and conducting user research.

There are two very different ways to create an index. For small sys‐ tems, you can simply create the index manually, using your knowl‐ edge of the full collection of content to inform decisions about which links to include. This centralized, manual approach results in a one-step index such as the one in Figure 8-18. Another example is shown in Figure 8-19, where the Centers for Disease Control and Prevention two-step site index features term rotation and

196 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

6 This is clever work by the late, great Rich Wiggins, whose presence is felt in this book years after his passing.

see/see-also references. Yet another interesting example is Michigan State University’s site index, shown in Figure 8-20, which takes hun‐ dreds of the site’s best bet results and renders them as an alphabeti‐ cal list.6

Figure 8-19. The Center for Disease Control and Prevention’s site index

In contrast, on a large site with distributed content management, it may make sense to use controlled vocabulary indexing at the docu‐ ment level to drive automatic generation of the site index. Because many controlled vocabulary terms will be applied to more than one document, this type of index must allow for a two-step process: the user first selects the term from the index, and then selects from a list of documents indexed with that term.

Supplemental Navigation Systems | 197

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

Figure 8-20. Michigan State University’s site index

A useful trick in designing an index involves term rotation, also known as permutation. A permuted index rotates the words in a phrase so that users can find the phrase in two places in the alpha‐ betical sequence. For example, in the CDC index, users will find list‐ ings for both “Abuse, Elder” and “Elder Maltreatment.” This supports the varied ways in which people look for information. Term rotation should be applied selectively. You need to balance the probability of users seeking a particular term with the annoyance of cluttering the index with too many permutations. For example, it would probably not make sense in an event calendar to present “Sunday (Schedule)” as well as “Schedule (Sunday).” If you have the time and budget to conduct focus groups or user testing, that’s great. If not, you’ll have to fall back on common sense.

Guides Guides can take several forms, including guided tours, tutorials, and walk-throughs focused around a specific audience, topic, or task. In each case, guides supplement the existing means of navigating and understanding the system’s content and functionality.

Guides often serve as useful tools for introducing new users to the content and functionality of a website. They can also be valuable

198 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

marketing tools for restricted-access systems (such as services that charge subscription fees), enabling you to show potential customers what they will get for their money. And, they can be valuable inter‐ nally, providing an opportunity to showcase key features of a rede‐ signed site to colleagues, managers, and venture capitalists.

Guides typically feature linear navigation (new users want to be gui‐ ded, not thrown in), but hypertextual navigation should also be available to provide additional flexibility. Screenshots of major pages should be combined with narrative text that explains what can be found in each area.

The IRS Withholding Calculator, shown in Figure 8-21, provides an example: it consists of a highly editorialized selection of important links wrapped in helpful (and clearly structured) copy.

Figure 8-21. The introduction to the IRS Withholding Calculator

Rules of thumb for designing guides include:

• The guide should be short. • At any point, the user should be able to exit the guide. • Navigation (Previous, Home, Next, swiping gestures) should be

consistent so that users can easily step back and forth through the guide.

Supplemental Navigation Systems | 199

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

• The guide should be designed to answer questions. • Screenshots should be crisp, clear, and optimized, with enlarged

details of key features. • If the guide includes more than a few pages, it may need its own

table of contents.

Remember that a guide is intended as an introduction for new users and as a marketing opportunity for the product or service. Many people may never use it, and few people will use it more than once. You should balance the inevitable big ideas about how to create an exciting, dynamic, interactive guide with the fact that it will not play a central role in the day-to-day use of the system.

Configurators Though they could be considered a special class of guide, wizards that help users to configure products or navigate complex decision trees deserve separate highlighting. Sophisticated configurators, like Motorola’s Moto Maker, shown in Figure 8-22, allow the user to easily traverse complicated decision-making processes.

Figure 8-22. The Moto Maker configurator

Moto Maker successfully combines a rich suite of navigation options without causing confusion. The user can move through a linear pro‐

200 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

cess or jump back and forth between steps, and the site’s global navi‐ gation is always present, providing context and possible next steps.

Often, users don’t have a clear understanding of the impact of the choices that affect the configuration process. It is desirable to pro‐ vide them with contextual clues that help them make sense of the various options available. For example, the iOS Apple Store applica‐ tion (Figure 8-23) includes product images that show changes to the product based on the user’s selected color finish, and includes text that explains the impact of more technical options on the product.

Figure 8-23. The iOS Apple Store application on the iPad

Search As we noted earlier, the searching system is a central part of supple‐ mental navigation. Search is a favorite tool of users because it puts them in the driver’s seat, allowing them to use their own keyword terms to look for information. Search also enables a tremendous level of specificity. Users can search the content for a particular phrase (e.g., “socially translucent systems failure”) that is unlikely to be represented in a sitemap or site index.

However, the ambiguity of language causes huge problems with most search experiences. Users, authors, and information architects all use different words for the same things. Because the design of

Supplemental Navigation Systems | 201

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

effective search systems is so important and so complex, we’ve devo‐ ted an entire chapter to the topic (Chapter 9).

Advanced Navigation Approaches So far, we’ve focused attention on the bread-and-butter components of navigation systems: the elements that form the foundation of use‐ ful, usable websites. Good navigation design is really important and really hard. Only after you’ve mastered the integration of these fun‐ damental building blocks should you dare to wander into the mine‐ field of advanced navigation.

Personalization and Customization Personalization involves serving up information to the user based upon a model of the behavior, needs, or preferences of that individ‐ ual. In contrast, customization involves giving the user direct control over some combination of presentation, navigation, and content options. In short, with personalization, we guess what the user wants, and with customization, the user tells us what he wants.

Both personalization and customization can be used to refine or supplement existing navigation systems. Unfortunately, however, both have been hyped by consultants and software vendors as the solution to all navigation problems. The reality is that personaliza‐ tion and customization:

• Typically play important but limited roles • Require a solid foundation of structure and organization • Are really difficult to do well • Can make it more difficult to collect metrics and analyze user

behavior

Amazon is the most cited example of successful personalization, and some of the things it’s done are truly valuable. It’s nice that Amazon remembers our names, and it’s great that it remembers our address and credit card information. It’s when Amazon starts trying to rec‐ ommend products based on past purchases that the system breaks down (see Figure 8-24). In this example, Jorge already owns two of the top five recommended books, but the system doesn’t know this because he purchased them elsewhere and (obviously) not as Kindle books. And this ignorance is not the exception, but the rule. Because

202 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

we don’t have time to teach our systems, or because we prefer to maintain our privacy, we often don’t share enough information to drive effective personalization. In addition, in many cases, it’s really hard to guess what people will want to do or learn or buy tomorrow. As they say in the financial world, past performance is no guarantee of future results. In short, personalization works really well in limi‐ ted contexts, but fails when you try to expand it to drive the entire user experience.

Figure 8-24. Amazon’s personalized recommendations

Customization introduces a similar set of promises and perils. The idea of giving users control and thereby alleviating some of the pres‐ sures on design is obviously very compelling. And customization can sometimes deliver great value. For example, Gmail allows the user to set the visibility and order of labels—a critical element in the structuring of the user’s mail in the system—by dragging and drop‐ ping them within a global navigation structure (Figure 8-25).

The problem with customization is that most people don’t want to spend much (if any) time customizing, and will do this work only on a small handful of sites that are most important to them. Because corporate intranets have a captive audience of repeat visitors, cus‐ tomization has a much better chance of being used there than it does on most public websites.

Advanced Navigation Approaches | 203

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

Figure 8-25. Customization in Gmail

However, there’s another problem. Even users themselves don’t always know what they will want to know or do tomorrow. Custom‐ ization works great for tracking the sports scores of your favorite baseball team or monitoring the value of stocks you own, but not so well when it comes to broader news and research needs. One day you want to know the results of the French elections; the next day you want to know when dogs were first domesticated. Do you really know what you might need next month?

204 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

Visualization Since the advent of the Web, people have struggled to create useful tools that enable users to navigate in a more visual way. First came the metaphor-driven attempts to display online museums, libraries, shopping malls, and other websites as physical places. Then came the dynamic, fly-through “sitemaps” that tried to show relationships between pages on a website. Both looked very cool and stretched our imaginations, but neither proved to be very useful. Visualization has proven most useful when the user must select among a result set of elements that she knows by their looks, as in the case of shopping for physical goods (Figure 8-26).

Figure 8-26. Google Shopping’s visual search results

Social Navigation With the rise of massive social networks like Facebook and Twitter, social navigation has become an important approach to structuring information so that people can discover new information particu‐ larly tailored to their interests. Social navigation is built on the premise that value for the individual user can be derived from observing the actions of other users—especially those that have some meaningful relation to that individual.

Advanced Navigation Approaches | 205

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

At its simplest level, social navigation can help users discover con‐ tent based on the popularity of individual items, whether by sheer volume of traffic or by implementing a user-driven voting system. Reddit, a content aggregation and discovery service, employs such a voting system—in fact, it is its primary differentiator (Figure 8-27).

Figure 8-27. The sequence in which stories are presented on Reddit’s home page is defined by the up- or down-votes of registered site users

Other systems depend on much richer and more complex social algorithms. For example, many of Facebook’s navigation structures consist of dynamically generated lists of content items: from the sequence of posts that appear in the user’s main timeline to lists of suggested pages and other Facebook users you may know (Figure 8-28). While the exact nature of these algorithms is not pub‐ licly known (it is part of Facebook’s “secret sauce”), the content selection and the sequence it is presented in is clearly reliant on the user’s “social graph” (the list of that individual’s contacts on Facebook).

206 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

Figure 8-28. Facebook presents the user with a variety of algorithmi‐ cally generated lists of navigation links that are influenced by the social graph; the ad selection is also algorithmically determined based on the user’s profile (Facebook knows that Jorge is in the San Francisco Bay area, and that it is Valentine’s Day)

Advanced Navigation Approaches | 207

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

We expect that as more people and devices become connected through these networks, dynamically generated social navigation systems will become increasingly complex, sophisticated, and useful. As a result, organizations will find new ways of tailoring the naviga‐ tion structures of information environments to better serve the needs of individual users. However, we must be careful to not go overboard: systems that are too precisely tuned to the preferences of any one particular user’s social groups can easily devolve into echo chambers that downplay alternative points of view. It’s also impor‐ tant to keep in mind that global navigation structures play an impor‐ tant role in placemaking; people need to share some level of common, consistent structure when visiting the information envi‐ ronment over time. As with all information architecture, a balance is called for.

Recap Let’s recap what we learned in this chapter:

• We use navigation systems to chart our course, determine our position, and find our way back; they provide a sense of context and comfort as we explore new places.

• The surface layer of navigation—what people actually interact with—is changing very fast.

• There are various types of navigation systems; three common ones are global, local, and contextual systems.

• The tools we use to explore information environments—such as web browsers—provide their own navigation mechanisms.

• Building context—allowing users to locate their positions within the system—is a critical function of navigation systems.

• Global navigation systems are intended to be present on every page or screen in the information environment.

• Local navigation systems complement global ones, and allow users to explore the immediate area where they are.

• Contextual navigation systems occur in context of the content being presented in the environment, and support associative learning by allowing users to explore the relationships between items.

208 | Chapter 8: Navigation Systems

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

• There are also various supplemental navigation systems we can use, such as sitemaps, indexes, and guides.

And now we move on to search systems, which allow people to find what they are looking for in your information environment.

Recap | 209

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed

C op

yr ig

ht ©

2 01

5. O

'R ei

lly M

ed ia

, I nc

or po

ra te

d. A

ll rig

ht s

re se

rv ed