Information Architecture Assignment

One page 500-590 words

This assignment aims to apply your learning from Module 1 and 2. You will evaluate a webpage of your interest to identify all the major elements of the information architectures in terms of Organization System, Labeling System, Navigation System, and Search System (see Chapter 6-9 in Rosenfeld, et al. book).

Before you apply the guidelines to a webpage you would like to evaluate, you have to select a webpage with the following components to meaningfully evaluate their information structure & architecture.

Does the website contain information & content (e.g., text, description) for an intended group of audience?
Does the website contain enough layers/structures so that you can assess the 4 major elements and allow search query?

Examples of a website that is not suitable for this assignment:

GitHub: https://github.com/Links to an external site.
A one layer webpage like this R-MarkdownLinks to an external site.
Visual interactive page like Pinterest
Social Media platforms on the web

Examples of website that is suitable for this assignment (you can use these if you don’t want to identify one):

IS department: https://informationscience.unt.edu/Links to an external site.
ASIS&T organization https://www.asist.org/Links to an external site.
City of Denton https://www.cityofdenton.com/

CHAPTER 6

Organization Systems

The beginning of all understanding is classification

—Hayden White

In this chapter, we’ll cover:

• Subjectivity, politics, and other reasons why organizing infor‐
mation is so difficult

• Exact and ambiguous organization schemes
• Hierarchy, hypertext, and relational database structures
• Tagging and social classification

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 classifi‐
cation 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 orga‐
nize, label, and relate information influences the way people com‐
prehend that information.

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 05:58:45.

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 organize information so that people can find the right answers
to their questions, and to give them context to understand those
answers. We strive to support casual browsing and directed search‐
ing. Our aim is to design organization and labeling systems that
make sense to users.

Digital media provide us with wonderfully flexible environments in
which to organize. We can apply multiple organization systems to
the same content and escape the physical limitations of the analog
world. So why are many digital products so difficult to navigate?
Why can’t the people who design these products make it easy to find
information? These common questions focus attention on the very
real problem of organizing information.

Challenges of Organizing Information
In recent years, increasing attention has been focused on the chal‐
lenge of organizing information. Yet this challenge is not new. Peo‐
ple 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 power‐
ful 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 Cataloguing Rules.
They classified, cataloged, and helped you find the information you
needed.

As the Internet provides users with the freedom to publish informa‐
tion, it quietly burdens them with the responsibility to organize that
information. New information technologies open the floodgates for
exponential content growth, which creates a need for innovation in
content organization (see Figure 6-1).

98 | Chapter 6: Organization 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 6-1. Content growth drives innovation

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

We’re living in a world in which tremendous numbers of people
publish and organize their own information. As we do so, the chal‐
lenges inherent in organizing that information become more recog‐
nized and more important. Let’s explore some of the reasons why
organizing information in useful ways is so difficult.

Ambiguity
Classification systems are made of language, and language is ambig‐
uous: words are capable of being understood in more than one way.
Think about the word pitch. When I say “pitch,” what do you hear?
There are more than 15 definitions, including:

Challenges of Organizing Information | 99

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 The tomato is technically a berry and thus a fruit, despite a 1893 US Court decision
that declared it a vegetable. (John Nix, an importer of West Indies tomatoes, had
brought suit to lift a 10% tariff, mandated by Congress, on imported vegetables. Nix
argued that the tomato is a fruit. The Court held that because a tomato was consumed
as a vegetable rather than as a dessert-like fruit, it was a vegetable.) Source: Denise
Grady, “Best Bite of Summer” (Self 19:7, 1997, 124–125).

• A throw, fling, or toss
• A black, sticky substance used for waterproofing
• The rising and falling of the bow and stern of a ship in a rough

sea
• A salesman’s persuasive line of talk
• An element of sound determined by the frequency of vibration

This ambiguity results in a shaky foundation for our classification
systems. When we use words as labels for our categories, we run the
risk that users will miss our meaning. This is a serious problem. (See
Chapter 7 to learn more about labeling.)

It gets worse. Not only do we need to agree on the labels and their
definitions, but we also need to agree on which documents to place
in which categories. Consider the common tomato. According to
Webster’s dictionary, a tomato is “a red or yellowish fruit with a juicy
pulp, used as a vegetable: botanically it is a berry.” Now I’m con‐
fused. Is it a fruit, a vegetable, or a berry?1 And of course, this
assumes that the user reads English to begin with—an unrealistic
assumption in our increasingly multicultural digital media.

If we have such problems classifying the common tomato, consider
the challenges involved in classifying website content. Classification
is particularly difficult when you’re organizing abstract concepts
such as subjects, topics, or functions. For example, what is meant by
“alternative healing,” and should it be cataloged under “philosophy,”
“religion,” “health and medicine,” or all of the above? The organiza‐
tion of words and phrases, taking into account their inherent ambi‐
guity, presents a very real and substantial challenge.

Heterogeneity
Heterogeneity refers to an object or collection of objects composed of
unrelated or unlike parts. You might refer to grandma’s homemade

100 | Chapter 6: Organization 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

broth with its assortment of vegetables, meats, and other mysterious
leftovers as “heterogeneous.” At the other end of the scale, “homoge‐
neous” refers to something composed of similar or identical ele‐
ments. For example, Ritz crackers are homogeneous. Every cracker
looks and tastes the same.

An old-fashioned library card catalog is relatively homogeneous. It
organizes and provides access to books. It does not provide access to
chapters in books or collections of books. It may not provide access
to magazines or videos. This homogeneity allows for a structured
classification system. Each book has a record in the catalog. Each
record contains the same fields: author, title, and subject. It is a
high-level, single-medium system, and it works fairly well.

Most digital information environments, on the other hand, are
highly heterogeneous in many respects. For example, websites often
provide access to documents and their components at varying levels
of granularity. A site might present articles and journals and journal
databases side by side. Links might lead to pages, sections of pages,
or other websites. And websites typically provide access to docu‐
ments in multiple formats. You might find financial news, product
descriptions, employee home pages, image archives, and software
files. Dynamic news content shares space with static human-
resources information. Textual information shares space with video,
audio, and interactive applications. The website is a great multime‐
dia melting pot, where you are challenged to reconcile the catalog‐
ing of the broad and the detailed across many mediums.

The heterogeneous nature of information environments makes it
difficult to impose any single structured organization system on the
content. It usually doesn’t make sense to classify documents at vary‐
ing levels of granularity side by side. An article and a magazine
should be treated differently. Similarly, it may not make sense to
handle varying formats the same way. Each format will have
uniquely important characteristics. For example, we need to know
certain things about images, such as file format (JPG, PNG, etc.) and
resolution (1024 × 768, 1280 × 800, etc.). It is difficult and often
misguided to attempt a one-size-fits-all approach to the organiza‐
tion of heterogeneous content. This is a fundamental flaw of many
enterprise taxonomy initiatives.

Challenges of Organizing Information | 101

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

2 It actually gets even more complicated, because an individual’s needs, perspectives, and
behaviors change over time. A significant body of research within the field of library
and information science explores the complex nature of information models. For an
example, see N.J. Belkin, “Anomalous States of Knowledge as a Basis for Information
Retrieval” (Canadian Journal of Information Science 5, 1980, 133–143).

3 For a fascinating study on the idiosyncratic methods people use to organize their physi‐
cal desktops and office spaces, see T.W. Malone, “How Do People Organize Their
Desks? Implications for the Design of Office Information Systems” (ACM Transactions
on Office Information Systems 1, 1983, 99–112).

Differences in Perspectives
Have you ever tried to find a file on a coworker’s computer? Perhaps
you had permission. Perhaps you were engaged in low-grade corpo‐
rate espionage. In either case, you needed that file. In some instan‐
ces, you may have found the file immediately. In others, you may
have searched for hours. The ways people organize and name files
and directories on their computers can be maddeningly illogical.
When questioned, they will often claim that their organization sys‐
tem makes perfect sense. “But it’s obvious! I put current proposals in
the folder labeled /office/clients/green and old proposals in /office/
clients/red. I don’t understand why you couldn’t find them!”2

The fact is that labeling and organization systems are intensely affec‐
ted by their creators’ perspectives.3 We see this at the corporate level
with websites organized according to internal divisions or org
charts, with groupings such as marketing, sales, customer support,
human resources, and information systems. How does a customer vis‐
iting this website know where to go for technical information about
a product she just purchased? To design usable organization sys‐
tems, we need to escape from our own mental models of content
labeling and organization.

We employ a mix of user research and analysis methods to gain real
insight. How do users group the information? What types of labels
do they use? How do they navigate? This challenge is complicated by
the fact that most information environments are designed for multi‐
ple users, and all users will have different ways of understanding the
information. Their levels of familiarity with your company and your
content will vary. For these reasons, even with a massive barrage of
user tests, it is impossible to create a perfect organization system.
One system does not fit all! However, by recognizing the importance
of perspective, by striving to understand the intended audiences

102 | Chapter 6: Organization 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

through user research and testing, and by providing multiple navi‐
gation pathways, you can do a better job of organizing information
for public consumption than your coworker does on his desktop
computer.

Internal Politics
Politics exist in every organization. Individuals and departments
constantly position for influence or respect. Because of the inherent
power of information organization in forming understanding and
opinion, the process of designing information architectures can
involve a strong undercurrent of politics. The choice of organization
and labeling systems can have a big impact on how users of the sys‐
tem perceive the company, its departments, and its products. For
example, should we include a link to the library site on the main
page of the corporate intranet? Should we call it “The Library,”
“Information Services,” or “Knowledge Management”? Should infor‐
mation resources provided by other departments be included in this
area? If the library gets a link on the main page, why not corporate
communications? What about daily news?

As a designer, you must be sensitive to your organization’s political
environment. In certain cases, you must remind your colleagues to
focus on creating an architecture that works for the users. In others,
you may need to make compromises to avoid serious political con‐
flict. Politics raise the complexity and difficulty of creating usable
information architectures. However, if you are sensitive to the politi‐
cal issues at hand, you can manage their impact upon the
architecture.

Organizing Information Environments
The organization of information environments is a major factor in
determining their success, and yet many teams lack the understand‐
ing necessary to do the job well. Our goal in this chapter is to pro‐
vide 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 rela‐
tionships between content items and groups. Both organization

Organizing Information Environments | 103

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

schemes and structures have an important impact on the ways infor‐
mation is found and understood.

Before diving in, it’s important to understand information organiza‐
tion in the context of system development. Organization is closely
related to navigation, labeling, and indexing. The organization
structures of information environments often play the part of the
primary navigation system. The labels of categories play a significant
role in defining the contents of those categories. Manual indexing or
metadata tagging is ultimately a tool for organizing content items
into groups at a very detailed level. Despite these closely knit rela‐
tionships, it is both possible and useful to isolate the design of orga‐
nization systems, which will form the foundation for navigation and
labeling systems. By focusing solely on the grouping of information,
you avoid the distractions inherent in implementation details (such
as the design of the navigation user interface) and can design a bet‐
ter product.

Organization Schemes
We navigate through organization schemes every day. Contact direc‐
tories, supermarkets, and libraries all use organization schemes to
facilitate access. Some schemes are easy to use. We rarely have diffi‐
culty finding a particular word’s definition in the alphabetical orga‐
nization scheme of a dictionary. 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?

In fact, the organization schemes of the dictionary and the super‐
market are fundamentally different. The dictionary’s alphabetical
organization scheme is exact. The hybrid topical/task-oriented orga‐
nization scheme of the supermarket is ambiguous.

104 | Chapter 6: Organization 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

Exact Organization Schemes
Let’s start with the easy ones. Exact or “objective” organization
schemes divide information into well-defined and mutually exclu‐
sive sections. For example, country names are usually listed in
alphabetical order. If you know the name of the country you are
looking for, navigating the scheme is easy. “Chile” is in the Cs, which
are after the Bs but before the Ds. This is called known-item search‐
ing. You know what you’re looking for, and it’s obvious where to find
it. No ambiguity is involved. The problem with exact organization
schemes is that they require users to know the specific name of the
resource they are looking for (“What’s the name of that country that
borders Guyana and French Guiana?”).

Exact organization schemes are relatively easy to design and main‐
tain because there is little intellectual work involved in assigning
items to categories. They are also easy to use. The following sections
explore three frequently used exact organization schemes.

Alphabetical schemes
An alphabetical organization scheme is the primary organization
scheme for encyclopedias and dictionaries. Almost all nonfiction
books, including this one, provide an alphabetical index. Phone
books, department-store directories, bookstores, and libraries all
make use of our 26-letter alphabet for organizing their contents.

Alphabetical organization often serves as an umbrella for other
organization schemes. We see information organized alphabetically
by last name, by product or service, by department, and by format.
Most address book applications organize contacts alphabetically by
last name, as shown in Figure 6-2.

Organization Schemes | 105

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 6-2. The OS X Contacts application (image: https://
www.apple.com/osx/apps/#contacts)

Chronological schemes
Certain types of information lend themselves to chronological orga‐
nization. For example, an archive of press releases might be organ‐
ized by the date of release. Press release archives are obvious
candidates for chronological organization schemes (see Figure 6-3).
The date of announcement provides important context for the
release. However, keep in mind that users may also want to browse
the releases by title, product category, or geography, or to search by
keyword. A complementary combination of organization schemes is
often necessary. History books, magazine archives, diaries, and tele‐
vision guides tend to be organized chronologically. As long as there
is agreement on when a particular event occurred, chronological
schemes are easy to design and use.

106 | Chapter 6: Organization 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

https://www.apple.com/osx/apps/#contacts

Figure 6-3. Press releases in reverse chronological order

Geographical schemes
Place is often an important characteristic of information. We travel
from one place to another. We care about the news and weather that
affect us in our location. Political, social, and economic issues are
frequently location dependent. And in a world where location-aware
mobile devices have become the main way in which many people
interact with information, companies like Google and Apple are

Organization Schemes | 107

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

investing heavily in local search and directory services, with the map
as the main interface to this information.

Border disputes aside, geographical organization schemes are fairly
straightforward to design and use. Figure 6-4 shows an example of a
geographical organization scheme from Craigslist. The user can
select her nearest local directory. If her browser supports geoloca‐
tion, the site navigates directly to it.

Figure 6-4. A geographical organization scheme with geolocation

Ambiguous Organization Schemes
Now for the tough ones. Ambiguous or “subjective” organization
schemes divide information into categories that defy exact defini‐
tion. They are mired in the ambiguity of language and organization,
not to mention human subjectivity. They are difficult to design and
maintain. They can be difficult to use. Remember the tomato? Do
we classify it under fruit, berry, or vegetable?

However, these schemes are often more important and useful than
exact organization schemes. Consider the typical library catalog.
There are three primary organization schemes: you can search for
books by author, by title, or by subject. The author and title organi‐
zation schemes are exact and thereby easier to create, maintain, and
use. However, extensive research shows that library patrons use

108 | Chapter 6: Organization 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

ambiguous subject-based schemes such as the Dewey Decimal and
Library of Congress classification systems much more frequently.

There’s a simple reason why people find ambiguous organization
schemes so useful: we don’t always know what we’re looking for. In
some cases, you simply don’t know the correct label. In others, you
may have only a vague information need that you can’t quite articu‐
late. As we mentioned in Chapter 3, information seeking is often
iterative and interactive. What you find at the beginning of your
search may influence what you look for and find later in your
search. This information-seeking process can involve a wonderful
element of associative learning. Seek and ye shall find, but if the sys‐
tem is well designed, you also might learn along the way.

Ambiguous organization supports this serendipitous mode of infor‐
mation seeking by grouping items in intellectually meaningful ways.
In an alphabetical scheme, closely grouped items may have nothing
in common beyond the fact that their names begin with the same
letter. In an ambiguous organization scheme, someone other than
the user has made an intellectual decision to group items together.
This grouping of related items supports an associative learning pro‐
cess that may enable the user to make new connections and reach
better conclusions. While ambiguous organization schemes require
more work and introduce a messy element of subjectivity, they often
prove more valuable to the user than exact schemes.

The success of an ambiguous organization scheme depends upon
the quality of the scheme and the careful placement of individual
items within that scheme. Rigorous user testing is essential. In most
situations, there is an ongoing need for classifying new items and for
modifying the organization scheme to reflect changes in the indus‐
try. Maintaining these schemes may require dedicated staff with
subject matter expertise. Let’s review a few of the most common and
valuable ambiguous organization schemes.

Topical organization schemes
Organizing information by subject or topic is one of the most useful
and challenging approaches. Newspapers are organized topically, so
if you want to see the scores from yesterday’s game, you know to
turn to the sports section. Academic courses and departments, and
the chapters of most nonfiction books, are all organized along
topical lines. Many people assume that these topical groupings are

Organization Schemes | 109

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

fixed, when in fact they are cultural constructs that can vary over
time.

While few information environments are organized solely by topic,
most should provide some sort of topical access to content. In
designing a topical organization scheme, it is important to define
the breadth of coverage. Some schemes, such as those found in an
encyclopedia, cover the entire breadth of human knowledge.
Research-oriented websites such as Consumer Reports (shown in
Figure 6-5) rely heavily on their topical organization schemes. Oth‐
ers, such as corporate websites, are limited in breadth, covering only
those topics directly related to that company’s products and services.
In designing a topical organization scheme, keep in mind that you
are defining the universe of content (both present and future) that
users will expect to find within that area of the system.

Figure 6-5. A topical taxonomy showing categories and subcategories

Task-oriented schemes
Task-oriented schemes organize content and applications into col‐
lections of processes, functions, or tasks. These schemes are appro‐
priate when it’s possible to anticipate a limited number of high-
priority tasks that users will want to perform. Task-oriented
organization schemes are common in desktop and mobile apps,
especially those that support the creation and management of con‐
tent (such as word processors and spreadsheets; see Figure 6-6).

110 | Chapter 6: Organization 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 6-6. Like many apps, Microsoft Word on iOS features a task-
oriented organization scheme

On the Web, task-oriented organization schemes are most common
in the context of websites where customer interaction takes center
stage. Intranets and extranets also lend themselves well to a task ori‐
entation, because they tend to integrate powerful applications as well
as content. You will rarely find a website organized solely by task.
Instead, task-oriented schemes are usually embedded within specific
subsites or integrated into hybrid task/topic navigation systems, as
we see in Figure 6-7.

Figure 6-7. Task, topic, and audience coexist on the Smithsonian home
page

Organization Schemes | 111

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

Audience-specific schemes
In cases where there are two or more clearly definable audiences for
a product or service, an audience-specific organization scheme may
make sense. This type of scheme works well if there is value in cus‐
tomizing the content for each audience. Audience-oriented schemes
break a site into smaller, audience-specific mini-sites, thereby
allowing for clutter-free pages that present only the options of inter‐
est to that particular audience. CERN, shown in Figure 6-8, presents
an audience-oriented organization scheme that invites users to self-
identify.

Figure 6-8. CERN invites users to self-identify

Organizing by audience brings all the promise and peril associated
with any form of personalization. For example, CERN understands
its audience segments and brings this knowledge to bear on its web‐
site. If I visit the site and identify myself as a member of the “Scien‐
tist” audience, CERN will present me with research results, papers
from CERN researchers, and other information of interest to the sci‐
entific community. This information is not readily available in the
“Students & Educators” section of the site. But what if I’m a science
student doing research, and need access to research papers? All
ambiguous schemes require us to make these educated guesses and
revisit them over time.

Audience-specific schemes can be open or closed. An open scheme
will allow members of one audience to access the content intended
for other audiences. A closed scheme will prevent members from
moving between audience-specific sections. This may be appropriate
if subscription fees or security issues are involved.

112 | Chapter 6: Organization 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

Metaphor-driven schemes
Metaphors are commonly used to help users understand the new by
relating it to the familiar. You need not look further than your desk‐
top computer with its folders, files, and trash can or recycle bin for an
example. Applied to an interface in this way, metaphors can help
users understand content and function intuitively. In addition, the
process of exploring possible metaphor-driven organization
schemes can generate new and exciting ideas about the design, orga‐
nization, and function of a website.

While metaphor exploration can be useful while brainstorming, you
should use caution when considering a metaphor-driven global
organization scheme. First, metaphors, if they are to succeed, must
be familiar to users. Organizing the website of a computer-hardware
vendor according to the internal architecture of a computer will not
help users who don’t understand the layout of a motherboard.

Second, metaphors can introduce unwanted baggage or be limiting.
For example, users might expect a digital library to be staffed by a
librarian that will answer reference questions. Most digital libraries
do not provide this service. Additionally, you may wish to provide
services in your digital library that have no clear corollary in the real
world. Creating your own customized version of the library is one
such example. This will force you to break out of the metaphor,
introducing inconsistency into your organization scheme.

Organization Schemes | 113

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

Another, perhaps less obvious, example: when you first log into
Facebook, you are greeted by a “news feed” of content published by
your Facebook friends. Initially, the news feed metaphor was apt,
because the stream of posts consisted of the latest (chronologically)
published friend content. However, as the frequency of posts grew,
Facebook eventually introduced a different algorithm for choosing
which posts to show first. The result is a news feed that can show
posts that are several days old above more recent posts, breaking the
chronological order that is expected in a news feed and potentially
causing confusion. As shown in Figure 6-9, Facebook allows users to
choose between “top stories” and “most recent” to determine which
algorithm to use when ordering posts shown in the feed—an awk‐
ward solution at best.

Figure 6-9. Facebook allows users to select which algorithm controls
the sequence of posts in their news feed

Hybrid schemes
The power of a pure organization scheme derives from its ability to
suggest a simple mental model that users can quickly understand.
Users easily recognize an audience-specific or topical organization.
And fairly small, pure organization schemes can be applied to large
amounts of content without sacrificing their integrity or diminish‐
ing their usability.

However, when you start blending elements of multiple schemes,
confusion often follows, and solutions are rarely scalable. Consider
the example in Figure 6-10. This hybrid scheme includes elements of
audience-specific, topical, metaphor-based, task-oriented, and
alphabetical organization schemes. Because they are all mixed
together, we can’t form a mental model. Instead, we need to skim
through each menu item to find the option we’re looking for.

114 | Chapter 6: Organization 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 6-10. A hybrid organization scheme

The exception to these cautions against hybrid schemes exists within
the surface layer of navigation. As illustrated by the Smithsonian
example (Figure 6-7), many websites successfully combine topics
and tasks on their main page and within their global navigation.
This reflects the reality that both the organization and its users typi‐
cally identify finding content and completing key tasks at the top of
their priority lists. Because only the highest-priority tasks are
included, the solution does not need to be scalable. It’s only when
such schemes are used to organize a large volume of content and
tasks that the problems arise. In other words, shallow hybrid
schemes are fine, but deep hybrid schemes are not.

Unfortunately, deep hybrid schemes are still fairly common. This is
because it is often difficult to agree upon any one scheme, so people
throw the elements of multiple schemes together in a confusing mix.
There is a better alternative. In cases where multiple schemes must
be presented on one page, you should communicate to designers the
importance of preserving the integrity of each scheme. As long as
the schemes are presented separately on the page, they will retain
the powerful ability to suggest a mental model for users. For exam‐
ple, a look at the main menu in the Stanford University website in
Figure 6-11 reveals a topical scheme, an audience-oriented scheme,
and a search function. By presenting them separately, Stanford pro‐
vides flexibility without causing confusion.

Organization Schemes | 115

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 6-11. Stanford provides multiple organization schemes

Organization Structures
Organization structure plays an intangible yet very important role in
the design of information environments. Although we interact with
organization structures every day, we rarely think about them. Mov‐
ies are linear in their physical structure. We experience them frame
by frame, from beginning to end. However, the plots themselves
may be nonlinear, employing flashbacks and parallel subplots. Maps

116 | Chapter 6: Organization 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

have a spatial structure. Items are placed according to physical prox‐
imity, although the most useful maps cheat, sacrificing accuracy for
clarity.

The structure of information defines the primary ways in which
users can navigate. Major organization structures that apply to
information architectures include the hierarchy, the database-
oriented model, and hypertext. Each organization structure pos‐
sesses unique strengths and weaknesses. In some cases, it makes
sense to use one or the other. In many cases, it makes sense to use all
three in a complementary manner.

The Hierarchy: A Top-Down Approach
The foundation of many good information architectures is a well-
designed hierarchy. In this hypertextual, free-ranging world of nets
and webs, such a statement may seem blasphemous, but it’s true.
The mutually exclusive subdivisions and parent–child relationships
of hierarchies are simple and familiar. We have organized informa‐
tion into hierarchies since the beginning of time. Family trees are
hierarchical. Our division of life on earth into kingdoms, classes,
and species is hierarchical. Organization charts are usually hierarch‐
ical. We divide books into chapters into sections into paragraphs
into sentences into words into letters. Hierarchy is ubiquitous in our
lives and informs our understanding of the world in a profound and
meaningful way. Because of this pervasiveness of hierarchy, users
can easily and quickly understand information environments that
use hierarchical organization models. They are able to develop a
mental model of the environment’s structure and their location
within that structure. This provides context that helps users feel
comfortable. Figure 6-12 shows an example of a simple hierarchical
model.

Organization Structures | 117

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 6-12. A simple hierarchical model

Because hierarchies provide a simple and familiar way to organize
information, they are usually a good place to start the information
architecture process. The top-down approach allows you to quickly
get a handle on the scope of the information environment without
going through an extensive content-inventory process. You can
begin identifying the major content areas and exploring possible
organization schemes that will provide access to that content.

Designing hierarchies
When designing hierarchies, you should remember a few rules of
thumb. First, you should be aware of, but not bound by, the idea that
hierarchical categories should be mutually exclusive. Within a single
organization scheme, you will need to balance the tension between
exclusivity and inclusivity. Hierarchies that allow cross-listing are
known as polyhierarchical. Ambiguous organization schemes in par‐
ticular make it challenging to divide content into mutually exclusive
categories. Do tomatoes belong in the fruit, vegetable, or berry cate‐
gory? In many cases, you might place the more ambiguous items
into two or more categories so that users are sure to find them.
However, if too many items are cross-listed, the hierarchy loses its
value. This tension between exclusivity and inclusivity does not exist
across different organization schemes. You would expect a listing of
products organized by format to include the same items as a com‐
panion listing of products organized by topic. Topic and format are
simply two different ways of looking at the same information. Or, to
use a technical term, they’re two independent facets. (See Chapter 10
for more about metadata, facets, and polyhierarchy.)

Second, it is important to consider the balance between breadth and
depth in your hierarchy. Breadth refers to the number of options at

118 | Chapter 6: Organization 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

4 G. Miller, “The Magical Number Seven, Plus or Minus Two: Some Limits on Our
Capacity for Processing Information” (Psychological Review 63:2, 1956, 81–97).

each level of the hierarchy. Depth refers to the number of levels in
the hierarchy. If a hierarchy is too narrow and deep, users have to
click or tap through an inordinate number of levels to find what
they are looking for. The top of Figure 6-13 illustrates a narrow-and-
deep hierarchy in which users are faced with six clicks to reach the
deepest content. The bottom shows a broad-and-shallow hierarchy,
where users must choose from 10 categories to reach 10 content
items. If a hierarchy is too broad and shallow, as in this case users
are faced with too many options on the main menu and are unpleas‐
antly surprised by the lack of content once they select an option.

Figure 6-13. Balancing depth and breadth

When considering breadth, you should be sensitive to people’s visual
scanning abilities and to the cognitive limits of the human mind.
Now, we’re not going to tell you to follow the infamous seven plus or
minus two rule.4 There is general consensus that the number of links
you can safely include is constrained by users’ abilities to visually
scan the page rather than by their short-term memories.

Organization Structures | 119

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 Just before this book went to press, the National Cancer Institute launched a new,
improved version of this page—which we like quite a bit!

Instead, when dealing with issues of breadth versus depth we sug‐
gest that you:

• Recognize the danger of overloading users with too many
options.

• Group and structure information at the page level.
• Subject your designs to rigorous user testing.

Consider the National Cancer Institute’s award-winning main page,
shown in Figure 6-14.5 It’s one of the US government’s most visited
(and tested) pages on the Web, and the portal into a large informa‐
tion system. Presenting information hierarchically at the page level,
as NCI has done, can make a major positive impact on usability.

Figure 6-14. The National Cancer Institute groups items within the
page

120 | Chapter 6: Organization 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

http://www.cancer.gov/

6 Kevin Larson and Mary Czerwinski, Microsoft Research, “Web Page Design: Implica‐
tions of Memory, Structure and Scent for Information Retrieval”.

There are roughly 85 links on NCI’s main page, and they’re organ‐
ized into several key groupings (Table 6-1).

Table 6-1. Links on NCI’s main page

Group Notes

Global navigation Global navigation (e.g., Cancer Topics, Clinical Trials, Cancer Statistics) has
seven links plus Search.

Highlighted stories Includes 9 links.

Types of Cancer Includes 12 Common Cancer Types and 4 alternate ways to explore All
Cancer Types.

Clinical Trials Includes 4 links.

Cancer Topics Includes 9 links.

Cancer Statistics Includes 3 links.

Research & Funding Includes 5 links.

NCI Vision & Priorities Includes 4 links.

News There are 3 headlines plus a link to the archive.

Resources Includes 7 links.

Footer navigation Includes 20 links.

These 80-odd links are subdivided into 10 discrete categories, with a
limited number of links per category.

In contrast to breadth, when considering depth, you should be even
more conservative. If users are forced to click through more than
two or three levels, they may simply give up and leave your website.
At the very least, they’ll become frustrated. An excellent study con‐
ducted by Microsoft Research suggests that a balance of breadth and
depth may provide the best results.6

For new information environments that are expected to grow, you
should lean toward a broad-and-shallow rather than a narrow-and-
deep hierarchy. This allows for the addition of content without
major restructuring. It is less problematic to add items to secondary
levels of the hierarchy than to the main page, for a couple of reasons.
First, in many systems, the main page or screen serves as the most
prominent and important navigation interface for users, helping set
their expectations of what they can do in the system. Second,

Organization Structures | 121

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/larson_czerwinski

because of the main page’s prominence and importance, companies
tend to put lots of care (and money) into its graphic design and lay‐
out. Changes to the main page can be more time consuming and
expensive than changes to secondary pages.

Finally, when designing organization structures, you should not
become trapped by the hierarchical model. Certain content areas
will invite a database or hypertext-based approach. The hierarchy is
a good place to begin, but it is only one component in a cohesive
organization system.

The Database Model: A Bottom-Up Approach
A database is defined as “a collection of data arranged for ease and
speed of search and retrieval.” A Rolodex provides a simple example
of a flat-file database (see Figure 6-15). Before computers became
commonplace, Rolodexes were a common tool to store people’s con‐
tact information. They consisted of rolls of physical cards, with each
card representing an individual contact: a record in the system. Each
record contains several fields, such as name, address, and telephone
number. Each field may contain data specific to that contact. The
collection of records is a database.

Figure 6-15. The printed card Rolodex is a simple database

In an old-fashioned Rolodex, users are limited to searching for a
particular individual by last name. In a digital contact-management
system, we can also search and sort using other fields. For example,
we can ask for a list of all contacts who live in Connecticut, sorted
alphabetically by city.

Most of the heavy-duty databases we use are built upon the rela‐
tional database model. In relational database structures, data is
stored within a set of relations or tables. Rows in the tables represent
records, and columns represent fields. Data in different tables may
be linked through a series of keys. For example, in Figure 6-16, the

122 | Chapter 6: Organization 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

au_id and title_id fields within the AUTHOR_TITLE table act as keys
linking the data stored separately in the AUTHOR and TITLE tables.

Figure 6-16. A relational database schema (image: http://bit.ly/rela‐
tional_model).

Organization Structures | 123

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/relational_model

So why are database structures important to information architects?
In a word, metadata. Metadata is the primary key that links infor‐
mation architecture to the design of database schemas. It allows us
to apply the structure and power of relational databases to the heter‐
ogeneous, unstructured environments of websites and intranets. By
tagging documents and other information objects with metadata, we
enable powerful searching, browsing, filtering, and dynamic linking.
(We’ll discuss metadata and controlled vocabularies in more detail
in Chapter 9.)

The relationships between metadata elements can become quite
complex. Defining and mapping these formal relationships requires
significant skill and technical understanding. For example, the entity
relationship diagram (ERD) in Figure 6-17 illustrates a structured
approach to defining a metadata schema. Each entity (e.g.,
Resource) has attributes (e.g., Name, URL). These entities and
attributes become records and fields. The ERD is used to visualize
and refine the data model before design and population of the data‐
base.

We’re not suggesting that you must become an expert in SQL, XML
schema definition, the creation of entity relationship diagrams, and
the design of relational databases—though these are all extremely
valuable skills. In many cases, you’ll be better off working with a
professional programmer or database designer who really knows
how to do this stuff. And for large websites, you will hopefully be
able to rely on content management system (CMS) software to man‐
age your metadata and controlled vocabularies.

124 | Chapter 6: Organization 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 6-17. An entity relationship diagram showing a structured
approach to defining a metadata schema (courtesy of Peter Wyngaard
of Interconnect of Ann Arbor)

Instead, you need to understand how metadata, controlled vocabu‐
laries, and database structures can be used to enable:

• Automatic generation of alphabetical indexes (e.g., a product
index)

• Dynamic presentation of associative “see also” links and content
• Fielded searching
• Advanced filtering and sorting of search results

Organization Structures | 125

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 database model is particularly useful when applied within rela‐
tively homogeneous subsites such as product catalogs and staff
directories. However, enterprise controlled vocabularies can often
provide a thin horizontal layer of structure across the full breadth of
a site. Deeper vertical vocabularies can then be created for particular
departments, subjects, or audiences.

Hypertext
Hypertext is a highly nonlinear way of structuring information. A
hypertext system involves two primary types of components: the
items or chunks of information that will be linked, and the links
between those chunks.

These components can form hypermedia systems that connect text,
data, image, video, and audio chunks. Hypertext chunks can be con‐
nected hierarchically, nonhierarchically, or both, as shown in
Figure 6-18. In hypertext systems, content chunks are connected via
links in a loose web of relationships.

Figure 6-18. A network of hypertextual connections

Although this organization structure provides you with great flexi‐
bility, it presents substantial potential for complexity and user con‐
fusion. Why? Because hypertext links reflect highly personal
associations. The relationships that one person sees between content
items may not be apparent to others. Additionally, as users navigate
through highly hypertextual websites, it is easy for them to get lost.
It’s as if they are thrown into a forest and are bouncing from tree to

126 | Chapter 6: Organization 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

tree, trying to understand the lay of the land. They simply can’t cre‐
ate a mental model of the environment’s organization. Without con‐
text, users can quickly become overwhelmed and frustrated.

For these reasons, hypertext is rarely a good candidate for the pri‐
mary organization structure. Rather, it can be used to complement
structures based upon the hierarchical or database models.

Hypertext allows for useful and creative relationships between items
and areas in the hierarchy. It usually makes sense to first design the
information hierarchy and then identify ways in which hypertext
can complement the hierarchy.

Social Classification
Social media has become a mainstay of the digital experience. Plat‐
forms like Facebook and Twitter have enabled hundreds of millions
of people to share their interests, photos, videos, and more with one
another and with all of us. As a result, social classification—primar‐
ily driven by user-generated content tagging—has emerged as an
important tool for organizing information in shared information
environments.

Free tagging, also known as collaborative categorization, mob index‐
ing, and ethnoclassification, is a simple yet powerful tool. Users tag
objects with one or more keywords. These tags can be informally
supported in text fields, or they can be provided for with bespoke
fields in the formal structure of content objects. The tags are public
and serve as pivots for social navigation. Users can move fluidly
between objects, authors, tags, and indexers. And when large num‐
bers of people get involved, interesting opportunities arise to trans‐
form user behavior and tagging patterns into new organization and
navigation systems.

For example, in Twitter, words with a prepended hash (#) have a
special meaning: the system picks them up as tags. When you
include one of these tagged words in a tweet, the system marks that
post as belonging to a group of posts that has been informally
defined by the users of Twitter (Figure 6-19). No single person or
centralized team created a taxonomy to define these relationships.

Social Classification | 127

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

7 Twitter tags weren’t originally included in the system: they emerged informally,
included by the users of the platform in unstructured text fields.

Rather, they emerged (and continue to emerge) through the tagging
efforts of many individuals.7

Figure 6-19. The “Discover” and “Trending” features in Twitter, which
allow you to discover new and potentially interesting content, are
driven by user-generated tags

Similarly, LinkedIn allows users to “endorse” their professional con‐
tacts as possessing certain individual professional skills
(Figure 6-20). These endorsements are in effect tags: they allow
users to describe their business contacts in a granular way that
informs how the system groups them with similar people. Though
users can suggest new endorsement labels, these are not free-form,
unstructured tags like the ones that Twitter employs; they have been
built as bespoke, dedicated structures within the architecture of
LinkedIn.

In the early days of information architecture, an impassioned debate
raged over whether or not free-form tag structures (or “folksono‐
mies,” as information architect Thomas Vander Wal cleverly chris‐
tened them) would eliminate the need for top-down, centrally
defined information structures. The passage of time has proven the
value of top-down structures: high-profile experiments in tag-driven
systems—such as the bookmarking service Delicious.com—fizzled
in the marketplace, and most of these systems employed tags within
centrally defined structures anyway. Still, free-form tagging has pro‐

128 | Chapter 6: Organization 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

ven its usefulness in specific situations, and it remains a valuable
tool in the information architect’s toolset.

Figure 6-20. LinkedIn allows you to “endorse” your contacts as having
certain professional skills, from a set of predefined tags

Creating Cohesive Organization Systems
User experience designer Nathan Shedroff suggests that the first step
in transforming data into information is exploring its organization.
As you’ve seen in this chapter, organization systems are fairly com‐
plex. You need to consider a variety of exact and ambiguous organi‐
zation 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 influ‐
ence 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 website development
project, these questions can be overwhelming. That’s why it’s impor‐
tant to break down the information enviornment into its compo‐
nents, 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

Creating Cohesive Organization Systems | 129

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

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 pan‐
cakes doesn’t mean they will go well together. The recipe for cohe‐
sive organization systems varies from one information environment
to another. However, there are a few guidelines to keep in mind.

When 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 pre‐
cisely 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, peo‐
ple have different perspectives, and politics can rear their ugly head.
Providing multiple ways to access the same information can help to
deal with all of these challenges.

When thinking about which organization structures to use, keep in
mind that large systems typically require several types of structures.
The top-level, umbrella architecture for the environment will almost
certainly be hierarchical. As you are designing this hierarchy, keep a
look out for collections of structured, homogeneous information.
These potential subenvironments are excellent candidates for the
database model. Finally, remember that less structured, more crea‐
tive relationships between content items can be handled through
author-supplied hypertext or user-contributed tagging. In this way,
myriad organization structures together can create a cohesive orga‐
nization system.

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

• Our understanding of the world is informed by how we classify
things.

• Classifying things is not easy; we have to deal with ambiguity,
heterogeneity, differences in perspective, and internal politics,
among other challenges.

130 | Chapter 6: Organization 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 can organize things using exact organization schemes or
ambiguous organization schemes.

• Exact organization schemes include alphabetical, chronological,
and geographical groupings.

• Ambiguous organization schemes include topical, task-based,
audience-based, metaphorical, and hybrid groupings.

• The structure of organization schemes also plays an important
role in the design of information environments.

• Social classification has emerged as an important tool for organ‐
izing information in shared digital environments.

Now let’s move on to cover another critical component of an infor‐
mation architecture: labeling systems.

Recap | 131

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

CHAPTER 7

Labeling Systems

Now the LORD God had formed out of the ground all the
wild animals and all the birds in the sky

He brought them

to the man to see what he would name them; and whatever
the man called each living creature, that was its name.

—Genesis 2:19

In this chapter, we’ll cover:

• What labeling is and why it’s important
• Common types of labels
• Guidelines for developing labels
• Sources of inspiration for your labeling system

Labeling is a form of representation. Just as we use spoken words to
represent concepts and thoughts, we use labels to represent larger
chunks of information in our information environments. For exam‐
ple, “Contact Us” is a label that represents a chunk of content, often
including a contact name, an address, and telephone, fax, and email
information. You cannot present all this information quickly and
effectively on an already crowded web page without overwhelming
impatient people who might not actually need that information.
Instead, a label like “Contact Us” works as a shortcut that triggers
the right association in someone’s mind without presenting all that
stuff prominently. The person can then decide whether to click
through or read on to get more contact information. So, the goal of a
label is to communicate information efficiently—that is, to convey

133

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

meaning without taking up too much of a page’s physical space or
the user’s cognitive space.

Unlike the weather, hardly anyone ever talks about labeling (aside
from a few deranged librarians, linguists, journalists, and informa‐
tion architects), but everyone can do something about it. In fact, we
are doing something about it, albeit unconsciously: anyone develop‐
ing content or an architecture for a website or app is creating labels
without even realizing it. And our label creation goes far beyond our
information products; ever since Adam named the animals, labeling
has been one of the things that make us human. Spoken language is
essentially a labeling system for concepts and things. Perhaps
because we constantly label, we take the act of labeling for granted.
That’s why labeling can often be confusing, and users suffer the con‐
sequences. This chapter provides some advice on how to think
through an information environment’s labeling before diving into
implementation.

How does labeling fit with the other systems we’ve discussed? Well,
labels are often the most obvious way to clearly show the user your
organization and navigation schemes across multiple systems and
contexts. For example, a single screen layout might contain different
groups of labels, with each group representing a different organiza‐
tion or navigation system. Examples include labels that match the
environment’s organization system (e.g., Home/Home Office, Small
Business, Medium & Large Business, Government, Health Care), a
global navigation system (e.g., Main, Search, Feedback), a subsite
navigation system (e.g., Add to Cart, Enter Billing Information,
Confirm Purchase), and systems specific to other channels such as
interactive voice response (IVR) phone services and printed
catalogs.

Why You Should Care About Labeling
Prerecorded 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 her own point, or beginning to clench her
fingers into an angry fist, and we react by shifting our own style of

134 | Chapter 7: Labeling 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 A popular game that goes by different names around the world. Players pass a message
in secret from one person to another. When it reaches the last player, they compare the
(often unrecognizable) final message to the one they started with.

2 Thanks to information architect Andrew Hinton, who brought this example to our
attention. You can read more about Andrew’s take on Starbucks’s labels in his book
Understanding Context (Sebastopol, CA: O’Reilly, 2014).

communication, perhaps by raising our speaking volume, increasing
our use of body language, changing a rhetorical tack, or fleeing.

Unfortunately, when we “converse” with users through the systems
we design, the feedback isn’t quite so immediate, if it exists at all.
There are certainly exceptions—social media such as Twitter, for
example—but in most cases an information environment serves as
an intermediary that slowly translates messages from the system’s
owners and authors to users, and back again. This “telephone
game”1 muddies the message. So in such a disintermediated medium
with few visual cues, communicating is harder, and labeling is there‐
fore more important.

To minimize this disconnect, we must try our best to design labels
that speak the same language as our environment’s users while
reflecting its content. And, just as in a dialogue, when there is a
question or confusion over a label, there should be clarification and
explanation. Labels should educate people about new concepts and
help them quickly identify familiar ones.

The conversation between a user and the environment’s owner often
begins on a website’s main page. To get a sense of how successful this
conversation might be, look at a site’s main page, do your best to
ignore the other aspects of its design, and ask yourself a few ques‐
tions: Do the prominent labels on this page stand out to you? If they
do, why? (Often, successful labels are invisible; they don’t get in your
way.) If a label is new, unanticipated, or confusing, is there an
explanation? Or are you required to click through to learn more?
Although unscientific, this label testing exercise will help you get a
sense of how the conversation might go with actual users.

Let’s try it with an average corporate information environment: Star‐
bucks’s public website, which is shown in Figure 7-1.2

Why You Should Care About Labeling | 135

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 7-1. How do you respond to these labels?

Starbucks’s labels don’t seem terribly out of the ordinary. However,
mediocrity isn’t an indicator of value or success; in fact, trouble
spots arise from an informal cruise through the site’s labels. Let’s
have a look:

My Bag | Find a Store | Sign In | Search this site
So far so good: these are fairly standard labels on websites for
companies that sell goods in physical and online stores. The
location pin icon next to the “Find a Store” link implies that this
will lead to the geographic locations of Starbucks’s stores, and
the “My Bag” label, while not as common, is accompanied by a
fairly standard bag icon that implies “shopping cart.”

Coffee
Again, not bad—Starbucks sells coffee, so we’d expect some‐
thing like this here. It’s also good that it’s the first label next to
the Starbucks logo, because it reinforces the association of the
company logo with its primary product.

Menu
This is where we start spotting trouble. What do we mean by
“Menu” in the context of a website? Does this refer to the navi‐
gation menu of the site? A list of coffee drinks? Or is it a menu
in the sense of a restaurant? (It turns out to be the latter.) While

136 | Chapter 7: Labeling 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

this label doesn’t seem to be that ambiguous in a desktop
browser—after all, the rest of the site menu items are laid out
next to it—it becomes more problematic when rendered in a
mobile browser, because the label “Menu” is more often experi‐
enced in those browsers as a way of accessing the system’s main
navigation menu (Figure 7-2).

Figure 7-2. When accessed in a mobile browser, the labels used on
the Starbucks website are experienced in a different context, which
can change their meaning

It’s worth noting here that while clicking the global menu links
in the desktop version of the Starbucks website reveals mega-
menus for each label, mobile users can’t derive additional con‐
textual clues; all they have to go by are the labels of the global
navigation menu.

Why You Should Care About Labeling | 137

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

Coffeehouse
You’ve probably seen this word before. What does it mean to
you? According to the OS X dictionary, it means “a cafe or other
place where coffee is served, sometimes also offering informal
entertainment”—in other words, a physical place where you can
buy coffee. So you’d think that this is where you will find a list of
Starbucks’s stores, and you’d be partly right… But there is much
more there! For example, this is also where you find informa‐
tion about Starbucks’s iOS and Android apps and the company’s
“Online Community” (Figure 7-3). It gives the impression that
“Coffeehouse” has a particular meaning within the Starbucks
Corporation, and one that is not immediately evident from
examining the content it represents. It’s also worth noting that
because “Coffeehouse” begins with the word “Coffee” (and sits
close to it in the navigation menu), this label may cause users to
do a double-take when looking for coffee.

Figure 7-3. The word “Coffeehouse” seems to have a particular
meaning in the context of Starbucks

Responsibility
Again, we don’t have too many issues with this label; it’s fairly
common for large corporations to have social responsibility
programs, and we’d expect to find that type of information here.

Card
“Card” seems like a very broad term. Does it refer to your Star‐
bucks Card, the Starbucks eGift Card you received for your

138 | Chapter 7: Labeling 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

birthday, or the credit card that is registered as a valid payment
method in your Starbucks account?

Shop
“Shop” can be a verb or a noun. Here it is meant as a verb: it’s
where you shop online in the “Starbucks Store” (which is not
the same type of physical Starbucks “store” referred to in the
“Find a Store” link). This is the only verb in the global naviga‐
tion, a potential source of confusion for users who may read it
as leading to information about a physical “shop.”

The results of this quick exercise can be summarized by these
categories:

The labels aren’t representative and don’t differentiate
Many of Starbucks’s labels don’t represent the content they link
to or precede. Other than clicking through, users have no way
to learn what “Menu” means, or what the difference is between
“Coffeehouse,” “Coffee,” and “Shop.” Groupings of dissimilar
items (e.g., “Wi-Fi,” “Starbucks Mobile Apps,” and “Online
Community”) don’t provide any context for what those items’
labels really represent. There is too much potential for confu‐
sion to consider these labels effective.

Some labels are jargony, not user-centric
Labels like “Coffeehouse” and “Starbucks Store” can expose an
organization that, despite its best intentions, does not consider
the importance of its customers’ needs as important as its own
goals, politics, and culture. This is often the case when websites
use organizational jargon for their labels. You’ve probably seen
such sites; their labels are crystal clear, obvious, and enlighten‐
ing, as long as you’re one of the .01% of 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 Process‐
ing and Fulfillment Facility.”

The labels waste money
There are too many chances for a user to step into one of the
many confusing cognitive traps presented by Starbucks’s labels.
And any time an architecture intrudes on a user’s experience
and forces him to pause and say “huh?” there is a reasonable
chance that he will give up on a site and go somewhere else,
especially given the competitive nature of this medium. In other

Why You Should Care About Labeling | 139

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

words, confusing labels can negate the investment made to
design and build a useful site and to market that site to intended
audiences.

The labels don’t make a good impression
The way you communicate or represent information on your
site says a lot about you, your organization, and its brand. If
you’ve ever read an airline magazine, you’re familiar with those
ads for some educational series that develops your vocabulary.
“The words you use can make or break your business deals,” or
something like that. The same is true with an information envi‐
ronment’s labeling—poor labeling can destroy a user’s confi‐
dence in an organization. While it may have spent heavily on
traditional branding, Starbucks doesn’t seem to have given
much thought to the labels on the most important piece of its
virtual real estate—its main page.

Like writing or any other form of professional communication,
labels do matter. It’s fair to say that they’re as integral to an effective
web presence as any other aspect of your website, be it brand, visual
design, functionality, content, or navigability.

Varieties of Labels
In information environments, we regularly encounter labels in two
formats: textual and iconic. In this chapter, we’ll spend most of our
time addressing textual labels (as they remain the most common,
despite the Web’s highly visual nature), including:

Contextual links
Hyperlinks to chunks of information on other pages or to other
locations on the same page

Headings
Labels that simply describe the content that follows them, just as
print headings do

Navigation system choices
Labels representing the options in navigation systems

Index terms
Keywords, tags, and subject headings that represent content for
searching or browsing

140 | Chapter 7: Labeling 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

These categories are by no means perfect or mutually exclusive. A
single label can do double duty; for example, the contextual link
“Naked Bungee Jumping” could lead to a page that uses the heading
label “Naked Bungee Jumping” and has been indexed as being about
(you guessed it) naked bungee jumping. And some of these labels
could be iconic rather than textual, although we’d rather not imagine
a visual representation of naked bungee jumping!

In the following section, we’ll explore the varieties of labels in
greater detail and provide you with some examples.

Labels as Contextual Links
Labels describe the hypertext links within the body of a document or
chunk of information, and naturally occur within the descriptive
context of their surrounding text. Contextual links are easy to create
and are the basis for the exciting interconnectedness that drives
much of the Web’s success.

However, just because contextual links are relatively easy to create
doesn’t mean they necessarily work well. In fact, ease of creation
introduces problems. Contextual links are generally not developed
systematically; instead, they are developed in an ad hoc manner
when the author makes a connection between her text and some‐
thing else, and encodes that association in her document. These
hypertext connections are therefore more heterogeneous and per‐
sonal than, say, the connections between items in a hierarchy, where
links are understood to be connecting parent items and child items.
The result is that contextual link labels mean different things to dif‐
ferent people. You see the link “Shakespeare” and, upon clicking it,
expect to be taken to the Bard’s biography. I, on the other hand,
expect to be taken to his Wikipedia entry. In fact, the link actually
takes us to a page for the village of Shakespeare, New Mexico. Go
figure…

To be more representational of the content they connect to, contex‐
tual links rely instead upon, naturally, context. If the content’s
author succeeds at establishing that context in his writing, then the
label draws meaning from its surrounding text. If he doesn’t, the
label loses its representational value, and users are more likely to
experience occasionally rude surprises.

Because GOV.UK (Figure 7-4) is a site dedicated to providing infor‐
mation to the entire population of the UK, contextual links need to

Varieties of Labels | 141

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

be straightforward and meaningful. GOV.UK’s contextual link
labels, such as “Benefits,” “Money and tax,” and “Disabled people,”
are representational, and draw on surrounding text and headings to
make it clear what type of help you’ll receive if you click through.
These highly representational labels are made even clearer by their
context: explanatory text, clear headings, and a site that itself has a
few straightforward uses.

Figure 7-4. The contextual links on the GOV.UK home page are
straightforward and meaningful

On the other hand, contextual links on a blog aren’t necessarily so
clear. The author is among friends and can assume that her regular
readers possess a certain level of background (or, really, contextual)
knowledge. Or she knows that keeping her link labels less represen‐
tational creates some mystery around what they’ll lead to. So the
author may choose to design contextual link labels that aren’t so
representational.

In Figure 7-5, the author expects us to know who “Dr. Drang” is—
perhaps s/he’s been mentioned in this blog before. Or the author
knows that we’ll recognize the label “Dr. Drang” as a person, and
provides some mysterious context—“Your favorite snowman and
mine”—to entice the user to click through. “Brent Simmons’ obser‐
vation” is equally obscure; we have no idea what this label repre‐
sents, but the blog author summarizes it by stating that “software

142 | Chapter 7: Labeling 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

engineers don’t really have a code of ethics.” Nonrepresentational
labels have their place; as it’s likely that we already trust the author’s
opinion, we’ll probably want to click through and learn more. In a
case like the blog illustrated here, they can even convey the feeling
that you are dropping in on a discussion among friends. But without
that degree of trust already in place, nonrepresentational links could
be damaging.

Figure 7-5. These contextual links aren’t very representational, but
that’s acceptable when there is a high degree of trust in the author

As we’ll see, other varieties of labels derive context, and therefore
meaning, from being part of larger sets of labels or labeling systems.
But systematic consistency isn’t quite so possible with link labels.
These labels are glued together by the copy and context rather than
membership in a peer group. However, consistency among these
labels and the chunks of information to which they link remains an
issue to keep in mind.

We can ensure that contextual link labels are representational by
asking, “What kind of information will the person expect to be
taken to?” before creating and labeling a contextual link. Contextual
links are created in such an ad hoc manner that simply asking this
question will improve the quality of representation. (An easy way to
study people’s interpretations of labels is to provide a printout of a

Varieties of Labels | 143

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

page with the labels clearly identified, and have participants jot
down what they’d expect each to link to.)

On the other hand, it’s important to acknowledge that contextual
links are often not within our control. Usually, content authors are
responsible for contextual links. They are the ones who know the
meaning of their content and how to best link it to other content. So
while you may want to enforce rules for contextual link labels (such
as what an employee’s name should always link to), you may be bet‐
ter off suggesting guidelines to content authors (such as suggesting
that employees’ names link to corresponding directory listings when
possible).

Labels as Headings
Labels are often used as headings that describe the chunks of infor‐
mation that follow. Headings, as shown in Figure 7-6, are often used
to establish a hierarchy within content. Just as in a book, where
headings help us distinguish chapters from sections, they also help
us determine a site’s subsites, or differentiate categories from
subcategories.

Figure 7-6. Layout, typographic treatment, and whitespace help the
reader distinguish labels and hierarchy in the Windows Store

The hierarchical relationships between headings—whether parent,
child, or sibling—are usually established visually through consistent
use of numbering, font sizes, colors and styles, whitespace and
indentation, or combinations thereof. A visually clear hierarchy,

144 | Chapter 7: Labeling 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

often the work of information or graphic designers, can take some
pressure off information architects by reducing the need to create
labels that convey that hierarchy. So, a set of labels that don’t mean
much can suddenly take on meaning when presented in a hierarchy.
For example, this set of inconsistent headings may be quite
confusing:

Our Furniture Selection
Office Chairs
Our buyer’s picks
Chairs from Steelcase
Hon products
Herman Miller
Aerons
Lateral Files

However, they are much more meaningful when presented in a
hierarchy:

Our Furniture Selection
Office Chairs
Our buyer’s picks
Chairs from Steelcase
Hon products
Herman Miller
Aerons
Lateral Files

It’s also important not to be too rigidly bound to showcasing hier‐
archical relationships. In Figure 7-7, heading labels such as “Lead‐
ers” and “Southeastern Standings” represent the content that follows
them. Yet the game schedule closer to the top of the page doesn’t
merit the same treatment, because most readers could visually dis‐
tinguish these without actually reading them. In other words, insert‐
ing the heading “Game Schedule” before the table and applying to it
the same typographic style as that used for “Leaders” and “South‐
eastern Standings” wouldn’t greatly benefit users, who would likely
recognize the schedule already.

Labels as Headings | 145

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 7-7. This hierarchy of heading labels is inconsistent, but that’s
OK

It is interesting to note, however, that it’d be impossible to correctly
read the schedule if each column in the table didn’t have its own
heading label.

We can be a bit more flexible when designing hierarchical headings,
but it’s especially important to maintain consistency when labeling
steps in a process. To successfully navigate a process, it’s typically
necessary for users to complete each step along the way, so heading
labels have to be obvious and must also convey sequence. Using
numbers is an obvious way to communicate progression, and

146 | Chapter 7: Labeling 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

consistently framing the labels as actions—utilizing verbs—also
helps tie together the sequence of steps. In effect, the labels should
tell users where to start, where to go next, and what action will be
involved in each step along the way. Figure 7-8 shows a page in the
process to sign up to become a Google Play Developer, which clearly
describes the actions required in each step.

Figure 7-8. Clear sequential labeling in the Google Play Developer
signup process

Heading labels, whether hierarchical or sequenced, come in multi‐
ples, and should be more systematically designed than contextual
link labels.

Labels Within Navigation Systems
Because navigation systems typically have a small number of
options, their labels demand consistent application more than any
other type of label. A single inconsistent option can introduce an
“apples and oranges” effect more quickly in a navigation system,
which usually has fewer than 10 choices, than in a set of index
terms, which might have thousands. Additionally, a navigation sys‐
tem is typically experienced repeatedly throughout the environment,
so navigation labeling problems are magnified through repeated
exposure.

Users rely on a navigation system to behave “rationally” through a
consistent location and look; labels should be no different.

Labels as Headings | 147

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

Effectively applied labels are integral to building a sense of familiar‐
ity, so they’d better not change from page to page. Using the label
“Main” on one page, “Main Page” on another, and “Home” else‐
where could destroy the familiarity that the user needs when navi‐
gating a site. In Figure 7-9, the horizontal navigation system’s four
labels—“The Janus Advantage,” “Our Funds,” “Planning,” and “My
Account”—are applied consistently throughout the website, and
would be even more effective if their colors and locations were also
consistent.

There are no standards, but some common variants exist for many
navigation system labels. You should consider selecting one from
each of these categories and applying it consistently, as these labels
are already familiar to most web users. Here is a nonexhaustive list:

• Main, Main Page, Home
• Search, Find, Browse, Search/Browse
• Site Map, Contents, Table of Contents, Index
• Contact, Contact Us
• Help, FAQ, Frequently Asked Questions
• News, News & Events, News & Announcements, Announce‐

ments
• About, About Us, About , Who We Are

Of course, the same label can often represent different kinds of
information. For example, in one system, “News” may link to an
area that includes announcements of new additions to the website.
In another site, “News” may link to an area of news stories describ‐
ing national and world events. Obviously, if you use the same labels
in different ways within your own system, your users will be very
confused. One alternative in such cases is to include brief descrip‐
tions under navigational labels, with the obvious trade-off being that
these descriptions consume valuable screen real estate.

148 | Chapter 7: Labeling 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 7-9. Janus’s navigation system labels remain consistent through‐
out the website

Labels as Index Terms
Often referred to as keywords, tags, descriptive metadata, taxono‐
mies, controlled vocabularies, and thesauri, sets of index term labels
can be used to describe any type of content: sites, subsites, pages,
content chunks, and so on. By representing the meaning of a piece

Labels as Headings | 149

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

of content, index terms support more precise searching than simply
searching the full text—someone has assessed the content’s meaning
and described it using index terms, and searching those terms ought
to be more effective than having a search engine match a query
against the content’s full text.

Index terms are also used to make browsing easier: the metadata
from a collection of documents can serve as the source of browsable
lists or menus. This can be highly beneficial to users, as index terms
provide an alternative to a primary organization system, such as an
information architecture organized by business unit. Index terms in
the form of indexes and other lists provide a valuable alternative
view by “cutting across the grain” of organizational silos.

The index of the SFGate website shown in Figure 7-10 is generated
from index term labels, which in turn are used to identify content
from many different sections of the site. Much of the content already
accessible through the site’s primary organization system is also
accessible by browsing these index terms (i.e., keywords).

Figure 7-10. The SFGate site index

150 | Chapter 7: Labeling 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

Frequently, index terms are completely invisible to users. The
records we use to represent documents in content management sys‐
tems and other databases typically include fields for index terms,
which are often heard but not seen: they come into play only when
you search. Similarly, index terms may be hidden as embedded met‐
adata in an HTML document’s or tags. For example, a furniture manufacturer’s website might list the following index terms in the <meta> tags of records for its upholstered items: <meta name="keywords" CONTENT="upholstery, upholstered, sofa, couch, loveseat, love seat, sectional, armchair, arm chair, easy chair, chaise lounge"> A search on “sofa” would then retrieve the page with these index terms even if the term “sofa” doesn’t appear anywhere in the page’s text. Figure 7-11 shows a similar, more delectable example from the Bon Appétit website. A search for “snack” retrieves this recipe, though there is no mention of the term in the recipe itself. “Snack” is likely stored separately as an index term in a database record for this recipe. Figure 7-11. A search for “snack” retrieves this recipe, even though the term doesn’t appear within the text Web search engines such as Google have become the primary way in which people find and access websites. Using index terms to describe a main page is an effective way for getting that page, and Labels as Headings | 151 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:00:35. 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 Search Engine Watch is the most useful resource for learning how web-wide search engines and directories work, and how you can index your site’s main and other major pages so they “rise to the top” of retrieval results. the site as a whole, indexed and “known” so that users who search the Web are more likely to find it.3 Getting your pages to stand out from one another is a different and much more daunting challenge. That’s where a more systematic approach to labeling—using index terms from controlled vocabula‐ ries or thesauri—has more value. These sets of labels are designed to describe delineated domains—such as products and services, or oncology—and to do so in a consistent, predictable manner. We’ll describe these vocabularies in great detail in Chapter 10. Iconic Labels It’s true that a picture is worth a thousand words. But which thousand? Icons can represent information in much the same way as text can. We see them most frequently used as navigation system labels, espe‐ cially in mobile apps where screen space is constrained. Addition‐ ally, icons occasionally serve as heading labels and have even been known to show up as link labels, although this is rare. The problem with iconic labels is that they constitute a much more limited language than text. That’s why they’re more typically used for navigation system or small organization system labels, where the list of options is small, than for larger sets of labels such as index terms, where iconic “vocabularies” are quickly outstripped. They also can work well for less text-oriented audiences, such as children. Even so, iconic labels are still a risky proposition in terms of whether or not they can represent meaning. Figure 7-12 shows navi‐ gation tiles on the Microsoft Band fitness tracker. What do the icons mean to you? 152 | Chapter 7: Labeling Systems 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:00:35. 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 . <blockquote class="wp-embedded-content" data-secret="BagyZh7uRy"><a href="https://www.searchenginewatch.com/">Homepage</a></blockquote> <iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; visibility: hidden;" title="“Homepage” — Search Engine Watch" src="https://www.searchenginewatch.com/embed/#?secret=yn0DQuhAqh#?secret=BagyZh7uRy" data-secret="BagyZh7uRy" width="500" height="282" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe> Figure 7-12. Icons from the Microsoft Band’s navigation system (image: https://www.microsoft.com/microsoft-band/en-us) (They are, respectively: Mail, Run, Calendar, Exercise, Sleep, Mes‐ saging, and Finance.) Even given the fairly specific context of a fitness band, most users probably won’t understand this language immediately, although they might correctly guess the meaning of one or two of these labels. Iconic labels like these add aesthetic appeal to an information envi‐ ronment, and as long as they don’t compromise the system’s usabil‐ ity, there’s no reason not to use them. In fact, the iconic “language” might get established in your users’ minds through repeated expo‐ sure. In such situations, icons are especially useful shorthand, both representational and easy to visually recognize—a double bonus. Unless your system has a patient, loyal audience of users who are willing to learn your visual language, however, we suggest using iconic labels only for environments with a limited set of options, being careful not to place form ahead of function. Designing Labels Designing effective labels is perhaps the most difficult aspect of information architecture. Language is simply too ambiguous for you to ever feel confident that you’ve perfected a label. There are always synonyms and homonyms to worry about, and different contexts influence our understanding of what a particular term means. And of course, the challenge is much more complicated if your system deals with more than one language. But even labeling conventions are questionable: you absolutely cannot assume that the label “main page” will be correctly interpreted by 100% of your system’s users. Your labels will never be perfect, and you can only hope that your efforts make a difference, as measuring label effectiveness is an extremely difficult undertaking. If it sounds to you like labeling is an art rather than a science, you’re absolutely correct. And, as in all such cases, you can forget about Designing Labels | 153 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:00:35. 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 . https://www.microsoft.com/microsoft-band/en-us finding incontrovertible rules, and hope for guidelines instead. Fol‐ lowing are some guidelines and related issues that will help you as you delve into the mysterious art of label design. General Guidelines Remember that content, users, and context affect all aspects of an information architecture, and this is particularly true with labels. Any of the variables attached to users, content, and context can drag a label into the land of ambiguity. Let’s revisit the term “pitch.” From baseball (what’s thrown) to foot‐ ball (the field where it’s played in the United Kingdom), from busi‐ ness (what’s sometimes made while riding in an elevator) to sailing (the angle of the boat in the water), there are at least 15 different def‐ initions, and it’s hard to make sure that your site’s users, content, and context will converge upon the same definition. This ambiguity makes it difficult to assign labels to describe content, and difficult for users to rely on their assumptions about what specific labels actually mean. So what can we do to make sure our labels are less ambiguous and more representational? The following two guidelines may help. Narrow the scope whenever possible If we focus our information environments on a more defined audi‐ ence, we reduce the number of possible perspectives on what a label means. Sticking to fewer subject domains achieves more obvious and effective representation. A narrower business context means clearer goals for the system, its architecture, and therefore its labels. Labeling is easier if your content, users, and context are kept simple and focused. Too many environments have tried to take on too much, achieving broad mediocrity rather than nailing a few choice tasks. Accordingly, labeling systems often cover too much ground to truly be effective. If you are planning any aspect of your environ‐ ment’s scope—who will use it, what content it will contain, and how, when, and why it should be used—erring toward simplicity will make your labels more effective. If your environment must be a jack of all trades, avoid using labels that address the entire system’s content. The obvious exceptions are the labels for global navigation systems, which do cover the entire 154 | Chapter 7: Labeling Systems 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:00:35. 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 . system. But in the other areas of labeling, modularizing and simpli‐ fying content into subsections that meet the needs of specific audi‐ ences will enable you to design more modular, simpler collections of labels to address those specific areas. This modular approach may result in separate labeling systems for different areas of your environment. For example, records in your staff directory might benefit from a specialized labeling system that wouldn’t make sense for other parts of the site, while your site-wide navigation system’s labels wouldn’t really apply to entries in the staff directory. Develop consistent labeling systems, not labels It’s also important to remember that labels, like organization and navigation systems, are systems in their own right. Some are planned systems; some aren’t. A successful system is designed with one or more characteristics that unify its members. In successful labeling systems, one characteristic is typically consistency. Why is consistency important? Because consistency means predicta‐ bility, and systems that are predictable are simply easier to learn. You see one or two labels, and then you know what to expect from the rest—if the system is consistent. This is especially important for first-time users, but consistency benefits all users by making labeling easy to learn, easy to use, and therefore invisible. Consistency is affected by many issues: Style Haphazard usage of punctuation and case is a common problem within labeling systems, and can be addressed, if not eliminated, by using style guides. Consider hiring a proofreader and pur‐ chasing a copy of Strunk & White. Presentation Similarly, consistent application of fonts, font sizes, colors, whitespace, and grouping can help visually reinforce the sys‐ tematic nature of a group of labels. Syntax It’s not uncommon to find verb-based labels (e.g., “Grooming Your Dog”), noun-based labels (e.g., “Diets for Dogs”), and question-based labels (e.g., “How Do You Paper Train Your Dog?”) all mixed together. Within a specific labeling system, Designing Labels | 155 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:00:35. 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 . consider choosing a single syntactical approach and sticking with it. Granularity Within a labeling system, it can be helpful to present labels that are roughly equal in their specificity. Exceptions (such as site indexes) aside, it’s confusing to encounter a set of labels that cover differing levels of granularity—for example, “Chinese res‐ taurants,” “Restaurants,” “Taquerias,” “Fast Food Franchises,” “Burger Kings.” Comprehensiveness People can be tripped up by noticeable gaps in a labeling sys‐ tem. For example, if a clothing retailer’s website lists “trousers,” “ties,” and “shoes,” while somehow omitting “shirts,” we may feel like something’s wrong. Do they really not carry shirts? Or did they make a mistake? Aside from improving consistency, a comprehensive scope also helps people do a better job of quickly scanning and inferring the environment’s content. Audience Mixing terms like “lymphoma” and “tummy ache” in a single labeling system can also throw people off, even if only tem‐ porarily. Consider the languages of your environment’s major audiences. If each audience uses a very different terminology, you may have to develop a separate labeling system for each audience, even if these systems are describing exactly the same content. There are other potential roadblocks to consistency. None is particu‐ larly difficult to address, but you can certainly save a lot of labor and heartache if you consider these issues before you dive into creating labeling systems. Sources of Labeling Systems Now that you’re ready to design your labeling systems, where do you start? Believe it or not, this is the easy part. Unless you’re dealing with ideas, concepts, and topics that until now were unknown to humanity, you’ll probably have something to start with. And already having a few labels generally beats starting from scratch, which can be prohibitively expensive, especially with large vocabularies. 156 | Chapter 7: Labeling Systems 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:00:35. 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 . 4 Like many information environments, Budget.com is evolving. Prior to going to press, the site implemented changes to its design and labeling that fixed many of the issues presented here. Existing labeling systems might include the labels currently on your website, or comparable or competitors’ sites. Ask yourself who might have taken this on before. Study, learn, and “borrow” from what you find in other environments. And keep in mind that a major benefit of examining existing labeling systems is that they’re systems—they’re more than groups of odd, miscellaneous labels that don’t necessarily fit together. As you look for existing labeling systems to draw upon, consider what works and what doesn’t. Which systems can you learn from, and, perhaps more importantly, which of those labels can you keep? There are a variety of sources for labels that you should examine. Your current information environment Your current website or app probably already has labeling systems by default. At least some reasonable decisions had to have been made during the course of its creation, so you probably won’t want to throw all those labels out completely. Instead, use them as a start‐ ing point for developing a complete labeling system, taking into consideration the decisions made while creating the original system. A useful approach is to capture the existing labels in a single docu‐ ment. To do so, walk through the entire system, either manually or automatically, and gather the labels. You might consider assembling them in a simple table containing a list or outline of each label and the documents it represents. Creating a labeling table is often a natu‐ ral extension of the content inventory process. It’s a valuable exer‐ cise, though we don’t recommend it for indexing term vocabularies, which are simply too large to table-ize unless you focus on small, focused segments of those vocabularies. Table 7-1 provides a breakdown of the navigation system labels on Budget Rent A Car’s main page.4 Designing Labels | 157 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:00:35. 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 . Table 7-1. Budget Rent A Car’s navigation labels Label Destination’s heading label Destination’s <TITLE> label Top-of-page navigation system labels car rental – Automobile Rental from Budget specials Daily, Weekly, Weekend Day & Monthly Specials Budget coupons and car rental deals U.S. | Budget.com car types Rental car, SUV, and truck fleet Rental Car, SUV & Truck Fleet locations find your location in USA United States Car Rentals and car rental deals at Budget.com services Smart Car Rental Services Smart Car Rental Services – Perks & Products – Budget.com customer care Customer Care contact us | customer care | Budget car sales – Great Prices on Used Rental Cars – Budget Car Sales country / language Renting outside of the U.S.? – Sign in Sign In Authentication sign in | frequent renter | Budget Reserve with customer ID – rent your car today | Budget Create customer ID Frequent Renter Account Services Car Rental Deals Body navigation system labels Rent a car in 60 seconds – rent your car today | Budget Make a Car Reservation – rent your car today | Budget Already Have a Reservation? View, Change or Cancel an Existing Reservation rent your car today | Budget Common Questions Just the FAQs Common Questions – Car Rental FAQs – Budget.com Find a Location find your location in USA United States Car Rentals and car rental deals at Budget.com Bottom-of-page navigation system labels About Budget About Us About Us – Car Rentals – Budget.com Privacy U.S. Privacy US Privacy Policy – Customer Care – Budget.com Site map Budget.com car rental site map Site Map – Car Rental, Reservations & Discounts – Budget.com 158 | Chapter 7: Labeling Systems 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:00:35. 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 . Label Destination’s heading label Destination’s <TITLE> label Contact Us Customer Care contact us | customer care | Budget Employment avis budget group Avis Budget Group Car Rental Locations find your location in USA United States Car Rentals and car rental deals at Budget.com Budget Worldwide Budget Rental Car Locations: Worldwide Budget Car Rentals Locations Worldwide – Budget US & Canada Budget Rental Car Locations: World Budget Car Rentals Locations – Budget Major Airports Popular Airport Car Rental Locations Airport Car Rental Locations from Budget.com Orlando Car Rental Orlando Car Rental Orlando Car Rental – Rent a Car in Orlando, Florida at Budget.com Featured Rentals Popular Available Car Types Available Car Types from Budget.com Van Rentals Van Car Rental Van Rental – Passenger Van rental from Budget Car Rental Deals Budget Coupons at Budget.com Budget Rental Car Coupons – Save On a Budget Car Rental One Way Car Rental One Way Car Rental One Way Car Rental – Budget offers special deals on one way car rentals Monthly Car Rental Long Term Car Rental Monthly Car Rental – Save more with long term car rental Featured Products Smart Car Rental Services Smart Car Rental Services – Perks & Products – Budget.com Small Business Rentals Budget Business Program company account | frequent renters | Budget Car in the shop? Reservations Budget Reservations – Vehicle Replacement Budget Mobile Apps The Budget Mobile App Budget Rent A Car – Budget Mobile Go Green – Rent Clean Go Greener. Drive Cleaner. Green Car Rental – Rent an Eco-Friendly Vehicle – Budget.com Business accounts U.S. Budget Business Program® Budget Business Car Rental Program – Budget.com Partners Partners Partners, Affiliates, Travel Agents – Budget.com Affiliates Travel Affiliate Program affiliates | partners | about us | Budget Travel agents Car Rental Services for Travel Agents Rent A Car at Budget – Travel Agents Car sales Love it. Buy it. Car Sales – Buy Used Cars from Budget Designing Labels | 159 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:00:35. 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 . Label Destination’s heading label Destination’s <TITLE> label Budget is your earth friendly alternative Go Greener. Drive Cleaner. Green Car Rental – Rent an Eco-Friendly Vehicle – Budget.com Arranging labels in a table provides a more condensed, complete, and accurate view of navigation labels as a system. Inconsistencies are easier to catch; in Budget’s case, we encounter three variants of the company’s name: “Budget,” “Budget Rent A Car,” and “Budget.com.” We find inconsistencies for a single page’s labels: the contact page is labeled “Contact Us” and “Customer Care.” Some pages don’t have main headings. We encounter various other style and capitalization inconsistencies that may confuse users. We may decide that, personally, we just don’t like certain labels. We may also decide that some of the problems aren’t worth changing. In any case, we now have a sense of the site’s current labeling system and how it could be improved. Comparable and competitive environments If you don’t have a website or app in place or are looking for new ideas, look elsewhere for labeling systems. The open nature of the Web allows us to learn from one another. So, just as you might view the source of a wonderfully designed page, you can learn from another site’s great labeling system. Determine beforehand what your audiences’ needs are most likely to be, and then surf your competitors’ sites, borrowing what works and noting what doesn’t (you might consider creating a label table for this specific purpose). If you don’t have competitors, visit compara‐ ble sites or sites that seem to be best in class. As we mentioned in Chapter 4, the Web is already old enough to have produced various industry-specific typologies. If you explore multiple competitive or comparative environments, you may find that labeling patterns emerge. These patterns may not yet be indus‐ try standards, but they at least can inform your choice of labels. For example, in a competitive analysis of eight financial services sites “personal finance” was found to be more or less the de facto label choice, compared to its synonyms. Such data may discourage you from using a different label. 160 | Chapter 7: Labeling Systems 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:00:35. 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 7-13 shows labeling systems from United, Delta, Virgin America, and American Airlines, all competing in the airline busi‐ ness. Do you notice trends and differences here? Just a glance shows how much variation there is in terms of the number of labels (from five to as many as nine). Some use the “My…” approach, and some use brand-specific labels (e.g., “AAdvantage”). Task-based labels (e.g., “Book a trip”) are less common than one would expect, as is the use of a “Home” or “Main” option. Figure 7-13. Labeling systems from United, Delta, Virgin America, and American Airlines Controlled vocabularies and thesauri Another great source for labels is existing controlled vocabularies and thesauri (a topic we’ll cover in depth in Chapter 10). These especially useful resources are created by professionals with library or subject-specific backgrounds, who have already done much of the work of ensuring accurate representation and consistency. These vocabularies are often publicly available and have been designed for broad usage. You’ll find these to be most useful for populating label‐ ing systems used for indexing content. Designing Labels | 161 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:00:35. 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 . Seek out narrowly focused vocabularies that help specific audiences to access specific types of content. For example, if your system’s users are computer scientists, a computer science thesau‐ rus “thinks” and represents concepts in a way your users are likely to understand, more so than a general scheme like the Library of Con‐ gress subject headings would. A good example of a specific controlled vocabulary is the Educa‐ tional Resources Information Center (ERIC) Thesaurus. This the‐ saurus was designed, as you’d guess, to describe the domain of education. An entry in the ERIC Thesaurus for “scholarship” is shown in Figure 7-14. Figure 7-14. Controlled vocabularies and thesauri are rich sources of labels If your environment has to do with education or if your audience is comprised of educators, you might start with ERIC as the source for your system’s labels. You can use a thesaurus like ERIC to help you with specific labeling challenges, like determining a better variant for a particularly knotty label. You might go as far as to license the entire vocabulary and use it as your system’s labeling system. Unfortunately, there aren’t controlled vocabularies and thesauri for every domain. Sometimes you may find a matching vocabulary that 162 | Chapter 7: Labeling Systems 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:00:35. 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 . emphasizes the needs of a different audience. Still, it’s always worth seeing if a potentially useful controlled vocabulary or thesaurus exists before creating labeling systems from scratch. Try these excel‐ lent resources as you hunt for sources of labels: • Taxonomy Warehouse • American Online Thesauri and Authority Files (American Soci‐ ety for Indexing) Creating New Labeling Systems When there are no existing labeling systems that meet your needs, or when you need to do more customizing than you’d expected, you face the tougher challenge of creating labeling systems from scratch. Your most important sources are your content (and potentially its authors), and the people who will be using your environment. Content analysis Labels can come directly from your content. You might read a repre‐ sentative sample of your environment’s content and jot down a few descriptive keywords for each document along the way. It’s a slow and painful process, and it obviously won’t work with a huge set of documents. If you go this route, look for ways to speed up the pro‐ cess by focusing on any existing content representations like titles, summaries, and abstracts. Analyzing content for candidate labels is certainly another area where art dominates science. There are software tools available that can perform auto-extraction of meaningful terms from content. These tools—typically referred to as “entity extraction” applications—can save you quite a bit of time if you face a huge body of content; like many software-based solutions, auto-extraction tools may get you 80% of the way to the finish line. You’ll be able to take the terms that are output by the software and use them as candidates for a controlled vocabulary, but you’ll still need to do a bit of manual labor to make sure the output actually makes sense. (And it’s worth noting that auto-extraction tools—and the training and tuning required to make them work well—can be quite expensive.) Designing Labels | 163 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:00:35. 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://taxonomywarehouse.com/ http://bit.ly/online_thesauri http://bit.ly/online_thesauri Content authors Another manual approach is to ask content authors to suggest labels for their own content. This might be useful if you have access to authors; for example, you could talk to your company’s researchers who create technical reports and white papers, or to the PR people who write press releases. However, even when authors select terms from a controlled vocabu‐ lary to label their content, they don’t necessarily do it with the reali‐ zation that their documents are only one of many in a broader collection. So, they might not use sufficiently specific labels. Also, few authors happen to be professional indexers. So take their labels with a grain of salt, and don’t rely upon them for accuracy. As with other sources, labels from authors should be con‐ sidered useful candidates for labels, not final versions. User advocates and subject matter experts Another approach is to find advanced users or user advocates who can speak on the users’ behalf. Such people may include librarians, switchboard operators, or subject matter experts (SMEs) who are familiar with the users’ information needs in a larger context. Some of these people—reference librarians, for example—keep logs of what people want; all will have a good innate sense of people’s needs by dint of constant interaction. We found that talking to user advocates was quite helpful when working with a major healthcare system. Working with its library’s staff and SMEs, we set out to create two labeling systems: one with medical terms to help medical professionals browse the services offered by the healthcare system, the other for the lay audience to access the same content. It wasn’t difficult to come up with the med‐ ical terms because there are many thesauri and controlled vocabula‐ ries geared toward labeling medical content. It was much more difficult to come up with a scheme for the layperson’s list of terms. There didn’t seem to be an ideal controlled vocabulary, and we couldn’t draw labels from the site’s content because it hadn’t been created yet. So we were truly starting from scratch. We solved this dilemma by using a top-down approach: we worked with the librarians to determine what they thought users wanted out of the system. We considered their general needs, and came up with a few major ones: 164 | Chapter 7: Labeling Systems 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:00:35. 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 need information about a problem, illness, or condition. • The problem is with a particular organ or part of the body. • They want to know about the diagnostics or tests that the healthcare professionals will perform to learn more about the problem. • They need information on the treatment, drug, or solution that will be provided by the healthcare system. • They want to know how they can pay for the service. • They want to know how they can maintain their health. We then came up with basic terms to cover the majority of these six categories, taking care to use terms appropriate to this audience of laypersons. Table 7-2 shows some examples. Table 7-2. Sample laypersons’ labels for identified categories Category Sample labels Problem/illness/condition HIV, fracture, arthritis, depression Organ/body part Heart, joints, brain Diagnostics/tests Blood pressure, X-ray Treatment/drug/solution Hospice, bifocals, joint replacement Payment Administrative services, health maintenance organization, medical records Health maintenance Exercise, vaccination By starting with a few groupings, we were able to generate labels to support indexing. We knew a bit about the audience (laypersons), and so were able to generate the right kinds of terms to support their needs (e.g., leg instead of femur). The secret was working with peo‐ ple (in this case, staff librarians) who were knowledgeable about the kind of information people want. Users (directly) The actual users of a system may be able to tell you what the labels should be. This isn’t the easiest information to get your hands on, but if you can, it’s the best source of labeling there is. Designing Labels | 165 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:00:35. 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 Donna Spencer’s book Card Sorting: Designing Usable Categories (Brooklyn, NY: Rose‐ nfeld Media, 2011) is quite helpful here. Card sorting. Card sort exercises are one of the best ways to learn how your users would use information.5 (Card sorting methodolo‐ gies are covered more extensively in Chapter 11.) There are two basic varieties of card sorts: open and closed. Open card sorts allow participants to cluster labels for existing content into their own cate‐ gories and then label those categories (and clearly, card sorting is useful when designing organization systems as well as labeling sys‐ tems). Closed card sorts provide participants with existing categories and ask them to sort content into those categories. At the start of a closed card sort, you can ask users to explain what they think each category label represents and compare these definitions to your own. Both approaches are useful ways to determine labels, although they’re more appropriate for smaller sets of labels such as those used for navigation systems. In the following example, we asked participants to categorize cards from the owner’s section of a website for a large automotive com‐ pany (let’s call it “Tucker”). After we combined the data from this open card sort, we found that participants labeled the combined cat‐ egories in different ways. “Maintenance,” “maintain,” and “owner’s” were often used in labels for the first cluster, indicating that these were good candidates for labels (see Table 7-3). Table 7-3. Cluster 1 Participant Identified categories Participant 1 Ideas & maintenance Participant 2 Owner’s guide Participant 3 Items to maintain car Participant 4 Owner’s manual Participant 5 Personal information from dealer Participant 6 [No response] Participant 7 Maintenance upkeep & ideas Participant 8 Owner’s tip AND owner’s guide and maintenance But in other cases, no strong patterns emerged (see Table 7-4). 166 | Chapter 7: Labeling Systems 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:00:35. 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 . Table 7-4. Cluster 2 Participant Identified categories Participant 1 Tucker features Participant 2 [No response] Participant 3 Shortcut for info on car Participant 4 Auto info Participant 5 Associate with dealer Participant 6 Tucker website info Participant 7 Manuals specific to each car Participant 8 [No response] In a corresponding closed card sort, we asked participants to describe each category label before they grouped content under each category. In effect, we were asking participants to define each of these labels, and we compared their answers to see if they were simi‐ lar or not. The more similar the answers, the stronger the label. Some labels, such as “Service & Maintenance,” were commonly understood, and were in line with the content that you’d actually find listed under that category (see Table 7-5). Table 7-5. Service & Maintenance Participant Identified content Participant 1 When to change the fluids, rotate tires; a place to keep track when I had my vehicle in for service (sic) Participant 2 How to maintain vehicle: proper maintenance, features of car, where to find fuse box, etc., owner’s manual Participant 3 Find service that might be open on Sunday sometimes Participant 4 When I will need service and where to go to get it Participant 5 Reminders on when services is recommended (sic) Participant 6 Timeline for service and maintenance Participant 7 Maintenance schedule and tips to get best performance out of car and longevity of car Participant 8 Maintenance tips, best place to go to fix car problem, estimated price Other category labels were more problematic. Some participants understood “Tucker Features & Events” in the way that was intended, representing announcements about automobile shows, discounts, and so on. Others interpreted this label to mean a Designing Labels | 167 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:00:35. 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 The best summary of this method is Rashmi Sinha’s short but highly useful article, “Beyond Cardsorting: Free-Listing Methods to Explore User Categorizations,” Boxes & Arrows, February 2003 (http://bit.ly/beyond_cardsorting). vehicle’s actual features, such as whether or not it had a CD player (see Table 7-6). Table 7-6. Tucker Features & Events Participant Identified content Participant 1 New items for my vehicle; upcoming new styles—new makes & models; financial news—like 0% financing Participant 2 Local & national sponsorship; how to obtain Tucker sponsorship; community involvement Participant 3 Mileage, CD or cassette, leg room, passengers, heat/AC control dull or not, removable seats, automatic door openers Participant 4 All information regarding the Tucker automobile I’m looking for and any sale events going on regarding this auto Participant 5 Looking for special pricing events Participant 6 Site for outlining vehicles and options available. What automobile shows are available and where. Participant 7 About Tucker, sales, discounts, special events Participant 8 No interested (sic) Card sort exercises are very informative, but it’s important to recog‐ nize that they don’t present labels in the context of an actual prod‐ uct. Without this natural context, the labels’ ability to represent meaning is diminished. So, like all other techniques, card sorts have value but shouldn’t be seen as the only method of investigating label quality. Free-listing. While card sorting isn’t necessarily an expensive and time-consuming method, free-listing is an even lower-cost way to get users to suggest labels.6 Free-listing is quite simple: select an item and have participants brainstorm terms to describe it. You can do this in person (capturing data with pencil and paper will be fine) or remotely, using a free or low-cost online survey tool like Survey‐ Monkey, Zoomerang, or Google Forms. That’s really all there is to it. Well, not quite: you’ll want to consider your participants: who (ide‐ ally representative of your overall audience) and how many (three to 168 | Chapter 7: Labeling Systems 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:00:35. 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/beyond_cardsorting five may not yield scientifically significant results, but it is certainly better than nothing and may yield some interesting results). You might also consider asking participants to rank the terms they’ve suggested as a way to determine which are the most appropriate. You’ll also need to choose which items to brainstorm terms for. Obviously you can only do this with a subset of your content. You could choose some representative content, such as a handful of your company’s products. But even then, it’ll be tricky—do you choose the most popular products or the more esoteric ones? It’s important to get the labeling right for your big sellers, but conventions for their labels are already fairly established. The esoteric items? Well, they’re more challenging, but fewer people care about them. So you may end up with a balance among the few items you select for a free-listing exercise. This is one of those cases where the art of infor‐ mation architecture is at least as important as the science. What do you do with the results? Look for patterns and frequency of usage; for example, perhaps most of your participants use the term “cell phone” while surprisingly few prefer “mobile phone.” Patterns like these not only can provide you with a sense of how to label an individual item, but may also demonstrate the tone of users’ lan‐ guage overall. You might note that they use jargon quite a bit, or the reverse; perhaps you find a surprising amount of acronyms in their labels, or some other pattern emerges from free listing. The result won’t be a full-fledged labeling system, but it will give you a better sense of what tone and style you should take when developing a labeling system. Users (indirectly) Most organizations—especially those whose information environ‐ ments include search engines—are sitting on top of reams of user data that describe users’ needs. Analyzing those search queries can be a hugely valuable way to tune labeling systems, not to mention to diagnose a variety of other problems with your system. Additionally, the popularization of free-form tagging in social networks has cre‐ ated a valuable, if indirect, source of data on users’ needs that can help in the creation of labeling systems. Search log analysis. Search log analysis (also known as search analyt‐ ics) is one of the least intrusive sources of data on the labels your Designing Labels | 169 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:00:35. 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 . 7 For more on search analytics, an excellent resource is Lou’s book Search Analytics for Your Site: Conversations with Your Customers (Brooklyn, NY: Rosenfeld Media, 2011). site’s audiences actually use. Analyzing search queries7 is a great way to understand the types of labels your site’s visitors typically use (see Table 7-7). After all, these are the labels that users utilize to describe their own information needs in their own language. You may notice the use of acronyms (or lack thereof), product names, and other jar‐ gon, which could impact your own willingness to use jargony labels. You might notice that users’ queries use single or multiple terms, which could affect your own choice of short or long labels. And you might find that people simply aren’t using the terms you thought they would for certain concepts. You may decide to change your labels accordingly, or use a thesaurus-style lookup to connect a user- supplied term (e.g., “pooch”) to the preferred term (e.g., “dog”). Table 7-7. 40 common queries from Michigan State University’s site; each query tells us something about what the majority of users seek most often and how they label their information needs Rank Count Cumulative Percent of total Query 1 1184 1184 1.5330 capa 2 1030 2214 2.8665 lon+capa 3 840 3054 3.9541 study+abroad 4 823 3877 5.0197 angel 5 664 4541 5.8794 lon-capa 6 656 5197 6.7287 library 7 584 5781 7.4849 olin 8 543 6324 8.1879 campus+map 9 530 6854 8.8741 spartantrak 10 506 7360 9.5292 cata 11 477 7837 10.1468 housing 12 467 8304 10.7515 map 13 462 8766 11.3496 im+west 14 409 9175 11.8792 computer+store 15 399 9574 12.3958 state+news 16 395 9969 12.9072 wharton+center 17 382 10351 13.4018 chemistry 18 346 10697 13.8498 payroll 170 | Chapter 7: Labeling Systems 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:00:35. 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 . Rank Count Cumulative Percent of total Query 19 340 11037 14.2900 breslin+center 20 339 11376 14.7289 honors+college 21 339 11715 15.1678 calendar 22 334 12049 15.6002 human+resources 23 328 12377 16.0249 registrar 24 327 12704 16.4483 dpps 25 310 13014 16.8497 breslin 26 307 13321 17.2471 tuition 27 291 13612 17.6239 spartan+trak 28 289 13901 17.9981 menus 29 273 14174 18.3515 uab 30 267 14441 18.6972 academic+calendar 31 265 14706 19.0403 im+east 32 262 14968 19.3796 rha 33 262 15230 19.7188 basketball 34 255 15485 20.0489 spartan+cash 35 246 15731 20.3674 loncapa 36 239 15970 20.6769 sparty+cash 37 239 16209 20.9863 transcripts 38 224 16433 21.2763 psychology 39 214 16647 21.5534 olin+health+center 40 206 16853 21.8201 cse+101 Another—perhaps less obvious—way to obtain search terms is by using Google AdWords to see what terms people are searching for. These terms can then inform the labeling of your information environment. Tuning and Tweaking Your list of labels might be raw, coming straight from your content, another system, your environment’s users, or your own ideas of what should work best. Or, it may come straight from a polished controlled vocabulary. In any 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., from a search log), you’ll likely encounter some duplicates; remove these. Designing Labels | 171 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:00:35. 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 . Then review the list for consistency of usage, punctuation, letter case, and so forth, considering some of the consistency issues dis‐ cussed earlier in this chapter. This is a good time to resolve these inconsistencies and to establish conventions for punctuation and style. Decisions about which terms to include in a labeling system need to be made in the context of how broad and how large a system is required. First, determine if the labeling system has obvious gaps. Does it encompass all the possibilities that your environment may eventually need to include? If, for example, your online store currently allows users to search only a portion of your product database, ask yourself if eventually it might provide access to all products. If you’re not certain, assume it will, and devise appropriate labels for the additional products. If the environment’s labeling system is topical, try to anticipate the topics not yet covered. You might be surprised to see that the addi‐ tion of these “phantom” labels has a large impact on your labeling system, perhaps even requiring you to change its conventions. If you fail to perform this predictive exercise, you might learn the hard way that future content doesn’t fit into your system because you’re not sure how to label it, or it ends up in cop-out categories such as “Mis‐ cellaneous,” “Other Info,” and the classic “Stuff.” Plan ahead so that labels you might add in the future don’t throw off the current label‐ ing system. Of course, this planning should be balanced with an understanding of what your labeling system is there to accomplish today. If you try to create a labeling system that encompasses the whole of human knowledge (instead of the current and anticipated content of your website), don’t plan on doing anything else for the rest of your life. Keep your scope narrow and focused enough so that it can clearly address the requirements of your environment’s unique content, the special needs of its audiences, and the business objective at hand, but be comprehensive within that well-defined scope. This is a diffi‐ cult pursuit, to be sure—all balancing acts are. Finally, remember that the labeling system you launch will need to be tweaked and improved shortly thereafter. That’s because labels represent a relationship between two things—people and content— that is constantly changing. Stuck between two moving targets, your labeling system will also have to change. So be prepared to perform 172 | Chapter 7: Labeling Systems 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:00:35. 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 . usability tests, analyze search logs on a regular basis, and adjust your labeling system as necessary. Recap OK, let’s recap what we learned in this chapter: • We label things all the time. • Labeling is the most obvious way to show our organization schemes across multiple systems and contexts. • We must try to design labels that speak the same language as our environment’s users, while also reflecting its content. • Textual labels are the most common type we encounter in our work; they include contextual links, headings, navigation system options, and index terms. • Iconic labels are less common, but the widespread adoption of devices with less screen real estate means that they are an important component of many information environments. • Designing labels is one of the most difficult aspects of informa‐ tion architecture. • That said, there are various sources of inspiration—such as your existing information environment and search log analysis—that can help inform your labeling choices. Let’s now move on to Chapter 8, where we’ll dig into one of the mainstays of effective information architectures: navigation systems. Recap | 173 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:00:35. 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 . 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:00:35. 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . http://www.useit.com/alertbox/9609.html 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 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 . 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 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 . 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 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 . 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 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 . 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 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 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 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 . 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 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 . • 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . • 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . 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 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 . • 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 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 . 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 . CHAPTER 9 Search Systems The ultimate search engine would basically understand everything in the world, and it would always give you the right thing . And we’re a long, long ways from that. —Larry Page In this chapter, we’ll cover: • Determining whether your product needs a search system • The basic anatomy of a search system • What to make searchable • A basic understanding of retrieval algorithms • How to present retrieval results • Search interface design • Where to learn more Chapter 8 helped you understand how to create the best navigation system possible for your information environment. This chapter describes another form of finding information: searching. Searching (and more broadly, information retrieval) is an expansive, challeng‐ ing, and well-established field, and we can only scratch the surface here. We’ll limit our discussion to what makes up a search system, when to implement search systems, and some practical advice on how to design a search interface and display search results. This chapter often uses examples of search systems that allow you to search various different types of information environments, ranging 211 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:55. 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 . from the entire Web to mobile phone apps. Although these tools tend to index a very broad collection of content, it’s nonetheless extremely useful to study them. Does Your Product Need Search? Before we delve into search systems, we need to make a point: think twice before you make your product searchable. Your information environment should, of course, support the find‐ ing of its information. But as the preceding chapters demonstrate, there are other ways to support finding. And be careful not to assume, as many do, that a search engine alone will satisfy all users’ information needs. While many users want to search, some are nat‐ ural browsers, preferring to forgo filling in that little search box and hitting the “search” button. We suggest you consider the following issues before committing to a search system: Amount of content in the information environment How much content is enough to merit the use of a search engine? It’s hard to say. It could be 5, 50, or 500 content items; no specific number serves as a standard threshold. What’s more important is the type of information need that’s typical of your product’s users. For example, users of a technical support web‐ site often have a specific kind of information in mind, and are more likely to require search than users of an online banking app. If your product is more like a library than a software appli‐ cation, then search probably makes sense. If that’s the case, then consider the volume of content, balancing the time required to set up and maintain a search system with the payoff it will bring to your product’s users. Focus on more useful navigation systems Because many developers see search engines as the solution to the problems users have when trying to find information in their products, search engines become Band-Aids for poorly designed navigation systems and other architectural weak‐ nesses. If you see yourself falling into this trap, you should prob‐ ably suspend implementing your search system until you fix your navigation system’s problems. You’ll find that search sys‐ tems often perform better if they can take advantage of aspects of strong navigation systems, such as the controlled vocabulary terms used to tag content. And users will often benefit even 212 | Chapter 9: Search Systems 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:55. 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 . more from using both types of finding if they work together well. Of course, your product’s navigation might be a disaster for political reasons, such as an inability among your organiza‐ tion’s decision makers to agree on a system-wide navigation sys‐ tem. In such cases, reality trumps what ought to be, and search might indeed be your best alternative. Time and know-how to optimize the search system Search engines are fairly easy to get up and running, but they are difficult to implement effectively. As a user of the Web, you’ve certainly seen incomprehensible search interfaces, and we’re sure that your queries have retrieved some pretty inscruta‐ ble results. This is often due to a lack of planning by the site’s developer, who probably installed the search engine with its default settings, pointed it at the site, and forgot about it. If you don’t plan on putting some significant time into configuring your search engine properly, reconsider your decision to imple‐ ment it. Other alternatives Search may be a good way to serve your product’s users, but other ways may work better. For example, if you don’t have the technical expertise or confidence to configure a search engine or the money to shell out for one, consider providing an index instead. Both indexes and search engines help users who know what they’re looking for. While an index can be a heck of a lot of work, it is typically created and maintained manually, which makes it easier to implement. You could also provide access to a third-party search engine, such as Google’s. (While this is a cost- effective alternative, it has downsides: for one, search becomes separate from other means of finding, leading to a disjointed experience. For another, delegated search can’t generate the same data—and insights—from search analytics.) Users’ preferred ways of interacting It may already be clear that your users would rather browse than search. For example, users of a handmade crafts site may prefer browsing thumbnails of cards instead of searching. Or perhaps users do want to search, but searching is a lower priority for them, and it should be for you as you consider how to spend your information architecture development budget. Does Your Product Need Search? | 213 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:55. 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 . Now that we’ve got our warnings and threats out of the way, let’s dis‐ cuss when you should implement search systems. Many information environments—websites, especially—aren’t planned out in much detail before they’re built. Instead, they grow organically. This may be all right for smaller systems that aren’t likely to expand much, but for ones that become popular, more and more content and func‐ tional features get piled on haphazardly, leading to a navigation nightmare. The following issues will help you decide when your environment has reached the point of needing a search system: Search helps when you have too much information to browse There’s a good analogy with physical architecture here. Powell’s Books, which claims to be the largest bookstore in the world, covers an entire city block (68,000 square feet) in Portland, Ore‐ gon. We guess that it started as a single small storefront on that block, but as the business grew, the owners knocked a doorway through the wall into the next storefront, and so on, until it occupied the whole block. The result is a hodgepodge of cham‐ bers, halls with odd turns, and unexpected stairways. This cha‐ otic labyrinth is a charming place to wander and browse, but if you’re searching for a particular title, good luck. It will be diffi‐ cult to find what you’re looking for, although if you’re really lucky you might serendipitously stumble onto something better. Yahoo! once was a web version of Powell’s. At first, everything was there and fairly easy to find. Why? Because Yahoo!, like the Web, was relatively small. At its inception, Yahoo! pointed to a few hundred Internet resources, made accessible through an easily browsable subject hierarchy. No search option was avail‐ able, something unimaginable to Yahoo! users today. But things soon changed. Yahoo! had an excellent technical architecture that allowed site owners to easily self-register their sites, but Yahoo!’s information architecture couldn’t keep up with the increasing volume of resources that were added daily. Eventu‐ ally, the subject hierarchy became too cumbersome to navigate, and Yahoo! installed a search system as an alternative way of finding information. In 2014, Yahoo! discontinued its browsable site directory altogether. Your information environment probably isn’t as large as Yahoo!, but it’s probably experienced a similar evolution. Has your con‐ tent outstripped your browsing systems? Do your site’s users go 214 | Chapter 9: Search Systems 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:55. 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.powells.com http://www.powells.com insane trying to spot the right link on your hugely long category pages? Then perhaps the time has come for search. Search helps fragmented sites Powell’s room after room after room of books is also a good analogy for the silos of content that make up so many intranets and large public websites. As is so often the case, each business unit has gone ahead and done its own thing, developing content haphazardly with few (if any) standards, and probably no meta‐ data to support any sort of reasonable browsing. If this describes your situation, you have a long road ahead of you, and search won’t solve all of your problems—let alone your users’ problems. But your priority should be to set up a search system to perform full-text indexing of as much system content as possible, even across such traditional silos as company departments. Even if it’s only a stopgap, search will address your users’ dire need for finding information regardless of which business unit actually owns it. Search will also help you to get a better handle on what content is actually out there. Search is a learning tool Through search-log analysis, which we touched on in Chap‐ ter 7, you can gather useful data on what users actually want from your information environment, and how they articulate their needs (in the form of search queries). Over time, you can analyze this valuable data to diagnose and tune your search sys‐ tem, other aspects of its information architecture, the perfor‐ mance of its content, and many other areas as well. Search should be there because users expect it to be there Your product probably doesn’t contain as much content as Yahoo!, but if it’s substantial, it probably merits a search engine. There are good reasons for this. Users won’t always be willing to browse through its structures; their time is limited, and their cognitive-overload threshold is lower than you think. Interest‐ ingly, sometimes users won’t browse for the wrong reasons— that is, they search when they don’t necessarily know what to search for and would be better served by browsing. But perhaps most of all, users expect that little search box wherever they go. It’s a default convention, and it’s hard to stand against the wave of expectations. Does Your Product Need Search? | 215 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:55. 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 . Search can tame dynamism You should also consider creating a search system for your product if it contains highly dynamic content. For example, an online newspaper might be adding dozens of story files daily via a commercial newsfeed or some other form of content syndica‐ tion. For this reason, its team probably wouldn’t have the time each day to manually catalog its content or maintain elaborate tables of contents and site indexes. A search engine could help by automatically indexing the contents of the site once or many times daily. Automating this process ensures that users have quality access to the newspaper’s content, and the team can spend time doing things other than manually indexing and link‐ ing the story files as they come in. Search System Anatomy On its surface, search seems quite straightforward. Look for the box with the search button, enter and submit your query, and mutter a little prayer while the results load. If your prayers are answered, you’ll find some useful results and can go on with your life. Of course, there’s a lot going on under the hood. A search engine application has indexed the content of the information environ‐ ment. All of it? Some of it? As a user, you’ll probably never know. And what parts of the content? Usually the search engine can find the full text of each document. But a search engine can also index information associated with each document—like titles, controlled vocabulary terms, etc.—depending on how it’s been configured. And then there’s the search interface, your window on the search engine’s index. What you type there is looked up in the index; if things go well, results that match your query are returned. A lot is going on here. There are the guts of the search engine itself; aside from tools for indexing and spidering, there are algorithms for processing your query into something the software can understand, and for ranking the results. There are interfaces, too: ones for enter‐ ing queries (everything from simple search boxes to advanced natural-language, voice-driven interfaces like Siri) and others for displaying results (including decisions on what to show for each result, and how to display the entire set of results). Further compli‐ cating the picture, there may be variations in query languages (e.g., whether or not Boolean operators like AND, OR, and NOT can be 216 | Chapter 9: Search Systems 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:55. 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 . used) and query builders (e.g., spell checkers) that can improve upon a query. Obviously, there’s a lot to search that doesn’t meet the eye. Addition‐ ally, there’s your query, which itself usually isn’t very straightfor‐ ward. Where does your query come from? Your mind senses a gap that needs to be filled with information, but isn’t always sure how to express what it’s looking for. Searching is often iterative—not just because we don’t always like the results we retrieve, but often because it takes us a few tries to get the words right for our query. You then interact with a search interface, heading for the simple, Google-like box or, if you’re “advanced,” grappling with the advanced search interface. And finally, you interact with the results, hopefully quickly determining which results are worth clicking through, which to ignore, and whether or not you should go back and try modifying your search. Figure 9-1 shows some of these pathways. Figure 9-1. The basic anatomy of a search system (image adapted from Search Patterns: Design for Discovery, by Peter Morville and Jeffery Callender) That’s the 50,000-foot view of what’s happening in a search system. Most of the technical details can be left to your IT staff; you are more concerned with factors that affect retrieval performance than with the technical guts of a search engine. That said, it’s important that the team responsible for the environment’s information archi‐ tecture be part of the search system selection and implementation processes. The team must be prepared to argue strongly for owning at least an equal responsibility for selecting and implementing the search engine that will best serve users, rather than the one that runs on someone’s favorite platform or is written in someone’s favorite programming language. Search System Anatomy | 217 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:55. 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 . Choosing What to Index Let’s assume that you’ve already chosen a search engine. What con‐ tent should you index for searching? You can point your search engine at your content, tell it to index the full text of every docu‐ ment it finds, and let it do its thing. That’s a large part of the value of search systems—they can be comprehensive and can cover a huge amount of content quickly. But indexing everything doesn’t always serve users well. In a large, complex environment chock-full of heterogeneous subsystems and databases, you may want to allow users to search the silo of technical reports or the staff directory without muddying their search results with the latest HR newsletter articles on the addition of fish sticks to the cafeteria menu. The creation of search zones—pockets of more homogeneous content—reduces the apples-and-oranges effect and allows users to focus their searches. Choosing what to make searchable isn’t limited to selecting the right search zones. Each document or record in a collection has some sort of structure, whether rendered in a markup language like HTML or database fields. In turn, that structure stores content components: pieces or “atoms” of content that are typically smaller than a docu‐ ment. Some of that structure—say, an author’s name—may be lever‐ aged by a search engine, while other parts—such as the legal disclaimer at the bottom of each page—might be left out. Finally, if you’ve conducted an inventory and analysis of your con‐ tent, you already have some sense of what content is “good.” You might have identified your valuable content by manually tagging it or through some other mechanism. You might consider making this “good” stuff searchable on its own, in addition to being part of the global search. You might even program your search engine to search this “good” stuff first, and expand to search the rest of the content if that first pass doesn’t retrieve useful results. For example, if most of an ecommerce site’s users are looking for products, those could be searched by default, and the search could then be expanded to cover the whole site as part of a revised search option. In this section, we’ll discuss issues of selecting what should be searchable both at a coarse level of granularity (search zones) and at the more atomic level of searching within documents (content components). 218 | Chapter 9: Search Systems 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:55. 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 . Determining Search Zones Search zones are subsets of an information environment that have been indexed separately from the rest of the content. When a user searches a search zone, he has, through interaction with the envi‐ ronment, already identified himself as interested in that particular information. Ideally, the search zones correspond to his specific needs, and the result is a better search experience. By eliminating content that is irrelevant to his need, the user should retrieve fewer, more relevant, results. In Windows 8.1, shown in Figure 9-2, users can select search zones based on the type of content they are looking for (Settings, Files) and—somewhat awkwardly—by its location (Web images, Web vid‐ eos), with “Web” implying that the “Settings” and “Files” options refer to settings and files on your computer. (Note that “Every‐ where” is the default selection.) But what if the user wants to search for something other than videos or images on the Web? Or, inver‐ sely, wants to search for videos or images on her computer? Figure 9-2. Search zones in Windows 8.1 Although both the search box and the search result screen in Win‐ dows 8.1 present a single and consistent user interface for all searches, behind the scenes the system is rendering results from two very different search zones: the user’s computer system in the case of Choosing What to Index | 219 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:55. 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 . settings and files, and the entire Web (via Microsoft’s Bing search engine) in the case of images and videos. You can create search zones in as many ways as you can physically segregate documents or logically tag them. Your decisions in select‐ ing your environment’s organization schemes often help you deter‐ mine search zones as well. So, our old friends from Chapter 6 can also be the basis of search zones: • Content type • Audience • Role • Subject/topic • Geography • Chronology • Author • Department/business unit And so on. Like browsing systems, search zones allow a large body of content to be sliced and diced in useful new ways, providing users with multiple “views” of the environment and its content. But, natu‐ rally, search zones are a double-edged sword. Narrowing one’s search through search zones can improve results, but interacting with them adds a layer of complexity. So be careful: many users will ignore search zones when they begin their searches, opting to enter a simple search against the global index. Users might not bother with your meticulously created search zones until they’re taking their second pass at a search, via an advanced search interface. Following are a few ways to slice and dice. Navigation versus destination Most content-heavy information environments contain, at mini‐ mum, two major types of pages or screens: navigation pages and des‐ tination pages. Destination pages contain the actual information you want: sports scores, book reviews, software documentation, and so on. Navigation pages may include main pages, search pages, and pages that help you browse the environment. The primary purpose of navigation pages is to get you to the destination pages. 220 | Chapter 9: Search Systems 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:55. 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 . When a user searches an information environ‐ ment, it’s fair to assume that he is looking for destination pages. If navigation pages are included in the retrieval process, they will just clutter up the retrieval results. Let’s take a simple example: your company sells electronics accesso‐ ries via its website. The destination pages consist of descriptions, pricing, and ordering information, one page for each product. Also, a number of navigation pages help users find products, such as list‐ ings of products for different device types (e.g., tablets versus smart‐ phones), listings of products for different types of accessories (e.g., screen protectors, cases), and listings of different device manufac‐ turers (e.g., Apple, Samsung, LG). If the user is searching for Mophie iPhone cases, what’s likely to happen? Instead of simply retrieving the Mophie’s product page, she might have to wade through all of these pages: • iPhone cases index page • External batteries index page • Apple devices products index page • Mophie products index page • Android products index page • Mophie iPhone products index page The user’s search retrieves the right destination page (i.e., the Mophie iPhone product page), but also five more that are purely navigation pages. In other words, 83% of the retrieval obstructs the user’s ability to find the most useful result. Of course, indexing similar content isn’t always easy, because “simi‐ lar” is a highly relative term. It’s not always clear where to draw the line between navigation and destination pages—in some cases, a page can be considered both. That’s why it’s important to test out navigation/destination distinctions before actually applying them. The weakness of the navigation/destination approach is that it is essentially an exact organization scheme (discussed in Chapter 6) that requires the pages to be either destination or navigation. In the following three approaches, the organization schemes are ambigu‐ ous, and therefore more forgiving of pages that fit into multiple categories. Choosing What to Index | 221 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:55. 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 . Indexing for specific audiences If you’ve already decided to create an architecture that uses an audience-oriented organization scheme, it may make sense to create search zones by audience breakdown as well. We found this a useful approach for the original Library of Michigan website. The Library of Michigan has three primary audiences: members of the Michigan state legislature and their staffs, Michigan libraries and their librarians, and the citizens of Michigan. The information needed from this site is different for each of these audiences; for example, each has a very different circulation policy. So we created four indexes: one for each of the three audiences, and one unified index of the entire site in case the audience-specific indexes didn’t do the trick for a particular search. Table 9-1 shows the results from running a query on the word “circulation” against each of the four indexes. Table 9-1. Query results Index Documents retrieved Retrieval reduced by Unified 40 — Legislature area 18 55% Libraries area 24 40% Citizens area 9 78% As with any search zone, less overlap between indexes improves per‐ formance. If the retrieval results were reduced by a very small figure—say, 10% or 20%—it might not be worth the overhead of cre‐ ating separate audience-oriented indexes. But in this case, much of the site’s content is specific to individual audiences. Indexing by topic The Mayo Clinic employs topical search zones on its website. For example, if you’re looking for a doctor to help with your rehabilita‐ tion, you might select the “Doctors & Medical Staff ” search zone, as shown in Figure 9-3. The 88 results retrieved may sound like a lot, but if you’d searched the entire site, the total would have been 1,470 results, many dealing with topic areas that aren’t germane to identifying a physician. 222 | Chapter 9: Search Systems 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:55. 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 9-3. Executing a search against the “Doctors & Medical Staff” search zone Indexing recent content Chronologically organized content allows for perhaps the easiest implementation of search zones. (Not surprisingly, it’s a common example of search zones.) Because dated materials aren’t generally ambiguous and date information is typically easy to come by, creat‐ ing search zones by date—even ad hoc zones—is straightforward. The search interface of the New York Times provides a useful illus‐ tration of filtering by date range (Figure 9-4). Regular users can return to the site and check up on the news using one of a number of chronological search zones (e.g., today’s news, past week, past 30 days, past 90 days, past year, and since 1851). Additionally, users who are looking for news within a particular date range or on a specific date can essentially generate an ad hoc search zone. Choosing What to Index | 223 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:55. 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 9-4. There are many ways to narrow your New York Times search by date Selecting Content Components to Index Just as it’s often useful to provide access to subsets of your site’s con‐ tent, it’s valuable to allow users to search specific components of your documents. By doing so, you’ll enable users to retrieve more specific, precise results. And if your documents have administrative or other content components that aren’t especially meaningful to users, these can be excluded from the search. In the Yelp business listing shown in Figure 9-5, there are more con‐ tent components than meet the eye. There is a business name, oper‐ ating hours, images, a link to the business’s website, and some attributes that are invisible to users. There are also content compo‐ nents that we don’t want to search, such as the reviews and tips toward the bottom of the screen. These could confuse a user’s search results; for example, if a review included the name of a competing restaurant. (A great by-product of the advent of content manage‐ ment systems and logical markup languages is that it’s now much easier to leave out content that shouldn’t be indexed, like navigation options, advertisements, disclaimers, and other stuff that might show up in document headers and footers.) 224 | Chapter 9: Search Systems 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:55. 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 9-5. Yelp’s business listings are jam-packed with various content components, some visible and some not Yelp’s search system allows users to take advantage of the informa‐ tion environment’s structure, supporting searches by the following content components, among others: • Business name • Categories (e.g., Burgers, American) • Ambiance and attire (e.g., casual, formal, etc.) Choosing What to Index | 225 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:55. 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 . • Noise level • Location Would users bother to search by any of these components? In Yelp’s case, we could determine this by reviewing search query logs. But what about in the case of a search system that hadn’t yet been imple‐ mented? Prior to designing a search system, could we know that users would take advantage of this specialized functionality? There is another reason to exploit a document’s structure. Content components aren’t useful only for enabling more precise searches; they can also make the format of search results much more mean‐ ingful. In Figure 9-6, Yelp’s search results include category and list‐ ing titles (“Boulevard Burger,” “Burgers, Breakfast & Brunch”), snippets of reviews (“My wife & I came in last night for dinner…”), number of reviews, average ratings, and locations. Indexing numer‐ ous content components for retrieval provides added flexibility in how you design search results. (See “Presenting Results” on page 233 for more on this topic.) This leads to a difficult paradox: even if users would benefit from such souped-up search functionality, they likely won’t ever ask for it during initial user research. Typically, users don’t have much under‐ standing of the intricacies and capabilities of search systems. Devel‐ oping use cases and scenarios might unearth some reasons to support this level of detailed search functionality, but it might be better to instead examine other search interfaces that your site’s users find valuable, and determine whether to provide a similar type of functionality. 226 | Chapter 9: Search Systems 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:55. 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 9-6. Title, rating, and location are content components dis‐ played for each result Search Algorithms Search engines find information in many ways. In fact, there are about 40 different retrieval algorithms alone, most of which have been around for decades. We’re not going to cover them all here; if Search Algorithms | 227 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:55. 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 A good starting point is Modern Information Retrieval by Ricardo Baeza-Yates and Berthier Ribeiro-Neto (Boston: Addison-Wesley, 2011). you’d like to learn more, read any of the standard texts on informa‐ tion retrieval.1 We bring up the topic because it’s important to realize that a retrieval algorithm is essentially a tool, and just like other tools, spe‐ cific algorithms help solve specific problems. And as retrieval algo‐ rithms are at the heart of search engines, it’s important to note that there is absolutely no single search engine that will meet all of your users’ information needs. Remember that fact the next time you hear a search engine vendor claim that their product’s brand-new proprietary algorithm is the solution to all information problems. Pattern-Matching Algorithms Most retrieval algorithms employ pattern matching; that is, they compare the user’s query with an index of, typically, the full texts of your system’s documents, looking for the same string of text. When a matching string is found, the source document is added to the retrieval set. So, a user types the textual query “electric guitar,” and documents that include the text string “electric guitar” are retrieved. It all sounds quite simple. But this matching process can work in many different ways to produce different results. Recall and precision Some algorithms return numerous results of varying relevance, while some return just a few high-quality results. The terms for these opposite ends of the spectrum are recall and precision. Figure 9-7 shows formulas for calculating them (note the difference in the denominators). Figure 9-7. Precision and recall ratios 228 | Chapter 9: Search Systems 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:55. 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 . Are your system’s users doing legal research, learning about the cur‐ rent state of scientific research in a field, or performing due dili‐ gence about an acquisition? In these cases, they’ll want high recall. Each of the hundreds or thousands (or more?) results retrieved will have some relevance to the user’s search, although perhaps not very much. As an example, users who are “ego-surfing” will want to see every mention of their names—they’re hoping for high recall. The problem, of course, is that along with good results come plenty of irrelevant ones. On the other hand, a user who is looking for two or three really good articles on how to get stains out of a wool carpet will be hoping for high-precision results. It doesn’t matter how many relevant arti‐ cles there are if you get a good enough answer right away. Wouldn’t it be nice to have both recall and precision at the same time? Lots and lots of very high-quality results? Sadly, you can’t have your cake and eat it, too: recall and precision are inversely related. You’ll need to decide what balance of the two will be most beneficial to your users. You can then select a search engine with an algorithm biased toward either recall or precision, or perhaps configure an engine to accommodate one or the other. For example, a search tool might provide automatic stemming, which expands a term to include other terms that share the same root (or stem). If the stemming mechanism is very strong, it might treat the search term “computer” as sharing the same root (“com‐ put”) as “computers,” “computation,” “computational,” and “comput‐ ing.” Strong stemming in effect expands the user’s query by searching for documents that include any of those terms. This enhanced query will retrieve more related documents, meaning higher recall. Conversely, no stemming means the query “computer” retrieves only documents with the term “computer” and ignores other var‐ iants. Weak stemming might expand the query only to include plu‐ rals, retrieving documents that include “computer” or “computers.” With weak stemming or no stemming, precision is higher and recall is lower. Which way should you go with your search system—high recall or high precision? The answer depends on what kinds of information needs your users have. Another consideration is how structured the content is. Are there fields, rendered in HTML or XML or perhaps in a document record, Search Algorithms | 229 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:55. 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 . that the search engine can “see” and therefore search? If so, search‐ ing for “William Faulkner” in the author field will result in higher precision, assuming we’re looking for books authored by Faulkner. Otherwise, we’re left with searching the full text of each document and finding results where “William Faulkner” may be mentioned, whether or not he was the author. Other Approaches When you already have a “good” document on hand, some algo‐ rithms will convert that document into the equivalent of a query (this approach is typically known as document similarity). “Stop words” (e.g., “the,” “is,” and “he”) are stripped out of the good docu‐ ment, leaving a useful set of semantically rich terms that, ideally, represent the document well. These terms are then converted into a query that should retrieve similar results. An alternative approach is to present results that have been indexed with similar metadata. In Figure 9-8, hovering over individual search results in the Duck‐ DuckGo search engine offers more matches for the search terms in the same domain as that particular result. Figure 9-8. DuckDuckGo search results are accompanied by a link to “More results” within the same domain Approaches such as collaborative filtering and citation searching go even further to help expand results from a single relevant document. 230 | Chapter 9: Search Systems 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:55. 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 the following example from CiteSeer (see Figure 9-9), we’ve iden‐ tified an article that we like: “Application Fault Level Tolerance in Heterogeneous Networks of Workstations.” CiteSeer automatically finds documents in a number of ways: Cited by What other papers cite this one? The relationship between cited and citing papers implies some degree of mutual relevance. Per‐ haps the authors even know each other. Active bibliography (related documents) Conversely, this paper cites others in its own bibliography, implying a similar type of shared relevance. Related documents from co-citation Another twist on citation, co-citation assumes that if documents appear together in the bibliographies of other papers, they prob‐ ably have something in common. Figure 9-9. CiteSeer provides multiple ways to expand from a single search result There are other retrieval algorithms, more than we can cover here. What’s most important is to remember that the main purpose of these algorithms is to identify the best pool of documents to be pre‐ sented as search results. But “best” is subjective, and you’ll need to Search Algorithms | 231 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:55. 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 . have a good grasp of what users hope to find when they’re searching your site. Once you have a sense of what they wish to retrieve, begin your quest for a search tool with a retrieval algorithm that might address your users’ information needs. Query Builders Besides search algorithms themselves, there are many other means of affecting the outcome of a search. Query builders are tools that can soup up a query’s performance. They are often invisible to users, who may not understand their value or how to use them. Common examples include: Spell checkers These allow users to misspell terms and still retrieve the right results by automatically correcting search terms. For example, “accomodation” would be treated as “accommodation,” ensuring retrieval of results that contain the correct term. Phonetic tools Phonetic tools (the best-known of which is “Soundex”) are especially useful when searching for a name. They can expand a query on “Smith” to include results with the term “Smyth.” Stemming tools Stemming tools allow users to enter a term (e.g., “lodge”) and retrieve documents that contain variant terms with the same stem (e.g., “lodging,” “lodger”). Natural language processing tools These can examine the syntactic nature of a query—for exam‐ ple, is it a “how to” question or a “who is” question?—and use that knowledge to narrow retrieval. For example, Siri uses natu‐ ral language processing to figure out if it should trigger a web search or a bad joke (Figure 9-10). 232 | Chapter 9: Search Systems 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:55. 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 9-10. Siri uses natural language processing to determine whether the user wants to do a web search, look at the weather app, or hear a bad joke Controlled vocabularies and thesauri Covered in detail in Chapter 10, these tools leverage the seman‐ tic nature of a query by automatically including synonyms within the query. Spell checkers correct for an almost universal problem among searchers and are well worth considering for your search system. (Look over your search logs, and you’ll be amazed by the prepon‐ derance of typos and misspellings in search queries.) The other query builders have their pros and cons, addressing dif‐ ferent information needs in different situations. Once again, a sense of your users’ information needs will help you select which approaches make the most sense for you; additionally, keep in mind that your search engine may or may not support these query builders. Presenting Results What happens after your search engine has assembled the results to display? There are many ways to present results, so once again you’ll need to make some choices. And as usual, the mysterious art of understanding your content and how users want to use it should drive your selection process. When you are configuring the way your search engine displays results, there are two main issues to consider: which content Presenting Results | 233 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:55. 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 . components to display for each retrieved document, and how to list or group those results. Which Content Components to Display Display less information to users who know what they’re looking for, and more information to users who aren’t sure what they want. A variant on that simple approach is to show users who are clear on what they’re looking for only representational content components, such as a title or author, to help them quickly distinguish the result they’re seeking. Users who aren’t as certain of what they’re looking for will benefit from descriptive content components such as a sum‐ mary, part of an abstract, or keywords to get a sense of what their search results are about. You can also provide users some choice of what to display; again, consider your users’ most common informa‐ tion needs before setting a default. For example, the Yelp iPad app allows the user to view search results as listings, a location map, or images (Figure 9-11). Figure 9-11. The Yelp iPad app allows users to select three different ways of viewing search results: as listings, as locations on a map, or as images When it’s hard to distinguish retrieved documents because of a com‐ monly displayed field (e.g., the title), show more information, such as a page number, to help the user differentiate between results. Another take on the same concept is shown in Figure 9-12, which displays multiple versions of the same book. Some of the distinc‐ tions are meaningful: you’ll want to know which items are available in the library. Some aren’t so helpful; for example, you might not care as much about the cover. 234 | Chapter 9: Search Systems 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:55. 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 9-12. Content components help distinguish multiple versions of the same book How much information to display per result is also a function of how large a typical result set is. Perhaps you don’t have that much content, or most users’ queries are so specific that they retrieve only a small number of results. If you think that users would like more information in such cases, then it may be worth displaying more content components per result. But keep in mind that regardless of how many ways you indicate that there are more results than fit on one screen, many (if not most) users will never venture past that first screen. So don’t go overboard with providing lots of content per result, as the first few results may obscure the rest of the retrieval. Which content components you display for each result also depends on which components are available in each document (i.e., how your content is structured) and on how the content will be used. Users of phone directories, for example, want phone numbers first and foremost. So it makes sense to show them the information from the phone number field in the result itself, as opposed to forcing Presenting Results | 235 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:55. 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 . them to click through to another document to find this information (see Figure 9-13). Figure 9-13. A Yellow Pages search doesn’t force us to click through for a phone number If you don’t have much structure to draw from or if your engine is searching full text, showing the query terms within the “context” of the document’s text is a useful variation on this theme (see Figure 9-14). In this example, The Verge highlights the query terms by using a bold font within the sentence they appear in—an excel‐ lent practice, as it helps the user quickly scan the results page for the relevant part of each result. 236 | Chapter 9: Search Systems 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:55. 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 9-14. The Verge bolds search query result instances in their sur‐ rounding sentences to show their context Presenting Results | 237 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:55. 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 . How Many Documents to Display How many documents are displayed depends mostly on two factors. If your engine is configured to display a lot of information for each retrieved document, you’ll want to consider having a smaller retrieval set, and vice versa. Additionally, a user’s screen resolution, connectivity speed, and browser settings will affect the number of results that can be displayed effectively. It may be safest to err on the side of simplicity—by showing a small number of results—while providing a variety of settings that users can select based on their own needs. We suggest that you let users know the total number of retrieved documents so they have a sense of how many documents remain as they sift through search results. Also consider providing a results navigation system to help them move through the results. In Figure 9-15, Reuters provides such a navigation system, displaying the total number of results and enabling users to move through the result set 10 items at a time. In many cases, the moment a user is confronted by a large result set is the moment he decides the number of results is too large. This is a golden opportunity to provide the user with the option of revising and narrowing his search. Reuters achieves this quite simply by repeating the query in the search box. 238 | Chapter 9: Search Systems 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:55. 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 9-15. Reuters allows you to jump ahead through screens of 10 results at a time Listing Results Now that you have a group of search results and a sense of which content components you wish to display for each, in what order should these results be listed? Again, much of the answer depends Presenting Results | 239 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:55. 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 . upon what kind of information needs your users start with, what sort of results they are hoping to receive, and how they would like to use the results. There are two common methods for listing retrieval results: sorting and ranking. Retrieval results can be sorted chronologically by date, or alphabetically by any number of content component types (e.g., by title, by author, or by department). They can also be ranked by a retrieval algorithm (e.g., by relevance or popularity). Sorting is especially helpful to users who are looking to make a deci‐ sion or take an action. For example, users who are comparing a list of products might want to sort by price or another feature to help them make their choice. Any content component can be used for sorting, but it’s sensible to provide users with the option to sort on components that will actually help them accomplish tasks. Which ones are task oriented and which aren’t, of course, depends upon each unique situation. Ranking is more useful when there is a need to understand informa‐ tion or learn something. Ranking is typically used to describe retrieved documents’ relevance, from most to least. Users look to learn from those documents that are most relevant. Of course, as we shall see, relevance is relative, and you should choose relevance ranking approaches carefully. Users will generally assume that the top few results are best. The following sections provide examples of both sorting and rank‐ ing, as well as some ideas on what might make the most sense for your users. Sorting by alphabet Just about any content component can be sorted alphabetically (see Figure 9-16). This is a good general-purpose sorting approach— especially when sorting names—and in any case, it’s a good bet that most users are familiar with the order of the alphabet! It works best to omit initial articles such as “a” and “the” from the sort order (cer‐ tain search engines provide this option); users are likely to look for “The Naked Bungee Jumping Guide” under “N” rather than “T.” 240 | Chapter 9: Search Systems 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:55. 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 9-16. Baseball-Reference.com displays search results in alpha‐ betical order Sorting by chronology If your content (or your user’s query) is time sensitive, chronological sorts are a useful approach. And you can often draw on a filesystem’s built-in dating if you have no other sources of date information. If your site provides access to press releases or other news-oriented information, sorting by reverse chronological order makes good Presenting Results | 241 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:55. 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 . sense (see Figure 9-17 and Figure 9-18). Chronological order is less common and can be useful for presenting historical data. Figure 9-17. The Washington Post’s default list ordering is by reverse chronological order… 242 | Chapter 9: Search Systems 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:55. 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 9-18. …as is CNET’s Ranking by relevance Relevance-ranking algorithms (there are many flavors) are typically based on one or more of the following: • How many of the query’s terms occur in the retrieved document • How frequently those terms occur in that document Presenting Results | 243 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:55. 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 . • How close together those terms occur (e.g., are they adjacent, in the same sentence, or in the same paragraph?) • Where the terms occur (e.g., a document with the query term in its title may be more relevant than one with the query term in its body) • The popularity of the document where the query terms appear (e.g., is it linked to frequently, and are the sources of its links themselves popular?) Different relevance-ranking approaches make sense for different types of content, but with most search engines, the content you’re searching is apples and oranges. So, for example, Document A might be ranked higher than Document B, but Document B is definitely more relevant. Why? Because while Document B is a bibliographic citation to a really relevant work, Document A is a long document that just happens to contain many instances of the terms in the search query. The more heterogeneous your documents are, the more careful you’ll need to be with relevance ranking. Indexing by humans is another means of establishing relevance. Keyword and descriptor fields can be searched, leveraging the value judgments of human indexers. For example, manually selected rec‐ ommendations—popularly known as “best bets”—can be returned as relevant results. In Figure 9-19, the first set of results was associ‐ ated with the query “Ukraine” in advance. Requiring an investment of human expertise and time, the best bets approach isn’t trivial to implement and therefore isn’t necessarily suitable to be developed for each and every user query. Instead, rec‐ ommendations are typically used for the most common queries (as determined by search log analysis) and combined with automati‐ cally generated search results. 244 | Chapter 9: Search Systems 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:55. 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 9-19. A search of the BBC’s site retrieves a set of manually tag‐ ged documents as well as automatic results; the recommendations are called “Editor’s Choice” rather than “best bets” Ranking by popularity Popularity is the source of Google’s popularity. Put another way, Google is successful in large part because it ranks results by which ones are the most popular. It does so by factoring in how many links there are to a retrieved document. Google also dis‐ tinguishes the quality of these links: a link from a site that itself receives many links is worth more than a link from a little-known site. This algorithm, which is part of Google’s “secret sauce” for pre‐ senting search results, is known as PageRank. Presenting Results | 245 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:55. 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 other ways to determine popularity, but keep in mind that small sites or collections of separate, nonlinked sites (often referred to as “silos”) don’t necessarily take advantage of popularity as well as large, multisite environments with many users. The latter have a wide scope of usage and a richer set of links. A smaller system isn’t likely to have enough variation in the popularity of different docu‐ ments to merit this approach, while in a “silo” environment, little cross-pollination results in few links between sites. It’s also worth noting that, to calculate relevance, Google uses many other criteria in addition to PageRank. Ranking by users’ or experts’ ratings In an increasing number of situations, users are willing to rate the value of information. User ratings can be used as the basis of retrieval result ordering. In the case of Yelp (see Figure 9-20), these ratings—based on users’ reviews of businesses listed in the system— are integral to helping users judge the value of an item, and form the foundation of an entire information economy. Of course, Yelp has a lot of users who don’t shrink from expressing their opinions, so there is a rich collection of judgments to draw on for ranking. Most sites don’t have a sufficient volume of motivated users to employ valuable user ratings. However, if you have the opportunity to use this data, it can be helpful to display user ratings with a docu‐ ment, if not as part of a presentation algorithm. 246 | Chapter 9: Search Systems 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:55. 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 9-20. User ratings fuel the ranking of these Yelp results Presenting Results | 247 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:55. 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 . 2 Susan T. Dumais, Edward Cutrell, and Hao Chen, “Optimizing search by showing results in context” (Proceedings of CHI ’01, Human Factors in Computing Systems, 2001, 277–284).” Ranking by pay-for-placement Advertising has become the predominant business model for pub‐ lishing online, so it is no surprise that pay-for-placement (PFP) has become commonplace in many search systems. Although the previ‐ ous Yelp example showed results sorted by user rankings, the first result on the list actually has a lower ranking than the others; it owes its position at the top of the list solely to the fact that it is a paid advertisement. If your system aggregates content from a number of different ven‐ dors, you might consider implementing PFP to present search results. If users are shopping, they might also appreciate this approach—with the assumption being that the most stable, success‐ ful sites are the ones that can afford the highest placement. This is somewhat like selecting the plumber with the largest advertisement in the yellow pages to fix your toilet. Grouping Results Despite all the ways we can list results, no single approach is perfect. Hybrid approaches that combine different types of sorting—such as Google’s—show a lot of promise, but you typically need to be in the business of creating search engines to have this level of involvement with a tool. In any case, our information environments are typically getting larger, not smaller. Search result sets will accordingly get larger as well, and so will the probability that those ideal results will be buried far beyond the point where users give up looking. However, one alternative approach to sorting and ranking holds promise: clustering retrieved results by some common aspect. An excellent study by researchers at Microsoft and the University of California at Berkeley shows improved performance when results are clustered by category as well as by a ranked list.2 How can we cluster results? The obvious ways are, unfortunately, the least useful: we can use existing metadata, like document type (e.g., , ) and file creation/modification date, to allow us to divide search results into clusters. Much more useful are clusters derived from 248 | Chapter 9: Search Systems 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:55. 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 . manually applied metadata, like topic, audience, language, and product family. Unfortunately, approaches based on manual effort can be prohibitively expensive. In Figure 9-21, Forrester contextualizes the query “user experience” with roles such as “Marketing Leadership” and specific date ranges. Figure 9-21. Forrester contextualizes search results for the query “user experience” These clusters provide context for search results; selecting the cate‐ gory that seems to fit your interest best allows you to work with a significantly smaller retrieval set and (ideally) a set of documents that come from the same topical domain. This approach is much like generating search zones on the fly. Acting on Results You’ve provided the user with a set of search results. What happens next? Certainly, she could continue to search, revising her query and her idea of what she’s looking for along the way. Or, heavens, she might have found what she was looking for and be ready to move on. Contextual inquiry and task-analysis techniques will help you understand what users might want to do with their results. The fol‐ lowing sections discuss a few common options. Presenting Results | 249 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:55. 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 . Call to action Some search results can be acted on directly, without having to jump through intermediary steps. In these cases, it is often desirable to include a call-to-action button or link along with individual search results. For example, the iOS App Store allows the user to “GET” apps directly from search results, without having to view the apps’ description screens and user reviews (Figure 9-22). Figure 9-22. Search results in the iOS App Store include a “GET” but‐ ton (which lists the app’s price when it is not free) 250 | Chapter 9: Search Systems 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:55. 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 . Select a subset of results Sometimes when you’re searching you want to take more than one document along with you. You want to “shop” for documents just like you shop for books at Amazon. And if you’re sorting through dozens or hundreds of results, you may need a way to mark the documents you like so you don’t forget or lose track of them. A shopping cart feature can be quite useful in search-intensive envi‐ ronments such as library catalogs. In Figure 9-23, users can “save” a subset of their retrieval and then manipulate those results in their “shelves” once they’re done searching. Figure 9-23. The San Francisco Public Library allows users to add search results to three “shelves”: “Completed,” “In Progress,” and “For Later” Save a search In some cases, it’s the search itself, not the results, that you’re inter‐ ested in “keeping.” Saved searches are especially useful in dynamic domains that you’d like to track over time; you can manually re- execute a saved search on a regular basis, or schedule that query to automatically be rerun regularly. Note that the example in Figure 9-23 includes a “Save Search” link in the upper-right corner of the search results display; the user can name saved search sets for later retrieval. Presenting Results | 251 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:55. 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 . Designing the Search Interface All the factors we’ve discussed so far—what to search, what to retrieve, and how to present the results—come together in the search interface. And with so much variation among users and search technology functions, there can be no single ideal search interface. Although the literature of information retrieval includes many studies of search interface design, many variables preclude the emergence of a “right way” to design search interfaces. Here are a few of the variables on the table: Level of searching expertise and motivation Are users comfortable with specialized query languages (e.g., Boolean operators), or do they prefer natural language? Do they need a simple or a high-powered interface? Do they want to work hard to make their searches truly successful, or are they happy with “good enough” results? How many iterations are they willing to try? Type of information need Do users want just a taste, or are they doing comprehensive research? What content components can help them make good decisions about clicking through to a document? Should the results be brief, or should they provide extensive detail for each document? And how detailed a query are users willing to pro‐ vide to express their needs? Type of information being searched Is the information made up of structured fields or full text? Is it navigation pages, destination pages, or both? Is it written in HTML or other formats, including nontextual? Is the content dynamic or more static? Does it come tagged with metadata, full of fields, or is it full text? Amount of information being searched Will users be overwhelmed by the number of documents retrieved? How many results is the “right number”? That’s a lot to consider. Luckily, we can provide basic advice that you should consider when designing a search interface. In the early days of the Web, many search engines emulated the functionality of the “traditional” search engines used for online library catalogs and databases, or were ported directly from those environments. These traditional systems were often designed for 252 | Chapter 9: Search Systems 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:55. 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 . researchers, librarians, and others who had some knowledge of and incentive for expressing their information needs in complex query languages. Therefore, many search systems at the time allowed the user to use Boolean operators, search fields, and so forth; in fact, users were often required to know and use these complex syntaxes. As the Web’s user base exploded, overall searching experience and expertise bottomed out, and the new breed of user wasn’t especially patient. Users more typically just entered a term or two without any operators, pressed the “search” button, and hoped for the best. The reaction of search engine developers was to bury the old fancy tricks in advanced search interfaces, or to make them invisible to users by building advanced functionality directly into the search engines. For example, Google makes a set of assumptions about what kind of results users want (through a relevance algorithm) and how they’d like those results presented (using a popularity algo‐ rithm). Google makes some good assumptions for web-wide search‐ ing, and that’s why it’s successful. However, most search systems, web-wide or local, don’t work as well. For that reason, the pendulum may eventually swing back to sup‐ porting users who, out of frustration, have become more search lit‐ erate and are willing to spend more time learning a complex search interface and constructing a query. But for now, it’s fair to assume that, unless your site’s users are librarians, researchers, or specialized professionals (e.g., an attorney performing a patent search), they won’t invest much time or effort into crafting well-considered quer‐ ies. That means the burden of searching falls chiefly on the search engine, its interfaces, and how content is tagged and indexed. There‐ fore, it’s best to keep your search interface as simple as possible: present users with a simple search box and a “search” button. The Box Your system is likely to have the ubiquitous search box, as shown in Figure 9-24. Figure 9-24. The ubiquitous search box (in this case, from Apple) Designing the Search Interface | 253 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:55. 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 . Simple and clear. Type in some keywords (“lost iPhone”) or a natu‐ ral language expression (“Where can I find my iPhone?”), hit the Return (or Enter) button on your keyboard, and the whole site will be searched and results displayed. Users make assumptions about how search interfaces work, and you may want to test for those as you design your own search system. Some common user assumptions include: • “I can just type terms that describe what I’m looking for and the search engine will do the rest.” • “I don’t have to type in those funny AND, OR, or NOT thingies.” • “I don’t have to worry about synonyms for my term; if I’m look‐ ing for dogs, I just type ‘dogs,’ not ‘canine’ or ‘canines.’” • “Fielded searching? I don’t have time to learn which fields I can search.” • “My query will search the entire site.” If your users have those assumptions and are not especially motiva‐ ted to learn more about how your system’s search works differently, then go with the flow. Give them the box. You certainly could pro‐ vide a “help” page that explains how to create more advanced, pre‐ cise queries, but users may rarely visit this page. Instead, look for opportunities to educate users when they’re ready to learn. The best time to do this is after the initial searches have been executed, when the users have reached a point of indecision or frus‐ tration. The initial hope that the first try would retrieve exactly what they were looking for has now faded. And when users are ready to revise their searches, they’ll want to know how they can make those revisions. For example, if you search the eBay app for “watches” (see Figure 9-25), you’ll likely get a few more results than you’d like. 254 | Chapter 9: Search Systems 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:55. 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 9-25. The eBay app’s search results provide opportunities to revise your search… At this point, eBay’s search system goes beyond the box: it tells the user something to the effect of “Here are those 1,631,329 results that you asked for. Perhaps this is too many? If that’s the case, consider revising your search using our souped-up ‘Refine’ interface, which allows you to narrow your search. Or, select from a list of categories to narrow your results further” (see Figure 9-26). Designing the Search Interface | 255 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:55. 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 9-26. …including the ability to refine your search by specifying various category-specific facets In general, too many or too few (typically zero) search results are both good indicators for users to revise their searches; we’ll cover more on this topic in the section “Supporting Revision” on page 260 later in this chapter. Consider how your search box is presented. The box can cause con‐ fusion when it appears alongside other boxes. Unless your system’s 256 | Chapter 9: Search Systems 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:55. 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 . search functionality truly requires more than one field—as is the case with many travel-related services—it is best to keep search limi‐ ted to a single box. (If more than one field is required, it’s important that they be clearly labeled, as illustrated in Figure 9-27.) Figure 9-27. Kayak’s flight search form features clearly labeled fields Consistent placement of the search box alongside other global navi‐ gation choices, along with the consistent use of a button labeled “search” that comes with that box, will go a long way toward ensur‐ ing that users at least know where to type their queries. There are many assumptions behind that innocuous little search box, some made on the part of the user, and some by the designer who decides what functionality will be hidden behind that box. Determining what your users’ assumptions are should drive the default settings that you set up when designing the simple search interface. Autocomplete and Autosuggest Autocomplete and autosuggest are widely used patterns for interact‐ ing with search systems. In both cases, a list of results is presented alongside the search box, preemptively prompting the user with possible matches based on the first few characters typed. These results are culled from search indexes, controlled vocabularies, man‐ ually configured match lists, or often all of the above. Displays range from very simple and straightforward text lists (in the case of auto‐ complete patterns) to popovers with highly customized layouts (Figure 9-28). Designing the Search Interface | 257 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:55. 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 9-28. Like many airlines, Lufthansa presents a list of airports that match the first few characters the user types into the origin and destination search boxes This technique is very useful, because it helps users identify poten‐ tial matches based on partial or incomplete information. In some cases, it also gives them hints as to the way the system is structured, allowing them to make smarter searches by giving them the ability to explore the system right from the search box. Because of this, it has mostly supplanted the dedicated, advanced search mechanisms of yore. Advanced Search In the past, many websites provided advanced search interfaces as crutches for underfeatured or poorly configured search systems. In stark contrast to the search box, advanced search interfaces allow much more manipulation of the search system and are typically used by two types of users: advanced searchers (librarians, lawyers, doctoral students, medical researchers), and frustrated searchers who need to revise their initial searches (often users who’ve found that the search box didn’t meet their needs). As search engines have improved, advanced search interfaces are increasingly focused on serving the former. 258 | Chapter 9: Search Systems 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:55. 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 . While they are less common today, advanced search interfaces pro‐ vide flexibility and power to users who understand the structure of the information they are looking for. For example, the US Congress website allows knowledgeable users to configure extremely sophisti‐ cated searches using Boolean operators (Figure 9-29). Figure 9-29. Congress.gov allows advanced users to build complex searches using Boolean operators If your system could benefit from advanced search, a good rule of thumb is to expose your search engine’s various heavy-duty search functions on the advanced page for those few users who want to have a go at them, but design your search system with the goal of making it unnecessary for the vast majority of searchers to ever need to go to the advanced search page. Designing the Search Interface | 259 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:55. 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 . Supporting Revision We’ve touched on what can happen after the users find what they’re looking for, when the search is done. But all too often that’s not the case. Here are some guidelines to help your users hone their searches (and hopefully learn a little bit about your search system in the process). Repeat search in results page What was it I was looking for? Sometimes users are forgetful, espe‐ cially after sifting through dozens of results. Displaying the initial search within the search box (as in Figure 9-30) can be quite useful: it restates the search that was just executed, and allows the user to modify it without reentering it. Figure 9-30. In the Netflix Android app, the query is displayed on the results page and can be revised and reexecuted Explain where results come from It’s useful to make clear what content was searched, especially if your search system supports multiple search zones (see Figure 9-31). This reminder can be handy if the user decides to broaden or narrow his search; more or fewer search zones can be used in a revised search. 260 | Chapter 9: Search Systems 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:55. 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 9-31. The iOS iTunes Store app search system shows you where you searched (i.e., “All”), and makes it easy to reach results from other search zones Designing the Search Interface | 261 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:55. 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 . Explain what the user did If the results of a search are not satisfactory, it can be useful to state what happened behind the scenes, providing the user with a better understanding of the situation and a jumping-off point should she wish to revise her search. Explaining “what happened” can include the two guidelines just mentioned, as well as: • Restating the query • Describing what content was searched • Describing any filters that might be in place (e.g., date ranges) • Showing implicit Boolean or other operators, such as a default AND • Showing other current settings, such as the sort order • Mentioning the number of results retrieved In Figure 9-32, the New York Times site provides an excellent exam‐ ple of explaining to the user what just happened. Figure 9-32. All aspects of the search are restated as part of these search results 262 | Chapter 9: Search Systems 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:55. 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 . Integrate searching with browsing A key theme in this book is the need to integrate searching and browsing (think of them together as “finding”), but we won’t belabor it here. Just remember to look for opportunities to connect your search and browse systems to allow users to easily jump back and forth. As Figure 9-33 and Figure 9-34 illustrate, Barnes & Noble provides this functionality in both directions. Figure 9-33. Searching leads to browsing: a search for “2001 a space odyssey” on the Barnes & Noble site retrieves categories as well as documents Designing the Search Interface | 263 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:55. 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 9-34. And browsing leads to searching: navigate to the “Movies & TV” section, and you’ll find the search box set to search that zone When Users Get Stuck You can strive to support iterative searching with fully integrated browsing and state-of-the-art retrieval and presentation algorithms, yet users still will fail time and time again. What should you do when presenting the user with zero results, or with way too many? The latter case is a bit easier to address, because in most cases your search engine provides relevance-ranked results. In effect, winnow‐ ing oversized result sets is a form of search revision, and often the user will self-select when he is ready to stop reviewing results. But it is still useful to provide some instruction on how to narrow search results, as shown in Figure 9-35. You can also help users narrow their results by allowing them to search within their current result sets. In Figure 9-36, the initial search for hotels in New York City retrieved over 600 results; we can “filter by hotel name” for particular brands to narrow our retrieval. 264 | Chapter 9: Search Systems 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:55. 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 9-35. Congress.gov provides advice on how to narrow down searches Figure 9-36. Priceline.com allows users to search within the result set At the other end of the spectrum, zero hits is a bit more frustrating for users and challenging for information architects. We suggest you adopt a “no dead ends” policy to address this problem. “No dead Designing the Search Interface | 265 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:55. 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 . ends” simply means that users always have another option, even if they’ve retrieved zero results. The options might include: • A means of revising the search • Search tips or other advice on how to improve the search • A means of browsing (e.g., including the site’s navigation system or sitemap) • A human contact if searching and browsing won’t work It’s worth noting that we’ve seen few (if any) search systems that meet all these criteria. Where to Learn More Although this is the longest chapter in this book, we’ve covered only the tip of the search system iceberg. If this piqued your interest, you may want to delve further into the field of information retrieval. Some of our favorite texts are: • Search Patterns: Design for Discovery by Peter Morville and Jeff‐ ery Callender (Sebastopol, CA: O’Reilly, 2010) • Modern Information Retrieval by Ricardo Baeza-Yates and Berthier Ribeiro-Neto (Boston: Addison-Wesley, 2011) • Concepts of Information Retrieval by Miranda Lee Pao (West‐ port, CT: Libraries Unlimited, 1989); this title is out of print, but you may be able to find used copies on Amazon • On Search, the Series by Tim Bray, an excellent collection of essays on search written by the father of XML If you’re looking for more immediate and practical advice, the most useful site for learning about search tools is, naturally, Search‐ tools.com, Avi Rappoport’s compendium of installation and config‐ uration advice, product listings, and industry news. Another excellent source is Danny Sullivan’s Search Engine Watch, which focuses on web-wide searching but is quite relevant to site-wide searching nonetheless. 266 | Chapter 9: Search Systems 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:55. 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/on_search_the_series <blockquote class="wp-embedded-content" data-secret="Dfog4KTqFo"><a href="https://www.searchtools.com/">Search Tools Consulting</a></blockquote> <iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; visibility: hidden;" title="“Search Tools Consulting” — Searchtools.com" src="https://www.searchtools.com/embed/#?secret=miGY96rSoP#?secret=Dfog4KTqFo" data-secret="Dfog4KTqFo" width="500" height="282" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe> <blockquote class="wp-embedded-content" data-secret="Dfog4KTqFo"><a href="https://www.searchtools.com/">Search Tools Consulting</a></blockquote> <iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; visibility: hidden;" title="“Search Tools Consulting” — Searchtools.com" src="https://www.searchtools.com/embed/#?secret=miGY96rSoP#?secret=Dfog4KTqFo" data-secret="Dfog4KTqFo" width="500" height="282" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe> <blockquote class="wp-embedded-content" data-secret="BagyZh7uRy"><a href="https://www.searchenginewatch.com/">Homepage</a></blockquote> <iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; visibility: hidden;" title="“Homepage” — Search Engine Watch" src="https://www.searchenginewatch.com/embed/#?secret=yn0DQuhAqh#?secret=BagyZh7uRy" data-secret="BagyZh7uRy" width="500" height="282" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe> Recap Let’s recap what we learned in this chapter: • Search is an important mechanism for finding information; however, it’s not a given that your information environment requires a search system. • Although search may appear simple—just type some words into the search box—there’s a lot going on under the hood. • Choosing what to index in your information environment is an important step when configuring your search system. • There are many different types of search algorithms. • There are also various different ways of presenting results back to the user. • All of these factors—what to search, what to retrieve, and how to present the results—come together in the search interface. Now we move on to discuss the final principle in our overview: the‐ sauri, controlled vocabularies, and metadata. Recap | 267 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:55. 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 . 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:55. 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 . INFO 4745 Information Architecture Assignment 1 UNT Department of Information Science Spring 202 3 Assignment One The goal of this assignment is to apply your learning from Module 1 and 2. You will evaluate a webpage of your interest to identify all the major elements of the information architectures in terms of Organization System, Labeling System, Navigation System, and Search System. A rubric is provided on Canvas for you to see how this assignment will be reviewed and graded. Before you apply the following guidelines to a webpage you would like to evaluate, you have to select a webpage with the following components to meaningfully evaluate their information structure & architecture. (See Canvas instruction for suitable and unsuitable websites) 1. Does the website contain information & content (e.g., text, description) for an intended group of audience ? 2. Does the website contain enough layers/structures so that you can assess the 4 major elements and allow search query? COPY the sections under the line and provide your responses to each guiding questions. Submit your completed evaluation via Canvas Assignment 1 submission page. Be sure your work is saved as a WORD document as I cannot open MacOS Pages files! Name you file as “firstname_lastname_assignment1 ” URL of the Website: Part 1: Organization systems (Reference Chapter 6 in Rosenfeld, et al. book) 1) What is the organization system and scheme(s) used in the site? Explain the characteristics that you observed from the site that aligns with the definitions and properties of the specified system and schemes you have identified. 2) What is the organization structure(s) used in the site? Explain the identified structure(s) and how the definition and properties you observed are evidence to the structure. Part 2: Labeling systems (Reference Chapter 7 in Rosenfeld, et al. book) 3) What is the purpose and intended audience of this site? Is the labeling systems appropriate to the intended audience? Why or why not? 4) Which type of label format is used in the site and how do you determine which varieties of label(s) this site is using? 5) Is the labeling systems consistent among the homepage and subpages? Why or why not? 6) How about the language used for the labeling system? Are there any places for improvement? Elaborate. 7) If you will be updating the labeling system to meet the users’ need, what will you modify? Explain what the users may need and how you will address it through the labeling system. Part 3: Navigation systems (Reference Chapter 8 in Rosenfeld, et al. book) 8) What is the global, local, & contextual embedded navigation systems within this site? Provide examples with your explanation for each system. 9) What are the supplemental navigation systems in this site? Identify it/them and show an example with your description. 10) Does the site include any form of advanced navigation, such as personalization, customization, visualization, or social navigation? Identify it/them and provide an example with your description. Part 4: Search systems (Reference Chapter 9 in Rosenfeld, et al. book) 11) What is the search interface available on the site? How does it suggest the user to use it? 12) Could you determine if the search function allow advanced queries? Explain the procedure you took to examine this functionality and your conclusion. 13) Select one of the following criteria and conduct a search: Auto complete, stop words, stemming, controlled vocabularies, or keywords. Analyze the results and response to the following questions. a) How many results are displayed per page? (Provide a screenshot of the result) i) If, there is no result returned, does it tell the user what to do? b) How are the results ranked or ordered? c) Can you reorder results using other criteria (as listed above)? What happened? d) Does the site allow printing, saving, or emailing results? ————————————– End of Assignment One ———————————- 3 <div class="cta_banner"> <div class="banner-content_type-content in_content"> <div class="banner-content_type-content_title"> Turn in your highest-quality paper Get a qualified writer to help you with</div> <div class="banner-content_type-content_text">“ Information Architecture Assignment ”</div> <a href="https://assignmentessays.com/order" class="btn btn-yellow intext_banner_button intext_banner" rel="nofollow">Get high-quality paper</a> <div class="banner-content_type-content_price">NEW! AI matching with writer</div> </div> </div> <div class="w-embed"> <div class="anchor" id="Help"></div> </div> <div class="w-embed"> <div class="cta-card-v2"> <div class="card-column"> <h2 class="heading-22">Order an Essay Now & Get These Features For Free:</h2> <div class="ft-wrap-banner"> <div class="feat-v2"><img src="https://assignmentessays.com/wp-content/themes/essaypro/images/5e5d43546b94f9e451c22cc8_check-circle-color.svg" loading="lazy" width="18" height="18" alt="" class="image-44"> Turnitin Report </div> <div class="feat-v2"><img src="https://assignmentessays.com/wp-content/themes/essaypro/images/5e5d43546b94f9e451c22cc8_check-circle-color.svg" loading="lazy" width="18" height="18" alt="" class="image-44"> Formatting </div> <div class="feat-v2"><img src="https://assignmentessays.com/wp-content/themes/essaypro/images/5e5d43546b94f9e451c22cc8_check-circle-color.svg" loading="lazy" width="18" height="18" alt="" class="image-44"> Title Page </div> <div class="feat-v2"><img src="https://assignmentessays.com/wp-content/themes/essaypro/images/5e5d43546b94f9e451c22cc8_check-circle-color.svg" loading="lazy" width="18" height="18" alt="" class="image-44"> Citation </div> <div class="feat-v2"><img src="https://assignmentessays.com/wp-content/themes/essaypro/images/5e5d43546b94f9e451c22cc8_check-circle-color.svg" loading="lazy" width="18" height="18" alt="" class="image-44"> Outline </div> </div> </div><a href="/order" class="blog-btn2 w-button">Place an Order</a> </div> </div> </div> <div class="div-block-137"> <a href="#" class="facebook-share w-inline-block"> <div class="share-icon-fb"></div> <div class="share-text">Share</div> </a> <a href="#" class="twitter-share w-inline-block"> <div class="share-icon-tw"></div> <div class="share-text">Tweet</div> </a> </div> <div class="w-embed"> <div class="share-links-wrap"> <a href="https://www.facebook.com/sharer/sharer.php?u=https://assignmentessays.com/information-architecture-assignment-2/" class="facebook-share w-inline-block" target="_blank" rel="nofollow"> <div class="share-icon-fb"></div> <div class="share-text">Share</div> </a> <a href="https://twitter.com/share?text=Information Architecture Assignment&url=https://assignmentessays.com/information-architecture-assignment-2/" class="twitter-share w-inline-block" target="_blank" rel="nofollow"> <div class="share-icon-tw"></div> <div class="share-text">Tweet</div> </a> </div> </div> </div> <div class="sidebar"> <div class="calc-short" data-calc-short=""> <form name="uvocalculator" class="Calc" method="get" action="/" data-calculator-form=""> <div class="Calc__header">Calculate the price</div> <div class="Calc__row"> <label class="Calc__label" for="paperTypeId"> Type of paper <select name="paperTypeId" data-academic-level-select=""></select> </label> </div> <div class="Calc__row"> <label class="Calc__label" for="academicLevelId"> Academic level <select name="academicLevelId" data-academic-level-select-mobile=""></select> </label> </div> <div class="Calc__group"> <div class="Calc__cell"> <label class="Calc__label" for="deadlineId"> Deadline <select name="deadlineId" arial-label="List of deadline" data-deadline-static=""></select> </label> </div> <div class="Calc__cell" data-tariff-control=""> <div class="Calc__label"> Pages (300 words) <div class="uvocalc--pages__buttons"> <button type="button" title="Decrease" data-minus-button="" class="sfrom-select-pages" id="-page" disabled="">−</button> <input name="pages" value="2" data-pages-input="" type="text"> <button type="button" title="Increase" data-plus-button="" class="sfrom-select-pages" id="+page">+</button> </div> </div> </div> </div> <div class="Calc__row Calc__total">$0.00</div> <div class="Calc__row Calc__submit"> <input type="submit" class="sform-submit" value="Continue to order" id="continue-to-order" data-submit-button=""> </div> </form> </div> </div> </div> </div> </div> <div class="footer"> <div class="wrapper"> <div class="w-layout-grid footer-grid"> <div class="footer-top cycle"> <img class="logo-copy" src="https://assignmentessays.com/wp-content/uploads/2024/03/Assignment-Essays-white.svg" alt="Assignment Essays" /> </div> <div class="footer-v1-column"> <div class="footer_h">Company</div> <ul id="footer-menu" class="footer-menu"> <li id="menu-item-230" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-230"><a href="https://assignmentessays.com/assignment-essays/" class=" ft_link">Assignment Essays</a></li> <li id="menu-item-321" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-321"><a href="https://assignmentessays.com/how-it-works/" class=" ft_link">How it works</a></li> <li id="menu-item-322" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-322"><a href="https://assignmentessays.com/pricing/" class=" ft_link">Pricing</a></li> </ul> </div> <div class="footer-v1-column"> <div class="footer_h">Legal</div> <ul id="footer-menu" class="footer-menu"> <li id="menu-item-231" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-231"><a href="https://assignmentessays.com/privacy-policy-2/" class=" ft_link">Privacy Policy</a></li> <li id="menu-item-232" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-232"><a href="https://assignmentessays.com/frequently-asked-questions-on-essay-writing-services/" class=" ft_link">FAQs</a></li> <li id="menu-item-233" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-233"><a href="https://assignmentessays.com/fair-use-policy/" class=" ft_link">Fair Use Policy</a></li> <li id="menu-item-325" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-325"><a href="https://assignmentessays.com/pricing/" class=" ft_link">Pricing</a></li> </ul> </div> <div class="footer-v1-column"> <div class="footer_h">How Our Service is Used:</div> <div>Assignment Essays essays are NOT intended to be forwarded as finalized work as it is only strictly meant to be used for research and study purposes. Assignment Essays does not endorse or condone any type of plagiarism.</div> </div> <div class="footer-v1-column"> <div class="footer-heading">Subscribe</div> <div class="subscribe-container w-embed"> <div class="lightbox__input-group sendgrid-subscription-widget widget-1297" data-emailerror="Please enter a valid email address" data-nameerror="Please enter your name" data-checkboxerror="Please tick the box to accept our conditions"> <div class="sg-response"></div> <form class="form-small sg-widget" onsubmit="return false;"> <input class="form-small-input sg_email" type="email" name="sg_email" placeholder="Your email address" required="required"> <button class="button small-form-arrow-button sg-submit-btn" type="submit"></button> </form> </div> </div> <div class="form-info"> <div>No Spam</div> </div> <img src="https://assignmentessays.com/wp-content/themes/essaypro/images/5e6b9cd665535a3422f5a6cb_new.svg" width="344" height="44" loading="lazy" alt="" class="image-2"> </div> </div> <div class="top_nav_footer"> <ul class="footer-v2-column"> <li class="menu-item menu-item-type-post_type menu-item-object-page menu-item-222"><a href="https://assignmentessays.com/assignment-essays/" class=" ft_link">Assignment Essays</a></li> <li class="menu-item menu-item-type-post_type menu-item-object-page menu-item-223"><a href="https://assignmentessays.com/nursing-essay-help/" class=" ft_link">Nursing Essay Help</a></li> <li class="menu-item menu-item-type-post_type menu-item-object-page menu-item-224"><a href="https://assignmentessays.com/economics-homework-help/" class=" ft_link">Economics Homework Help</a></li> <li class="menu-item menu-item-type-post_type menu-item-object-page menu-item-225"><a href="https://assignmentessays.com/psychology-homework-help/" class=" ft_link">Psychology Homework Help</a></li> <li class="menu-item menu-item-type-post_type menu-item-object-page menu-item-226"><a href="https://assignmentessays.com/math-homework-help/" class=" ft_link">Math Homework Help</a></li> <li class="menu-item menu-item-type-post_type menu-item-object-page menu-item-227"><a href="https://assignmentessays.com/homework-help/" class=" ft_link">Homework Help</a></li> <li class="menu-item menu-item-type-post_type menu-item-object-page menu-item-228"><a href="https://assignmentessays.com/cpm-homework-help/" class=" ft_link">CPM Homework Help</a></li> <li class="menu-item menu-item-type-post_type menu-item-object-page menu-item-229"><a href="https://assignmentessays.com/french-custom-essays-writing-services/" class=" ft_link">French custom essays writing services</a></li> </ul> </div> <div class="footer-bottom"> <div class="footer-bottom-left"> <ul class="social-icons-small"> </ul> </div> <div class="footer-bottom-right"> <div>© 2024 Assignment Essays. All rights reserved.</div> <div class="dot-divider white"></div> <div>Assignment Essays will be listed as ‘Assignment Essays’ on your bank statement.</div> </div> </div> </div> </div> </div> <div id="discountBanner" class="discount-banner"> <div class="container"> <div class="discount-banner__wrapper"> Order your essay today and save 25% with the discount code PYRAMID <div class="button-wrap"> <a href="/order" title="Order Now" class="button-order-now">Order Now</a> </div> </div> </div> </div> <link rel='stylesheet' id='ctawidgets-css' href='https://assignmentessays.com/wp-content/plugins/cta-widgets/css/widget.css?ver=52dcac36f26777c270c6ad1cebdbfcf7' type='text/css' media='all' /> <style id='ctawidgets-icon-inline-css' type='text/css'> @media screen and (min-width: 768px) { .article__cta:before { background-image: url(https://assignmentessays.com/wp-content/plugins/cta-widgets/icons/oval-archive.png); background-size: contain; background-position: center right; background-repeat: no-repeat } } </style> <link rel='stylesheet' id='wpnavigationbar-css' href='https://assignmentessays.com/wp-content/plugins/wp-navigation-bar/style.css?ver=52dcac36f26777c270c6ad1cebdbfcf7' type='text/css' media='all' /> <style id='wpnavigationbar-css-inline-css' type='text/css'> @media only screen and (min-width: 480px) { body.with_wpnavigationbar header:first-child {margin-top:55px !important;} }.discount-banner {background-color:#0f689b !important;}.discount-banner__text{color:#ffffff !important;}.discount-banner span {color:#f6a510 !important;}.discount-banner .button-order-now {background-color:#f6a510 !important;} @media only screen and (max-width: 480px) { .discount-banner { display: none; } } </style> <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js" id="jquery-js"></script> <script type="text/javascript" src="https://assignmentessays.com/wp-content/themes/essaypro/js/main.js?ver=1.0" id="essaypro-js-js"></script> <script type="text/javascript" src="https://assignmentessays.com/static/js/scripts.js" id="scripts-js"></script> <script type="text/javascript" src="https://assignmentessays.com/wp-content/themes/essaypro/periodic-table.js" id="periodic-table-script-js"></script>  <script type="text/javascript"> var Tawk_API=Tawk_API||{}, Tawk_LoadStart=new Date(); (function(){ var s1=document.createElement("script"),s0=document.getElementsByTagName("script")[0]; s1.async=true; s1.src='https://embed.tawk.to/5773f6ee767282275609f725/default'; s1.charset='UTF-8'; s1.setAttribute('crossorigin','*'); s0.parentNode.insertBefore(s1,s0); })(); </script>  </body> </html>