Lecture Notes: Srilakshmi - CH Iinformation Management: Unit-Iv

IT6701 LECTURE NOTES: SRILAKSHMI.
CH IINFORMATION MANAGEMENT: UNIT-IV
UNIT IV
UNIT IV INFORMATION ARCHITECTURE Principles of Information

architecture and framework, Organizing information, Navigation systems
and Labelling systems, Conceptual design, Granularity of Content.
S.NO TOPIC
1 Principles of Information architecture and framework
2 Organizing information
3 Navigation systems
4 Labelling systems
5 Conceptual design
6 Granularity of Content.
IT6701 LECTURE NOTES: SRILAKSHMI.CH IINFORMATION MANAGEMENT: UNIT-IV
Principles of Information architecture and framework
Definition:
1. The structural design of shared information environments.

2. The combination of organization, labelling, search, and navigation systems
within
web sites and intranets.
3. The art and science of shaping information products and experiences to
support
usability and findability.
4. An emerging discipline and community of practice focused on bringing
principles of
design and architecture to the digital landscape.
Basic concepts of information architecture :
Information
We use the term information to distinguish information architecture from

dataand knowledge management. Data is facts and figures. Relational databases
arehighly structured and produce specific answers to specific questions.
Knowledge is the stuff in people’s heads. Knowledge managers develop tools,
processes, and incentives to encourage people to share that stuff. Information
exists in the messy middle. With information systems, there’s often no single
“right” answer to a given question. We’re concerned with information of all
shapes and sizes: web sites, documents, software applications, images, and
more. We’re also con-cerned with metadata : terms used to describe and
represent content objects such as documents, people, processes, and
organizations.
Structuring, organizing, and labelling
It’s what information architects do best. Structuring involves determining

the appropriate levels of granularity for the information “atoms” in your site,
and deciding how to relate them to one another. Organizing involves grouping
those components into meaningful and distinctive categories. Labeling means
figuring out what to call those categories and the series of navigation links that
lead to them.
Finding and managing
Findability is a critical success factor for overall usability. If users can’t

find what they need through some combination of browsing, searching, and
asking, then the site fails. But user-centered design isn’t enough. The
organizations and people who manage information are important, too. An
information architecture must balance the needs of users with the goals of the
business. Efficient content management and clear policies and procedures are
essential.
Art and science
Disciplines such as usability engineering and ethnography are helping to

bring the rigor of the scientific method to the analysis of users’ needs and
information- seeking behaviors. We’re increasingly able to study patterns of
usage and subsequently make improvements to our web sites. But the practice
of information architecture will never be reduced to numbers; there’s too much
ambiguity and complexity. Information architects must rely on experience,
intuition, and creativity. We must be willing to take risks and trust our intuition.
This is the “art”of information architecture.
Differences between books and web sites
Differences between libraries and web sites

BENEFITS OF INFORMATION ARCHITECTURE

The cost of not finding information
How many bad decisions are made every day in your organization because
employees didn’t find the information they needed? How much duplication of
effort results from this disconnect? How many customers do you lose because
they can’t find the product they want on your web site? How much do you
spend every day providing telephone support to existing customers because they
hate navigating your online technical-support database?
The value of education

What is the value of educating your customers about new products and services
related to the ones they’re actively seeking on your web site?
The cost of construction

What does it cost to design and build a web site? How much does it cost to redo
it six months later because it doesn’t support findability or doesn’t scale?
The cost of maintenance

Similarly, what does it cost to ensure that good designs don’t crumble over time?
Will the people who maintain your site know where to put new content and
when to remove outdated content?
The cost of training

For internal, mission-critical information systems that support call centers, for
example, what does it cost to train employees to use that system? How much
could you save if it wasn’t so complicated to use?
The value of brand

No matter how beautiful your web site is, if customers can’t find what they
need, your brand loses value in their eyes. How much did you spend on those
brand-building TV commercials?
The Anatomy of an Information Architecture
Visualizing Information Architecture

Why is it important to be able to visualize information architecture? There are several answers. One is that the
field is new, and many people don’t believe that things exist until they can see them. Another is that the field is
abstract, and many whomight conceptually understand the basic premise of information architecture won’t
really “get it” until they see it and experience it.
Organization systems
Present the site’s information to us in a variety of ways, such as content categories that
pertain to the entire campus (e.g., the top bar and its “Calendar” and “Academics”
choices), or to specific audiences
Navigation systems
Help users move through the content, such as the “A–Z Directory” and the “Go
Quickly To...” menu of popular destinations.
Search systems
Allow users to search the content. Here, the default is set to search the Gustavus
site, but one could also search the Gustavus calendar, its directory, or the whole
web from the site’s search interface.
Labeling systems
Describe categories, options, and links in language that (hopefully) is meaning-
ful to users; you’ll see examples throughout the page, some (e.g., “Admission”)
more understandable than others (“Nobel Conference”)
Information Architecture Components
Types of browsing aids include:
Organization systems
The main ways of categorizing or grouping a site’s content (e.g., by topic, by task,
by audiences, or by chronology). Also known as taxonomies and hierarchies. Tag
clouds (based on user-generated tags) are also a form of organization system.
Site-wide navigation systems
Primary navigation systems that help users understand where they are and where
they can go within a site (e.g., breadcrumbs).
Local navigation systems
Primary navigation systems that help users understand where they are and where
they can go within a portion of a site (i.e., a subsite).
Sitemaps/Tables of contents
Navigation systems that supplement primary navigation systems; provide a con-
densed overview of and links to major content areas and subsites within the site,
usually in outline form.
Site indices
Supplementary navigation systems that provide an alphabetized list of links to
the contents of the site.
Site guides
Supplementary navigation systems that provide specialized information on a spe-
cific topic, as well as links to a related subset of the site’s content.
Site wizards
Supplementary navigation systems that lead users through a sequential set of
steps; may also link to a related subset of the site’s content.
Contextual navigation systems
Consistently presented links to related content. Often embedded in text, and
generally used to connect highly specialized content within a site.
Search Aids
These components allow the entry of a user-defined query (e.g., a search) and auto-
matically present users with a customized set of results that match their queries.
Search interface
The means of entering and revising a search query, typically with information
on how to improve your query, as well as other ways to configure your search
(e.g., selecting from specific search zones).
Query language
The grammar of a search query; query languages might include Boolean opera-
tors (e.g., AND, OR, NOT), proximity operators (e.g., ADJACENT, NEAR), or
ways of specifying which field to search (e.g., AUTHOR=“Shakespeare”).
Query builders
Ways of enhancing a query’s performance; common examples include spell

check-ers, stemming, concept searching, and drawing in synonyms from a
thesaurus.
Retrieval algorithms
The part of a search engine that determines which content matches a user’s
query; Google’s PageRank is perhaps the best-known example.
Search zones
Subsets of site content that have been separately indexed to support narrower
searching (e.g., searching the tech support area within a software vendor’s site).
Search results
Presentation of content that matches the user’s search query; involves decisions
of what types of content should make up each individual result, how many
results to display, and how sets of results should be ranked, sorted, and
clustered.
Content and Tasks

These are the users’ ultimate destinations, as opposed to separate components
that get users to their destinations.
Headings
Labels for the content that follows them.
Embedded links
Links within text; these label (i.e., represent) the content they link to.
Embedded metadata
Information that can be used as metadata but must first be extracted (e.g.,
in arecipe, if an ingredient is mentioned, this information can be indexed
to supportsearching by ingredient).
Chunks
Logical units of content; these can vary in granularity (e.g., sections and
chap-ters are both chunks) and can be nested (e.g., a section is part of a
book).
Lists
Groups of chunks or links to chunks; these are important because they’ve
beengrouped together (e.g., they share some trait in common) and have
been pre-sented in a particular order (e.g., chronologically).
Sequential aids
Clues that suggest where the user is in a process or task, and how far he
has to go before completing it (e.g., “step 3 of 8”).
Identifiers
Clues that suggest where the user is in an information system (e.g., a logo
speci-fying what site she is using, or a breadcrumb explaining where in
the site she is).
Invisible Components
Certain key architectural components are manifest completely in the
background;users rarely (if ever) interact with them. These components often
“feed” other components, such as a thesaurus that’s used to enhance a search
query. Some examples of invisible information architecture components
include:
Controlled vocabularies and thesauri
Predetermined vocabularies of preferred terms that describe a specific

domain(e.g., auto racing or orthopedic surgery); typically include variant terms
(e.g.,“brewskie” is a variant term for “beer”).Thesauri are controlled
vocabularies that generally include links to broader and narrower terms, related
terms, and descriptions of preferred terms (aka “scope notes”). Search systems
can enhance queries by extracting a query’s synonyms from a controlled
vocabulary.
Retrieval algorithms
Used to rank search results by relevance; retrieval algorithms reflect their
pro-grammers’ judgments on how to determine relevance.Best bets Preferred
search results that are manually coupled with a search query; editors and subject
matter experts determine which queries should retrieve best bets, and which
documents merit best bet status.
1. Where am I?
2. I know what I’m looking for; how do I search for it?
3. How do I get around this site?
4. What’s important and unique about this organization?
5. What’s available on this site?
6. What’s happening there?
7. Do they want my opinion about their site?
8. How can I contact a human?
9. What’s their address?
Organizing Web Sites and Intranets
The organization of information in web sites and intranets is a major factor in

determining success, and yet many web development teams lack the
understanding necessary to do the job well. Our goal in this chapter is to
provide a foundation for tackling even the most challenging information
organization projects.
Organization systems are composed of organization schemes and organization

structures . An organization scheme defines the shared characteristics of content
items and influences the logical grouping of those items. An organization
structure defines the types of relationships between content items and groups.
Before diving in, it's important to understand information organization in the

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

supermarkets, and television programming guides all use organization schemes
to facilitate access. Some schemes are easy to use. We rarely have difficulty
finding a friend's phone number in the alphabetical organization scheme of the
white pages. Some schemes are intensely frustrating. Trying to find
marshmallows or popcorn in a large and unfamiliar supermarket can drive us
crazy. Are marshmallows in the snack aisle, the baking ingredients section,
both, or neither?
In fact, the organization schemes of the phone book and the supermarket are
fundamentally different. The alphabetical organization scheme of the phone
book's white pages is exact. The hybrid topical/task-oriented organization
scheme of the supermarket is ambiguous.
Exact organization schemes
Let's start with the easy ones. Exact organization schemes divide information
into well defined and mutually exclusive sections. The alphabetical organization
of the phone book's white pages is a perfect example. If you know the last name
of the person you are looking for, navigating the scheme is easy. Porter is in the
P's which is after the O's but before the Q's. This is called " known-item"
searching. 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 the user to know the specific name of the resource they are looking
for. The white pages don't work very well if you're looking for a plumber.
Exact organization schemes are relatively easy to design and maintain 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
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. See Figure 3-1 for
an example.
Figure 3-1. An alphabetical index supports both rapid scanning for a

known item and more casual browsing of a directory.
Chronological
Certain types of information lend themselves to chronological organization. For

example, an archive of press releases might be organized by the date of release
(see Figure 3-2). History books, magazine archives, diaries, and television
guides are organized chronologically. As long as there is agreement on when a
particular event occurred, chronological schemes are easy to design and use.
Figure 3-2. Press release archives are obvious candidates for chronological
organization schemes. 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 or search by keyword. A complementary
combination of organization schemes is often necessary.
Geographical
Place is often an important characteristic of information. We travel from one

place to another. We care about the news and weather that affects us in our
location. Political, social, and economic issues are frequently location-
dependent. With the exception of border disputes, geographical organization
schemes are fairly straightforward to design and use. Figure 3-3 shows an
example of a geographic organization scheme.
Figure 3-3. In this example, the map presents a graphical view of the
geographic organization scheme. Users can select a location from the map
using their mouse.
Ambiguous organization schemes
Now for the tough ones. Ambiguous organization schemes divide information
into categories that defy exact definition. 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 put it under fruit, berry, or vegetable?
However, they 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 organization schemes are exact and thereby easier
to create, maintain, and use. However, extensive research shows that library
patrons use 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 only have a vague information
need that you can't quite articulate. For these reasons, 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 system is well-designed, you also might learn along
the way. This is web surfing at its best.
Ambiguous organization supports this serendipitous mode of information

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
process 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 ambiguous organization schemes depends on the initial design of

a classification system and the ongoing indexing of content items. The
classification system serves as a structured container for content items. It is
composed of a hierarchy of categories and subcategories with scope notes that
define the types of content to be included under each category. Once this
classification system has been created, content items must be assigned to
categories accurately and consistently. This is a painstaking process that only a
librarian could love. Let's review a few of the most common and valuable
ambiguous organization schemes.
Topical
Organizing information by subject or topic is one of the most challenging yet

useful approaches. Phone book yellow pages are organized topically. That's why
they're the right place to look when you need a plumber. Academic courses and
departments, newspapers, and the chapters of most nonfiction books are all
organized along topical lines.
While few web sites should be 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
(see Figure 3-4 for an example). Others, such as those more commonly found in
corporate web sites, 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
web site.
Figure 3-4. Research-oriented web sites such as the Argus Clearinghouse

rely heavily on their topical organization scheme. In this example, the scope
note for the Arts and Humanities category is presented as well as the list of
subcategories. This helps the user to understand the reasoning behind the
inclusion or exclusion of specific subcategories.
Task-oriented
Task-oriented schemes organize content and applications into a collection of

processes, functions, or tasks. These schemes are appropriate when it's possible
to anticipate a limited number of high-priority tasks that users will want to
perform. Desktop software applications such as word processors and
spreadsheets provide familiar examples. Collections of individual actions are
organized under task-oriented menus such as Edit, Insert, and Format.
On today's Web, task-oriented organization schemes are less common, since

most web sites are content rather than application intensive. This should change
as sites become increasingly functional. Intranets and extranets lend themselves
well to a task orientation, since they tend to integrate powerful applications as

well as content. Figure 3-5 shows an example of a task-oriented site.
Figure 3-5. In this example, General Motors anticipates some of the most
important needs of users by presenting a task-based menu of action items.
This approach enables GM to quickly funnel a diverse user base into
specific action-oriented areas of the web site.
Audience-specific
In cases where there are two or more clearly definable audiences for a web site
or intranet, an audience-specific organization scheme may make sense. This
type of scheme works best when the site is frequented by repeat visitors who
can bookmark their particular section of the site. Also, it works well if there is
value in customizing 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 interest to that particular
audience. See Figure 3-6 for an example.
Figure 3-6. This area of the SIGGRAPH 97 conference web site is designed
to meet the unique needs of media professionals covering the conference.
Other SIGGRAPH audiences with special needs include contributors and
exhibitors.
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. A closed scheme may be appropriate if subscription fees or security
issues are involved.
Metaphor-driven
Metaphors are commonly used to help users understand the new by relating it to
the familiar. You need not look further than your desktop 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,
organization, and function of the web site (see "Metaphor Exploration" in
Chapter 8, "Conceptual Design").
While metaphor exploration can be very 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 web site 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 virtual library to be staffed by a librarian that will
answer reference questions. Most virtual libraries do not provide this service.
Additionally, you may wish to provide services in your virtual 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.
Figure 3-7 shows a more offbeat metaphor example.
Figure 3-7. In this offbeat example, Bianca has organized the contents of
her web site according to the metaphor of a physical shack with rooms.
While this metaphor-driven approach is fun and conveys a sense of place, it
is not particularly intuitive. Can you guess what you'll find in the pantry?
Also, note that features such as Find Your Friend don't fit neatly into the
metaphor.
Hybrid schemes
The power of a pure organization scheme derives from its ability to suggest a
simple mental model for users to quickly understand. Users easily recognize an
audience-specific or topical organization. However, when you start blending

elements of multiple schemes, confusion is almost guaranteed. Consider the
example of a hybrid scheme in Figure 3-8. This hybrid scheme includes
elements of audience-specific, topical, metaphor-based, and task-oriented
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.
Figure 3-8. A hybrid organization scheme
Examples of hybrid schemes are common on the Web. This happens because it
is often difficult to agree upon any one scheme to present on the main page, 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 retaining
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 (see Figure 3-9 for an example).
Figure 3-9. Notice that the audience-oriented scheme (contributors,

exhibitors, media) has been presented as a pure organization scheme,
separate from the others on this page. This approach allows you to present
multiple organization schemes on the same page without causing confusion.
Organization Structures
Organization structure plays an intangible yet very important role in the design
of web sites. While we interact with organization structures every day, we rarely
think about them. Movies are linear in their physical structure. We experience
them frame by frame from beginning to end. However, the plots themselves
may be non-linear, employing flashbacks and parallel subplots. Maps have a
spatial structure. Items are placed according to physical proximity, 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 web site and intranet
architectures include the hierarchy, the database-oriented model, and hypertext.
Each organization structure possesses 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 almost all good information architectures is a well-designed

hierarchy. In this hypertextual 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 information into hierarchies since the beginning of time. Family trees
are hierarchical. Our division of life on earth into kingdoms and classes and
species is hierarchical. Organization charts are usually hierarchical. 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 web sites that use
hierarchical organization models. They are able to develop a mental model of
the site's structure and their location within that structure. This provides context
that helps users feel comfortable. See Figure 3-10 for an example of a simple
hierarchical model.
Figure 3-10. A simple hierarchical organization 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 web
site 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 information hierarchies on the Web, 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. Ambiguous organization schemes in particular make it
challenging to divide content into mutually exclusive categories. Do tomatoes
belong in the fruit or vegetable or berry category? 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 companion listing of
products organized by topic. Topic and format are simply two different ways of
looking at the same information.
Second, it is important to consider the balance between breadth and depth in

your information hierarchy. Breadth refers to the number of options at 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 through an inordinate
number of levels to find what they are looking for (see Figure 3-11). If a
hierarchy is too broad and shallow, users are faced with too many options on the
main menu and are unpleasantly surprised by the lack of content once they
select an option.
Figure 3-11. In the narrow and deep hierarchy, users are faced with six
clicks to reach the deepest content. In the broad and shallow hierarchy,
users must choose from ten options to reach a limited amount of content.
In considering breadth, you should be sensitive to the cognitive limits of the

human mind. Particularly with ambiguous organization schemes, try to follow
the seven plus-or-minus two rule.[4] Web sites with more than ten options on
the main menu can overwhelm users.
In considering depth, you should be even more conservative. If users are forced
to click through more than four or five levels, they may simply give up and
leave your web site. At the very least, they'll become frustrated.
For new web sites and intranets that are expected to grow, you should lean
towards a broad and shallow rather than narrow and deep hierarchy. This
approach 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, the main page serves as the most
prominent and important navigation interface for users. Changes to this page
can really hurt the mental model they have formed of the web site over time.
Second, because of its prominence and importance, companies tend to spend
lots of care (and money) on the graphic design and layout of the main page.
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 is only
one component in a cohesive organization system.
Hypertext
Hypertext is a relatively new and highly nonlinear way of structuring

information. A hypertext system involves two primary types of components: the
items or chunks of information which are to be linked, and the links between
those chunks. These components can form hypermedia systems that connect
text, data, image, video, and infoarch chunks. Hypertext chunks can be
connected hierarchically, non-hierarchically, or both (see Figure 3-12).
Figure 3-12. In hypertext systems, content chunks are connected via links
in a loose web of relationships.
Although this organization structure provides you with great flexibility, it

presents substantial potential for complexity and user confusion. As users
navigate through highly hypertextual web sites, it is easy for them to get lost.
It's as if they are thrown into a forest and are bouncing from tree to tree, trying
to understand the lay of the land. They simply can't create a mental model of the
site organization. Without context, users can quickly become overwhelmed and
frustrated. In addition, hypertextual links are often personal in nature. The
relationships that one person sees between content items may not be apparent to
others.
For these reasons, hypertext is rarely a good candidate for the primary
organization structure. Rather, hypertext 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 to identify ways in which hypertext can complement the hierarchy.
The relational database model: A bottom-up approach
Most of us are familiar with databases. In fact, our names, addresses, and other
personal information are included in more databases than we care to imagine. A
database is a collection of records. Each record has a number of associated
fields. For example, a customer database may have one record per customer.
Each record may include fields such as customer name, street address, city,
state, ZIP code, and phone number. The database enables users to search for a
particular customer or to search for all users with a specific ZIP code. This
powerful field-specific searching is a major advantage of the database model.
Additionally, content management is substantially easier with a database than

without. Databases can be designed to support time-saving features such as
global search and replace and data validation. They can also facilitate
distributed content management, employing security measures and version
control systems that allow many people to modify content without stepping on
each others' toes.
Finally, databases enable you to repurpose the same content in multiple forms
and formats for different audiences. For example, an audience-oriented
approach might benefit from a context-sensitive navigation scheme in which
each audience has unique navigation options (such as returning to the main page
of that audience area). Without a database, you might need to create a separate
version of each HTML page that has content shared across multiple audiences.
This is a production and maintenance nightmare! In another scenario, you might
want to publish the same content to your web site, to a printed brochure, and to
a CD-ROM. The database approach supports this flexibility.
However, the database model has limitations. The records must follow rigid
rules. Within a particular record type, each record must have the same fields,
and within each field, the formatting rules must be applied consistently across
records. This highly structured approach does not work well with the
heterogeneous content of many web sites. Also, technically it's not easy to place
the entire contents (including text, graphics, and hypertext links) of every
HTML page into a database. Such an approach can be very expensive and time
consuming.
For these reasons, the database model is best applied to subsites or collections
of structured, homogeneous information within a broader web site. For
example, staff directories, news release archives, and product catalogs are
excellent candidates for the database model.
Designing databases
Typically, the top-down process of hierarchy design will uncover content areas
that lend themselves to a database-driven solution. At this point, you will do
well to involve a programmer, who can help not only with the database
implementation but with the nitty-gritty data modeling issues as well (see
Figure 3-13).
Figure 3-13. This entity relationship diagram (ERD) shows a structured

approach to database design. We see that entities (e.g., Resource) have
attributes (e.g., Name, URL). Ultimately, entities and attributes become
records and fields in the database. An ERD also shows relationships
between entities. For example, we see that each resource is available at one
or more locations. The ERD is used to visualize and refine the data model,
before design and population of the database. (This entity relationship
diagram courtesy of InterConnect of Ann Arbor, a technical consulting and
development firm.)
Within each of the content areas identified as candidates for a database-driven

solution, you will need to begin a bottom-up approach aimed at identifying the
content and structure of individual record types.
For example, a staff directory may have one record for each staff member. You
will need to identify what information will be made available for each
individual. Some fields such as name and office phone number may be required.
Others such as email address and home phone number may be optional. You
may decide to include an expertise field that includes keywords to describe the
skills of that individual. For fields such as this, you will need to determine
whether or not to define a controlled vocabulary.
A controlled vocabulary specifies the acceptable terms for use in a particular

field. It may also employ scope notes that define each term.
For example, the table below lists the controlled vocabulary for keywords in the
ecology area of the Argus Clearinghouse web site (see
http://www.clearinghouse.net). The scope notes explain that ecology is "the
branch of biology dealing with the relation of living things to their
environments." (See Figure 5-2 for an example of scope notes in action.) This
information is useful for the staff who index resources and the users who
navigate the web site.
Controlled Vocabulary
Argus Clearinghouse: Environment:

Ecology
biodiversity coastal zone management
conservation ecology (general)
environment environmental health
environmental resources environmental science
environmental studies land use
reef conservation roadkill
water resources wetlands conservation
wildlife wildlife management
wildlife rehabilitation
Use of a controlled vocabulary imposes an important degree of consistency that

supports searching and browsing. Once users understand the controlled
vocabulary, they know that a search on biodiversity should retrieve all relevant
documents. They do not also need to try biological diversity. In addition, this
consistency allows you to automatically generate browsable indexes. This is a
great feature for users, is not very difficult to implement, and is extremely
efficient from a site maintenance perspective (see Figure 3-14).
Figure 3-14. You can leverage a controlled vocabulary to automatically

generate browsable indexes. In this example, after selecting Environmental
Health from a menu of acceptable terms in the Ecology category, the user is
presented with a list of relevant resources. These resources have been
manually indexed according to the controlled vocabulary.
However, creating and maintaining a controlled vocabulary is not a simple task.

In many cases, complementing a simple controlled vocabulary that divides the
items into broad categories with an uncontrolled keyword field provides a good
balance of structure and flexibility. (For more on creating controlled
vocabularies, see Section 5.4.1.3, "Controlled vocabularies and thesauri" in
Chapter 5, "Labeling Systems".)
Once you've constructed the record types and associated controlled

vocabularies, you can begin thinking about how users should be able to navigate
this information. One of the major advantages of a database-driven approach is
the power and flexibility it affords for the design of searching and browsing
systems (see Figure 3-15). Every field presents an additional way to browse or
search the directory of records.
Figure 3-15. A database of organizational resources brings power and

flexibility to the Henry Ford Health System web site. Users can browse by
organizational resource or keyword, or perform a search against the
collection of records. The browsing indexes and the records themselves are
generated from the database. Site-wide changes can be made at the press of
a button. This flexibility is made possible by a database-driven approach to
content organization and management.
The database-driven approach also brings greater efficiency and accuracy to

data entry and content management. You can create administrative interfaces
that eliminate worry about HTML tags and ensure standard formatting across
records through the use of templates. You can integrate tools that perform
syntax and link checking. Of course, the search and browse indexes can be
rebuilt automatically after each addition, deletion, or modification.
Content databases can be implemented in a variety of ways. The database

management software can be configured to produce static HTML pages in batch
mode or to generate dynamic HTML pages on-the-fly as users navigate the site.
These implementation decisions will be influenced by technical performance
issues (e.g., bandwidth and CPU constraints) and have little impact upon the
architecture.
Designing Navigation Systems
On the Web, navigation is rarely a life or death issue. However, getting lost in a
large web site can be confusing and frustrating. While a well-designed
hierarchical organization scheme will reduce the likelihood that users will
become lost, a complementary navigation system is often needed to provide
context and to allow for greater flexibility of movement within the site.
Navigation systems can be designed to support associative learning by featuring

resources that are related to the content currently being displayed. For example,
a page that describes a product may include see also links to related products
and services (this type of navigation can also support a company's marketing
goals). As users move through a well-designed navigation system, they learn
about products, services, or topics associated to the specific content they set out
to find.
Any page on a web site may have numerous opportunities for interesting see
also connections to other areas of the site. The constant challenge in navigation
system design is to balance this flexibility of movement with the danger of
overwhelming the user with too many options.
Navigation systems are composed of a variety of elements. Some, such as

graphical navigation bars and pop-up menus, are implemented on the content-
bearing pages themselves. Others, such as tables of contents and site maps,
provide remote access to content within the organization structure. While these
elements may be implemented on each page, together they make up a
navigation system that has important site-wide implications. A well-designed
navigation system is a critical factor in determining the success of your web
site.
4.1. Browser Navigation Features
When designing a navigation system, it is important to consider the

environment the system will exist in. On the Web, people use web browsers
such as Netscape Navigator and Microsoft Internet Explorer to move around
and view web sites. These browsers sport many built-in navigation features.
Open URL allows direct access to any page on a web site. Back and Forward
provide a bidirectional backtracking capability. The History menu allows
random access to pages visited during the current session, and Bookmark
enables users to save the location of specific pages for future reference. Web
browsers also go beyond the Back button to support a "bread crumbs" feature by
color-coding hypertext links. By default, unvisited hypertext links are one color
and visited hypertext links are another. This feature helps users understand
where they have and haven't been and can help them to retrace their steps
through a web site.
Finally, web browsers allow for a prospective view that can influence how users
navigate. As the user passes the cursor over a hypertext link, the destination
URL appears at the bottom of the browser window, ideally hinting about the
nature of that content (see Figure 4-1). If files and directories have been
carefully labeled, prospective view gives the user context within the content
hierarchy. If the hypertext link leads to another web site on another server,
prospective view provides the user with basic information about this off-site
destination.
Figure 4-1. In this example, the cursor is positioned over the Investor Info
button. The prospective view window at the bottom shows the URL of the
Investor Info page.
Building Context
With all navigation systems, before we can plot our course, we must locate our
position. Whether we're visiting Yellowstone National Park or the Mall of
America, the You Are Here mark on fixed-location maps is a familiar and
valuable tool. Without that landmark, we must struggle to triangulate our
current position using less dependable features such as street signs or nearby
stores. The You Are Here indicator can make all the difference between
knowing where you stand and feeling completely lost.
In designing complex web sites, it is particularly important to provide context

within the greater whole. Many contextual clues in the physical world do not
exist on the Web. There are no natural landmarks and no north and south.
Unlike physical travel, hypertextual navigation allows users to be transported
right into the middle of a large unfamiliar web site. Links from remote web
pages and search engine result pages allow users to completely bypass the front
door or main page of the web site. To further complicate matters, people often
print web pages to read later or to pass along to a colleague, resulting in even
more loss of context.
the navigation system should present the structure of the information hierarchy
in a clear and consistent manner and indicate the location within that hierarchy.
See Figure 4-2 for an example.
Figure 4-2. The navigation system for the Argus Clearinghouse clearly shows
the path the user has taken through the hierarchy and indicates the user's
current location. This helps the user to build a mental model of the
organization scheme that facilitates navigation and helps them feel
comfortable.
Improving Flexibility
As discussed in the previous chapter, hierarchy is a familiar and powerful way of organizing
information. In many cases, it makes sense for a hierarchy to form the foundation for
organizing content in a web site. However, hierarchies can be fairly limiting from a
navigation perspective. If you have ever used the ancient information browsing technology
and precursor to the World Wide Web known as Gopher, you will understand the limitations
of hierarchical navigation. In Gopherspace, you were forced to move up and down the tree
structures of content hierarchies (see Figure 4-3). It was not practical to encourage or even
allow jumps across branches (lateral navigation) or between multiple levels (vertical
navigation) of a hierarchy.
Figure 4-3. On a Gopher site, you could only move up or down through the tree structure of
the hierarchy.
The Web's hypertextual capabilities removed these limitations, allowing tremendous freedom
of navigation. Hypertext supports both lateral and vertical navigation (see Figure 4-4). From
any branch of the hierarchy, it is possible and often desirable to allow users to laterally move
into other branches. For example, as you explore the Programs and Events section of a
conference web site, you may decide to register for that conference. A hypertext link should
allow you to jump to Registration without first retracing your steps back up the Programs and
Events hierarchy.
Figure 4-4. In a hypertext system, navigation links can completely bypass the hierarchy.
You can enable users to get anywhere from anywhere. However, as you can see from this
diagram, things can get confusing pretty quickly. It begins to look like an architecture from
M.C. Escher.
It is also possible and often desirable to allow users to move vertically from one level in a
branch to a higher level in that same branch (e.g., from a specific Program back to the main
Programs and Events page) or all the way back to the main page of the web site.
The trick with designing navigation systems is to balance the advantages of flexibility with
the dangers of clutter. In a large, complex web site, the 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.
Types of Navigation Systems

A complex web site often includes several types of navigation systems. To design a
successful site, it is essential to understand the types of systems and how they work together
to provide flexibility and context.
Hierarchical Navigation Systems
Although we may not typically think of it this way, the information hierarchy is the primary
navigation system. From the main page to the destination pages that house the actual content,
the main options on each page are taken directly from the hierarchy (see Figure 4-5). As
noted earlier, the hierarchy is extremely important, but also rather limiting. It is these
limitations that often require additional navigation systems.
Figure 4-5. Global Navigation Systems
Global Navigation Systems
A global or site-wide navigation system often complements the information hierarchy by

enabling greater vertical and lateral movement throughout the entire site. At the heart of most
global navigation systems are some standard rules that dictate the implementation of the
system at each level of the site.
The simplest global navigation system might consist of a graphical navigation bar at the
bottom of each page on the site. On the main page, the bar might be unnecessary, since it
would duplicate the primary options already listed on that page. On second level pages, the
bar might include a link back to the home page and a link to the feedback facility, as in
Figure 4-6.
Figure 4-6. The MVAC Web site employs a very simple, icon-based global navigation system.
A slightly more complex global navigation system may provide for area-specific links on
third level pages and below. For example, if a user explores the products area of the web site,
the navigation bar could include Main Page, Products, and Search. The obvious exception to
this rule-based system is that pages should not include navigation links to themselves. For
example, the main page of the products area should not include a Products link. However,
this is a great opportunity for the site's graphic designer to devise the navigation bar to show
that you are currently on the main page of the products area. Designers often leverage a
folder tab or button metaphor to accomplish this effect. (On the Argus web site, we use the @
sign from our corporate logo, as seen in Figure 4-7.)
Figure 4-7. For the Argus web site, graphic designers from Q LTD came up with a creative
and elegant solution to show context within the navigation system by leveraging the @ sign
from our corporate logo. In this example, the @ sign indicates that the Publications page is
within the What We Do area.
As you can see, this type of rule-based global navigation system can easily be applied
throughout the entire web site. The navigation system and the graphic design system should
be integrated to provide both flexibility and context. Note that the relative locations of the
options should remain the same from one version of the bar to another and that, since people
read from left to right, Main Page should be to the left of the other options. Both these factors
enhance the context within the hierarchy.
Local Navigation Systems
For a more complex web site, it may be necessary to complement the global navigation
system with one or more local navigation systems. To understand the need for local
navigation systems, it is necessary to understand the concept of a sub-site.[7] The term sub-
site was coined by Jakob Nielsen to identify the recurrent situation in which a collection of
web pages within a larger site invite a common style and shared navigation mechanism
unique to those pages.
For example, a software company may provide an online product catalog as one area in their
web site. This product catalog constitutes a sub-site within the larger web site of the software
company. Within this sub-site area, it makes sense to provide navigation options unique to
the product catalog, such as browsing products by name or format or market.
However, it is also important to extend the global navigation system throughout the sub-site.
Users should still be able to jump back to the main page or provide feedback. Local
navigation systems should be designed to complement rather than replace the global
navigation system (see Figure 4-8).
Figure 4-8. In this example, the bulleted options are part of a simple local navigation
system that guides users through information about the Digital Dissertations project. The
graphical buttons at the lower left of the page are part of the global navigation system.
This integration can be challenging, particularly when the global and local navigation
systems provide too many options. Alone they may each be manageable, but together on one
page, the variety of options may overwhelm the user. In some cases, you may need to revisit
the number of global and local navigation options. In others, the problem may be minimized
through elegant page design.
Ad Hoc Navigation
Relationships between content items do not always fit neatly into the categories of
hierarchical, global, and local navigation. An additional category of ad hoc links is more
editorial than architectural. Typically an editor or content specialist will determine

appropriate places for these types of links once the content has been placed into the
architectural framework of the web site. In practice, this usually involves representing words
or phrases within sentences or paragraphs (i.e., prose) as embedded hypertext links. This
approach can be problematic if these ad hoc links are important, since usability testing shows
"a strong negative correlation between embedded links (those surrounded by text) and user
success in finding information." Apparently, users tend to scan pages so quickly that they
often miss these less conspicuous links. You can replace or complement the embedded link
approach with external links that are easier for the user to see.
Embedded Links
As you can see, embedded links are surrounded by text.
Users often miss these links.
One Solution to the Embedded Link Problem is to give links their own separate lines within
the paragraph.
Another solution is to create a separate menu of ad hoc links at the top or bottom of the page
that point to useful related resources:
 Embedded Links
 Users
 One Solution to the Embedded Link Problem
The approach you use should be determined by the nature and importance of the ad hoc links.
For non-critical links provided as a point of interest, embedded links can be an elegant,
unobtrusive solution.
When using ad hoc links, it's important to consider whether the linked phrase provides
enough context for the user. In Figure 4-9, it's fairly obvious where the Digital Dissertations
Pilot Site link will take you. However, if 1861 or 1997 were underlined, you would be hard
pressed to guess where those links would lead. In designing navigation systems for the Web,
context is king.
Figure 4-9. Moderation is the primary rule of thumb for guiding the creation of embedded
ad hoc links. Used sparingly (as in this example), they can complement the existing
navigation systems by adding one more degree of flexibility. Used in excess, ad hoc links can
add clutter and confusion.
Labelling
Squandering Attention Spans
Rock music lyrics were still pretty simple back in the early `60s. Even with
folks like Little Richard screeching "A-wop-bop-a-loo-lop a-lop-bam-boo!" you
could generally understand what the words meant. But the music matured so
much so quickly during that decade that it soon supported the rise of a new
pasttime: rock lyric interpretation. Serious brainpower was deployed to interpret
what the heck it was that such lyrical giants as Bob Dylan, the Beatles, and Tiny
Tim really meant.
But those innocent days of recreational head-scratching have given way to an

era of abbreviated attention spans. Don't count on the Web maturing in the same
way that rock music did; that is to say, web users are not likely to spend much
time decoding what it was a web site designer really meant by labeling an item
Info or Stuff.
Making Bad Impressions
Besides immeasurably affecting navigation, labeling influences your site's users

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

example, the buttoned-down stuffiness of annual reports. At least for now, that
is. That's why investors were willing to pump millions into something called
Yahoo! (which, incidentally, is an acronym for "Yet Another Hierarchical
Officious Oracle"). A year before Yahoo! came out, we started something
stuffily named "The Clearinghouse for Subject-Oriented Internet Resource
Guides" (now called The Argus Clearinghouse: http://www.clearinghouse.net/);
if only we'd gone with something cuter or hipper -- for example, Dogwash! --
we would now be worth zillions.
Self-Centered Labeling
Labels can also expose an organization that, despite its best intentions, does not
consider the importance of its customers' needs as important as its own goals.
This is most common in web sites that use org-speak for their labels.
Labelling Systems
It's important to remember that labels, like organization and navigation systems,
are systems in their own right. So it follows that labeling systems, like any
other, require planning to succeed. To illustrate, let's compare two labeling
systems:
1. Unplanned Labeling System

2. Faculty Skunkworks
3. Office for Instructional Technology
4. K12 PDN Projects Web Page
5. Digital Libraries Project
6. Office of Technology Management
7. Extension Services
8. The New Media Center
9. Project 1999
10. Institute for Information Technology
11. English Composition Board
Technology Dissemination Office
12. Planned Labeling System

13. Arts & Humanities
14. Business & Employment
15. Communication
16. Computers & Information Technology
17. Education
18. Engineering
19. Environment
20. Government & Law
21. Health & Medicine
22. Places & Peoples
23. Recreation
24. Science & Mathematics
Social Sciences & Social Issues
Types of Labeling Systems
In web sites, labels come in two formats, textual and iconic. We typically find
them used in two ways: as links to chunks of information on other pages
(usually within the context of navigation systems, as index terms, or as labels
for links), and as headings that break up and identify the chunks of information
on the same page (much like the heading on this printed page). Of course, a
single label can do double duty; for example, the link Contact Us could lead to a
page that uses the title label Contact Us.
Labels Within Navigation Systems
Navigation system labels demand consistent application more than any other
type of labeling system. Navigation systemsoccur again and again within a web
site. Just as users rely on navigational systems to be positioned on a page
consistently and look the same throughout the site, they rely on their labels to
work in a consistent, familiar way, as in Figure 5-1. Effectively applied labels
are integral to building this sense of familiarity, so they'd better not change from
page to page. That's why using the label Main, on one page, Main Page on
another, and Home elsewhere will surely destroy the familiarity that the user
needs when navigating a site.
Figure 5-1. The labels Interact, View, Browse, and Search are part of a site-
wide navigation system. This labeling system uses consistent verb-based
terminology.
Some conventions have emerged for navigation system labels. You should
consider using these, as they are already familiar to most web users. Here is a
non-exhaustive list:
 Main, Main Page, Home, Home Page

 Search, Find, Browse, Search/Browse, Site Map, Contents, Table of
Contents, Index
 Contact , Contact Us, Contact Webmaster, Feedback
 Help, FAQ, Frequently Asked Questions
 News, What's New
 About, About Us, About <company name>, Who We Are
However, each example has two or more textual variants used to represent the
same information. So these conventions aren't completely conventional; use
them with care! At least use them consistently within your site, as in the
example in Figure 5-1.
Conversely, the same label can often represent different kinds of information.
For example, in one site News may link to an area in a site that includes
announcements of new additions to the site. In another site News may link to an
area of news stories describing national and world events. Obviously, if you use
the same labels in different ways within your own site, your users will be very
confused.
To address both problems, navigational labels can be augmented by brief

descriptions (also known as scope notes) when initially introduced. For
example, when a user first encounters these navigational labels on a site's main
page, he or she will get a sense of their meaning from their accompanying
descriptions:
Label Scope Note

Search this site by entering a query, or browse it via a
Search/Browse
comprehensive site map.
A direct line to our customer service department, with a 24-hour
Contact Us
turn-around guaranteed.
Keep current with our up-to-the-minute stock prices and press
News
releases.
Help Our site's FAQ, and how to contact our webmaster.
After this initial introduction, the user should easily understand how to use the
following navigation bar that appears on all the other pages in the site:
Search/Browse | Contact Us | News | Help
The labels are now familiar, and if used consistently, will work effectively.
Usability tests run on many major sites have confirmed the contextual value of
providing descriptions. The Argus Clearinghouse provides a more extensive
example of the use of scope notes (Figure 5-2).
Figure 5-2. Each category and subcategory is described further by a scope

note.
Labels as Indexing Terms
Labels are increasingly used as indexing terms for classifying the contents of
large sites. They work in two ways: enhancing a document's chance of getting
retrieved by a searching system, and supporting browsing within a site.
To support searching, keywords are assigned to a document, whether within the

<META> tag or in an accompanying database record that describes the
document's contents. These labels are usually heard but not seen; in other
words, they aren't necessarily visible to the user, but instead work in the
background to ensure a search engine appropriately indexes the document. For
example, we inserted the following code in the main page for International
Furniture Rentals (http://www.rent-ifr.com):
<META name="keywords" content="IFR Furniture Rentals, International

Furniture Rentals, IFR Rentals, relocation, furniture rental, furniture
leasing, interim housing, furnished apartments, executive suites,

residential furniture, office furniture">
These indexing terms are keywords that describe the company's services and
locations, as well as synonyms and name variants (e.g., IFR Rentals) that we
anticipated might be searched by users. Search engines, whether Web-wide
(e.g., Alta Vista, Hotbot) or specific to this site would then include these terms
in their indexes, thereby improving user searching.
Indexing labels effectively within a page's <TITLE> tags can similarly improve
a searcher's chances of retrieving the right pages in your site. In fact, we've
found that Web-wide search engine relevance ranking algorithms seem to
consider terms in a document's <TITLE> as very indicative of the document's
content, and so these documents often end up ranked quite highly on result lists.
In our own site, we included these descriptive labels within the <TITLE> tags:
<TITLE>Argus Associates. information architecture design, organization,

labeling, navigation, searching, indexing, intranets, Web sites</TITLE>
It's surprising that labels as indexing terms are not used more. Site sponsors do
crazy things to get their sites noticed, including advertising their URL on
banners flown over football stadiums, but they don't always bother to insert
accurate, descriptive terms in their site's pages.
Besides enhancing searching, index labels can also improve browsing. By using
keywords to manually index a site's content, you can provide additional means
for accessing its content beyond its main organization scheme. For example, the
Henry Ford Health System's site (shown in Figure 5-3) contains many records
for each department, division, hospital, program, and so on. Because those are
the major entities of the health system, they constitute the main organization
system for that content. However, we also added topical keywords to each
record (e.g., heart, kidney, liver, lung, skin graft, and transplantation) to allow
users to access the site's content by topic. This approach allows users to cut
across the grain of the site's main organization system and browse the content in
a completely different mode.
Figure 5-3. Content already accessible through a major organization system

(e.g., organizational designations such as Departments & Divisions) can also
be made accessible by indexing terms (e.g., keywords). In this case, each
keyword serves as a link, allowing users to access other content indexed under
the same keyword.
Link Labels
Labels are also used as textual links within the body or text of a chunk of
information. These aren't as difficult to create because, unlike navigation system
labels, they are naturally used in the descriptive context of their surrounding
text. See Figure 5-4 for an example of link labels.
Figure 5-4. In this example, the link labels are services, houses, directory, and
added. When people describe hypertext, they're often thinking of link labels.
Just because they're relatively easy to create doesn't mean they necessarily work
well. For example, take the following list of link labels:
Amalgamated
annual report
Bob Pobjoy
ButtMaster 5000
forty percent
Here, we have no clue what these labels mean because there is no context.
Without context, these aren't part of a system at all. Certainly, if they were
being used as part of a navigation system, they'd never work.
However, as we see these labels as links within the context of the text, they start
to make sense:
...Amalgamated employees believe in the products that they manufacture,

market, and sell. For example, forty percent of the company's employees
religiously work out on Amalgamated's ButtMaster 5000 at least once per work
day. According to Bob Pobjoy , Amalgamated's Chief Morale Officer, "It's a
great stress reducer, healthful, and good clean fun. And if you read our annual
report , you'll know that Amalgamated is firmly behind firm behinds" quips
Pobjoy....
Systematic consistency isn't an issue for link labels. These labels are glued
together by the copy, not by a particular system. However, consistency does
become an issue between these labels and the chunks of information they link
to.
For example, the link "annual report" may take the user to a page with the
heading Financial Information. Most users won't have a problem with this, but
at least a few will be confused. But if the link "Amalgamated" leads to a page
labeled Acme Corporation, most users won't bother reading the copy far enough
to learn that Amalgamated is really a division of Acme.
Avoiding the problems associated with inconsistencies between link labels and
where they lead is difficult. We'll never be certain, for example, what we get if
we select the link "Bob Pobjoy." A biography? A photo? A personal home
page? A mailto:? An entry in a corporate directory? Will "forty percent" lead to
a simple pie chart, or the results of a rigorous scientific study of Amalgamated

employee exercise habits? These problems can be minimized by asking
yourself, "What kind of information will the user expect to be taken to?" before
creating and labeling a link. Then, apply your answer consistently. For example,
consider having all references to personal names (e.g., Bob Pobjoy) lead to the
same sort of destination (e.g., always to a mailto: link).
A note of caution about link labels: links embedded in text can be difficult for
the eye to scan. They are fine for ad hoc links that cannot be easily separated
from surrounding text, but don't rely on them for frequently used links such as
navigational links.
Labels as Headings
Links are often used as headings that describe the chunk of information that
follows the heading. For example, the label for this part of the page you are
reading, "Labels as Headings," represents the chunk of information between it
and the next heading, "Iconic Labeling Systems." To some degree, a heading
label, like a link label, also relies on the text that follows to convey its meaning
(see Figure 5-5). However, unlike link labels, there is no guarantee that the user
will read the associated chunk of text. So there is extreme pressure on heading
labels to draw the user's attention to the accompanying chunk of information.
Figure 5-5. The obvious heading labels here are Submit a Guide, Comments
& Suggestions, and Opportunities. These were designed so that users could
understand what the labels represent without reading the actual copy.
Navigation and Contact Information could also be considered heading labels,
in this case for broader areas.
To ensure that your heading labels work well as a system, display the heading
labels from each page in your site as a single outline. Look for two
characteristics: consistency in terminology and consistency in granularity.
Consistent terminology means that the wording used among labels is uniform
and cohesive. Consistent granularity means two things: 1) that the chunks of
information represented at each level of labels are roughly of equal importance,
and 2) that the levels of labels don't vary greatly in how deeply they cover parts
of a site.
In the following example, we see the outlines for a site's main page and two of
its component pages:
Heading Labels from Main Page
GPSC: Global Psychic Services Corporation

Call our Telephone Hotline
GPSC Publications for Sale
For Prospective Employees
Search This Site
Questions/Feedback
Heading Labels from "GPSC Publications for Sale" Page #1
GPSC Publications for Sale: The Bon Vivant's Guide to Nouvelle Psychic
What is "Psychic Cooking"?
Synopsis
About the Author
What People are Saying About The Bon Vivant's Guide to Nouvelle
Psychic
Cooking
Testimonials
Reviews
Ordering Information
By Fax
By Telephone
Via the Internet
Heading Labels from "GPSC Publications for Sale"
Publications for Sale-"Your Psychic Pet"

How to Order This Book
The main page's problems with consistent terminology are due to a poor
organization system. These labels are a mix of tasks (e.g., Call our Telephone
Hotline, Search This Site), audiences (e.g., For Prospective Employees), and
general topics (e.g., GPSC Publications for Sale, Questions/Feedback). Because
the organization system is poorly designed, the labels that represent it are
confusing.
The two GPSC Publications for Sale pages have inconsistent labels for the main
heading and the ordering information:
Cooking vs. Publications for Sale-"Living with Psychic Pets"
Ordering Information vs. How to Order This Book
One echoes the original heading on the main page, while the other omits the
GPSC. One uses a colon, the other a dash to separate the generic label from the
publication's title. One uses italics, while the other encloses the title in quotation
marks. Also, these two pages have radically different sets of headings for no
particularly good reason. Mightn't users also want a synopsis and author
information for Your Psychic Pet?
Lastly, the first publication's page goes into much more detail than the second.
The first has a much finer level of granularity than does the second. For
example, on Page #1, there are heading labels for ordering By Fax, By
Telephone, and Via the Internet, but on Page #2 the granularity is coarser: we
only know How to Order This Book without mention of how it can be ordered.
Is there any good reason for this? This sort of problem is caused by carelessness
or, in other words, lack of planning.
Iconic Labeling Systems
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. We see them
frequently used as navigation labels. Additionally, 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. Consider the concept home page. You'll find that there are
icons that are commonly recognized as representing home pages. Here are a few
examples:
These icons come from IconBAZAAR (http://www.iconbazaar.com/).
But what about when you want to represent something more complex? Like, for
instance, a link to Press Releases? You may have occasionally seen a newspaper
or cascaded trio of icons, like these:
Does it work? Would you automatically know that these icons represent press
releases? Or would you have guessed that it represents a report? Or something
that's already in print? Or something else altogether?
English has over 610,000 words. Remarkably, English speakers have generally
agreed to certain conventions about its syntax and semantics. In other words,
there isn't much doubt what is meant by the textual label Main Page.
[14]According to Nettie Lagace, Reference Librarian at the Internet Public

Library (http://www.ipl.org), "If you take the Oxford English Dictionary as
gospel, (English) contains half a million words in the CD-ROM edition
(http://www.oup-usa.org/oed/oed2cdfaq.html) according to its own homepage,
but 616,500 words according to Harvard's link
(http://hplus.harvard.edu/descriptions/oed.html ). The Encyclopedia Britannica
says Webster's Third New International Dictionary of the English Language
(1961), another authoritative unabridged source, contains `more than 450,000'
words, but in its entry for `English Language' doesn't address the size of our
collective vocabulary." Thanks Nettie!
Iconic languages, however, are a bit more constrained. Because we're not all
artistic, it's harder to convey a concept visually than it is in text (see Figure 5-6).
For example, if I drew an image of a house for use as a main page icon, it's as
likely that you'd interpret my drawing as representing a home page as you'd
interpret it as a dog chasing its tail.
Figure 5-6. Jakob Nielsen of Sun Microsystems and Darrell Sano of Netscape
Communica-tions conducted an interesting study of how users interpreted the
icons Sun was considering using on its intranet. Our favorite results: the icon
for "Benefits" interpreted as "Clinton's health plan," the icon for "What's
New" interpreted as "Laundry," and the icon for "World Wide Web"
interpreted as "dimensions of the planet."
Even more than text labels, iconic labels rely on consistent positioning on a
site's pages. Moving them around from page to page can sacrifice the user's
ability to scan the page quickly and understand what the labels represent,
thereby negating much of the benefit of using iconic labels.
Conceptual Design
Based upon information gathered during the research phase, you must now
create order out of chaos. Is there a metaphor that will drive the organization of
the site? How should the information be organized and labeled at the highest
levels of the hierarchy? What types of navigation systems will be applied? How
will searching work? This is where the fun begins.
Early conceptual design meetings focus on metaphor and high-level

organization. You need to present possible organization schemes, balancing the
desire to reach consensus and move forward with the need to remain open-
minded about alternate approaches. White boards and flip charts, high-level
architecture blueprints, and scenarios are key tools at this stage. After the major
issues have been worked out, later meetings involve the consideration of more
detailed organization, labeling, indexing, and navigation systems. Detailed
blueprints and Web-based prototypes will serve you well in these discussions.
Brainstorming with White Boards and Flip Charts
For collaborative purposes, white boards are unparalleled. The ephemeral nature
of white board scribbling permits a creative freedom not found in other media.
The technology disappears and inhibitions fall away.
In early research-oriented meetings, white boards support collaboration around

the definition and refinement of the mission, vision, and goals of the project.
When working with several people from the organization, each with a different
set of experiences, perspectives, and goals, you can use the white board to help
identify issues, resolve differences, and achieve consensus.
White boards are also useful for considering possible information architectures.
Presenting ideas on the white board triggers new understanding and further
brainstorming (see Figure 8-1). The white board, the architect, and colleagues
become connected in a feedback cycle that moves towards the articulation of an
information architecture.
Figure 8-1. Sample white board scribblings
At face level, a major problem of white boards revolves around the difficulty of
recording a white-boarding session. White board scribblings do not leave a
permanent record. Ideas flow. The board fills up. The board is erased.
Eventually, everyone leaves and the scribblings remain trapped on the surface
of the white board, soon to be erased by the participants of the next meeting.
In reality, you can use this problem to your advantage. Each time consensus is
reached, record the relevant white board scribblings. Differences of opinion and
dead-end discussions are quickly forgotten and only the agreements remain.
Alternatively, if you're not comfortable with this level of sneakiness, you can
assign a designated notetaker to record agreements and disagreements alike.
We are aware of high-tech white boards that allow you to print or save your
scribbles. While we don't have much direct experience, we're guessing many of
these gadgets are more trouble than they're worth. Sorry for the skepticism, but
what do you expect from librarians?
While the flip chart is a close relative of the white board, several characteristics
distinguish the two. Advantages of using the flip chart during the research phase
include its high portability and intrinsic record-generating nature. Flip charts are
portable. Their tearaway sheets can be taken back to the office for study and
transcription. White boards are often anchored to walls and won't fit in your car.
However, flip charts don't really support iteration and collaboration. Due to the
difficulty of erasing ink on paper and the ugliness of extensively marked-up
pages, flip charts invoke in people a higher fear of error and greater resistance
to change. When working with flip charts, people try to get it right the first time.
Whether or not they succeed, they tend to live with the results rather than mark
up the page. This limits the freedom and creativity of group collaboration.
While the visible differences between white boards and flip charts are fairly
subtle and seemingly innocent, the ultimate impact upon the collaborative
process can be significant. For collaborative brainstorming, give us a white
board any day.
Metaphor Exploration
Metaphor can be a powerful tool for communicating complex ideas and

generating enthusiasm. By suggesting creative relationships or by mapping the
familiar onto the new, metaphor can be used to explain, excite, and persuade. In
1992, vice-presidential candidate Al Gore popularized the term information
superhighway. This term mapped the familiar and respected metaphor of the
physical highway infrastructure of the United States onto the new and
unfamiliar concept of a national information infrastructure. Gore used this term
to excite the voters about his vision for the future. While the term did
oversimplify and has since been horribly overused, it succeeded in helping
people to begin learning about and discussing the importance and direction of
the global Internet.
Three types of metaphor can be applied in the design of web sites. These are
organizational, functional, and visual metaphors:
 Organizational metaphors leverage familiarity with one system's

organization to convey quick understanding of a new system's
organization. For example, when you visit an automobile dealership, you
must choose to enter one of the following departments: new car sales,
used car sales, repair and service, or parts and supplies. People have a
mental model of how dealerships are organized. If you're creating a web
site for an automobile dealership, it may make sense to employ an
organizational metaphor that draws from this model.
 Functional metaphors make a connection between the tasks you can
perform in a traditional environment and those you can perform in a new
environment. For example, when you enter a traditional library, you can
browse the shelves, search the catalog, or ask a librarian for help. Many
library web sites present these tasks as options for users, thereby
employing a functional metaphor.
 Visual metaphors leverage familiar graphic elements such as images,

icons, and colors to create a connection to the new. For example, an
online directory of business addresses and phone numbers might use a
yellow background and telephone icons to invoke a connection with the
more familiar print-based yellow pages.
The process of metaphor exploration can get the creative juices flowing.
Working with your clients or colleagues, begin to brainstorm ideas for
metaphors that might apply to your project. Think about how those metaphors
might apply in organizational, functional, and visual ways. How would you
organize a virtual bookstore or library or museum? Is your site more like a
bookstore or a library or a museum? What are the differences? What tasks
should users be able to perform? What should it look like? You and your
colleagues should cut loose and have fun with this exercise. You'll be surprised
by the ideas you come up with.
After this brainstorming session, you'll want to subject everyone's brilliant ideas
to a more critical review. Start populating the rough metaphor-based
architecture with random items from the expected content to see if they fit. Try
one or two user scenarios to see if the metaphor holds up. While metaphor
exploration is a useful process, you should not feel obligated to carry all or any
of the ideas forward into the information architecture. The reality is that
metaphors are great for getting ideas flowing during the conceptual design
process, but can be problematic when carried forward into the site itself.
Scenarios
While architecture blueprints are excellent tools for capturing an approach to

information organization in a detailed and structured way, they do not tend to
excite people. As an architect who wants to convince your colleagues of the
wisdom of your approach, you need to help them envision the site as you see it
in your mind's eye. Scenarios are great tools for helping people to understand
how the user will navigate and experience the site you design. They will also
help you think through the experience your site will provide and may generate
new ideas for the architecture and navigation system.
To provide a multidimensional experience that shows the true potential for the
site, it is best to write a few scenarios that show how people with different needs
and behaviors would navigate your site. Before beginning the scenario, you
should think about the primary intended audiences. Who are the people that will
use your site? Why and how will they want to use it? Will they be in a rush or
will they want to explore? Try to select three or four major user types who will
use the site in very different ways. Create a character who represents each type.
Give them a name, a profession, and a reason for visiting your site, as
demonstrated in the sidebar. Then, begin to flesh out a sample session in which
that person uses your site. Try to highlight the best features of the site through
your scenario. If you've designed for a new customization feature, show how
someone would use it.
This is a great opportunity to be creative. You'll probably find these scenarios to

be easy and fun to write. Hopefully, they'll help convince your colleagues to
invest in your ideas.
Sample Scenario
Rosalind, a tenth grader in San Francisco, regularly visits the LiveFun Web site
because she enjoys the interactive learning experience. She uses the site in both
investigative mode and serendipity mode .
For example, when her anatomy class was studying skeletal structure, she used
the investigative mode to search for resources about the skeleton. She found the
interactive human skeleton that let her test her knowledge of the correct names
and functions of each bone. She bookmarked this page so she could return for a
refresher the night before final exams.
When she's done with homework, Rosalind sometimes surfs through the site in
serendipity mode. Her interest in poisonous snakes led her to articles about how
certain types of venom affect the human nervous system. One of these articles
led her into an interactive game that taught her about other chemicals (such as
alcohol) that are able to cross the blood-brain barrier. This game piqued her
interest in chemistry and she switched into investigative mode to learn more.
This simple scenario shows why and how users may employ both searching and
browsing within the web site. More complex scenarios can be used to flesh out
the possible needs of users from multiple audiences.
High-Level Architecture Blueprints
The collaborative brainstorming process is exciting, chaotic, and fun. However,

sooner or later, you must hole up away from the crowd and transform this chaos
into order. Blueprints are the architect's tool of choice for performing this
transformation.
The very act of shaping ideas into the more formal structure of a blueprint
forces you to become realistic and practical. If brainstorming takes you to the
top of the mountain, blueprinting brings you back down to reality. Ideas that
seemed brilliant on the white board may not pan out when you attempt to
organize them in a practical manner. It's easy to throw around concepts such as
audience-specific gateways and adaptive information architectures. It's not so
easy to define on paper exactly how these concepts will be applied to a specific
web site.
During the conceptual design phase, high-level blueprints are most useful for
exploring primary organization schemes and approaches. High-level blueprints
map out the organization and labeling of major areas, usually beginning with a
bird's-eye view from the main page of the web site. This exploration may
involve several iterations as you further define the information architecture.
High-level blueprints are great for stimulating discussions focused on the
organization and management of content as well as the desired access pathways
for users. These blueprints can be created by hand, but we prefer to use
diagramming software such as Visio or Net Objects Fusion. These products not
only help you to quickly layout your architecture blueprints, but can also help
with site production and maintenance.
Figure 8-3. This high-level blueprint shows pages, components within pages,
groups of pages, and relationships between pages. The grouping of pages can
inform page layout. For example, the three value-added guides should be
presented together, whereas Search & Browse, Feedback, and News should be
presented separately.
Let's walk through the blueprint in Figure 8-3, as we would when presenting it
to clients or colleagues. The building block of this architecture is the sub-site.
Within this company, the ownership and management of content is distributed
among many individuals in different departments. There are already dozens of
small and large web sites, each with its own graphic identity and information
architecture. Rather than try to enforce one standard across this collection of
sites, this blueprint suggests an umbrella architecture approach that allows for
the existence of lots of heterogeneous sub-sites.
Moving up from the sub-sites, we see a directory of sub-site records. This

directory serves as a card catalog that provides easy access to the sub-sites.
There is a sub-site record for each sub-site. Each record consists of fields such
as title, description, keywords, audience, format, and topic that describe the
contents of that sub-site.
By creating a standardized record for each sub-site, we are actually creating a

database of sub-site records. This database approach enables powerful known-
item searching and more exploratory browsing. As you can see from the Search
& Browse page, users can search and browse by title, audience, format, and
topic.
We also see three value-added guides. These guides take the form of simple
narratives or stories that introduce new users to the organization and to the web
site. Interwoven throughout the text of these narratives are in-context links to
selected sub-sites. They guide users through the site in an interesting and
friendly way.
Finally, we see a dynamic news billboard (perhaps implemented through Java or

JavaScript) that rotates the display of featured news headlines and
announcements. In addition to bringing some action to the main page, this
billboard provides yet another way to access important content that might
otherwise be buried within a sub-site.
At this point in the discussion of the high-level blueprint, you are sure to have
questions. As you can see, the blueprints don't completely speak for themselves.
This is why it's ideal to present these blueprints in person, so you can answer
questions and explore new ideas.
In addition, your architectural ideas may need selling. Now, we're not
suggesting that you buy a polyester suit, but an element of sales is involved.
You need to excite your clients and colleagues about your approach and vision
for the site. You need to explain the ideas behind your labeling and organization
schemes and describe how this model will support growth over time. These
challenges are difficult to address without a meeting (or at least a telephone
conference call).
However, if a meeting is simply not possible, you can accompany blueprints

with descriptive text-based documents that anticipate and answer the most likely
questions. You can then follow up with a conference call to answer the
questions you didn't anticipate and move the process along.
You should note that these high-level blueprints leave out quite a bit of
information. They focus on the major areas of the site, ignoring navigation
elements and page-level details. These omissions are by design, not by accident.
Shaping the information architecture of a complex web site is a challenging
intellectual exercise. You and your colleagues must be able to focus on the big
picture issues at hand. For these blueprints, as with the web sites you design,
remember the rule of thumb that less is more. Detailed page-level blueprints
come later in the process.
Architectural Page Mockups
Information architecture blueprints are most useful for presenting a bird's-eye

view of the web site. However, they do not work well for helping people to
envision the contents of any particular page. They are also not straightforward
enough for most graphic designers to work from. In fact, no single format does
a perfect job of conveying all aspects of an information architecture to all
audiences. Because information architectures are multi-dimensional, it's
important to show them in multiple ways.
For these reasons, architectural page mockups are useful tools during
conceptual design for complementing the blueprint view of the site. Mockups
are quick and dirty textual documents that show the content and links of major
pages on the web site. They enable you to clearly (yet inexpensively)
communicate the implications of the architecture at the page level. They are
also extremely useful when used in conjunction with scenarios. They help
people to see the site in action before any code is written. Finally, they can be
employed in some basic usability tests to see if users actually follow the
scenarios as you expect. Keep in mind that you only need to mockup major
pages of the web site. These mockups and the designs that derive from them can
serve as templates for the design of subsidiary pages.
Figure 8-4. In this architectural mockup of a combination search/browse

page, we show an area for entering queries and an area for browsing. We
typically use a word processor like Microsoft Word to create these mockups
quickly. However, you can also create quick and dirty HTML mockups, and
even work quite interactively with the graphic designer.
In the example in Figure 8-4, you see that mockups are easier to read than
blueprints. By integrating aspects of the organization, labeling, and navigation
systems into one view, they will help your colleagues to understand the
architecture. In laying out the content on a page mockup, you should try to show
the logical visual grouping of content items. In this example, the search
interface and the browsing options are two separate content groups. You can
also indicate prominence in these mockups. Placing a content group at the top of
the page or using a larger font size indicate the relative importance of that
content. While the graphic designer will make the final and more detailed layout
decisions, you can make a good start with these mockups.
Design Sketches
Once you've developed high-level blueprints and architectural page mockups,

you're ready to collaborate with your graphic designer to create design sketches
on paper of major pages in the web site. In the research phase, the design team
has begun to develop a sense of the desired graphic identity or look and feel.
The technical team has assessed the information technology infrastructure of the
organization and the platform limitations of the intended audiences. They
understand what's possible with respect to features such as dynamic content
management and interactivity. And, of course, the architect has designed the
high-level information structure for the site. Design sketches are a great way to
pool the collective knowledge of these three teams in a first attempt at interface
design for the top level pages of the site. This is a wonderful opportunity for
interdisciplinary user interface design.
Using the architectural mockups as a guide, the designer begins sketching pages
of the site on sheets of paper. As the designer sketches each page, questions
arise that must be discussed. Here is a sample sketching session dialog:
Programmer:
I like what you're doing with the layout of the main page, but I'd like to
do something more interesting with the navigation system.
Designer:
Can we implement the navigation system using pull-down menus? Does

that make sense architecturally?
Architect:
That might work, but it would be difficult to show context in the

hierarchy. How about a tear-away table of contents feature? We've had
pretty good reactions to that type of approach from users in the past.
Programmer:
We can certainly go with that approach from a purely technical

perspective. How would a tear-away table of contents look? Can you
sketch it for us? I'd like to do a quick-and-dirty prototype.
As you can see, the design of these sketches requires the involvement of people
from all three teams. It is much cheaper and easier for the group to work with
the designer on these rough sketches than to begin with actual HTML page
layouts and graphics. These sketches allow rapid iteration and intense
collaboration. The final product of a sketching session might look something
like that in Figure 8-5.
Figure 8-5. In this example, Employee Handbook, Library, and News are
grouped together as the major areas of the web site. Search/Browse and
Guidelines/Policies make up the bottom of the page navigation bar. A news
area defines space for a dynamic Java-based news panel.
Web-Based Prototypes
For the architect, a high point of conceptual design comes when a highly skilled
graphic designer creates beautiful Web-based prototypes. More than sketches or
scenarios, these digital renditions show how the site will look and function.
While the balance of attention shifts with these prototypes towards the aesthetic
considerations such as page layout and graphic identity, the prototypes
frequently identify previously unseen problems or opportunities related to the
information architecture. Once your architecture and navigation system are
embodied in actual web pages, it becomes much easier for you and your
colleagues to see whether they are working.
The designer may begin with two concepts based upon a single information
architecture. After getting feedback from the client, the designer and architect
may work together to adapt and extend the preferred concept. At this point,
conceptual design ends and planning for production begins. The most exciting
challenges for the architect have been met and the days of detail begin.
GRANULARITY
The process of editing content to improve granularity is often referred to as

‘chunking’.
Granularity is a relative measurement of how general or specific a piece of

information is.
Website content tends to be highly-granular due to a combination of factors:
 download speed
longer-length web content is typically broken into smaller sections
(webpages) to reduce file size
 navigation
the process of making information available via a website often involves
creating micro-content summaries, e.g. news headlines, navigation labels,
related links
 subject matter
websites are often constructed around specific topics or in response to
frequently asked questions—this information is granular by nature
 The difficulty of reading onscreen
users have less tolerance for reading onscreen than in print, due to screen
resolution, lack of orientation cues, etc.
 search engine ranking
search engine ranking logics (algorithms) favour webpages dedicated to a
specific topic (i.e. webpages that contain a large number of topic-specific
terms) above webpages containing information on a range of topics
Labels as Headings
Links are often used as headings that describe the chunk of information that
follows the heading. For example, the label for this part of the page you are
reading, "Labels as Headings," represents the chunk of information between it
and the next heading, "Iconic Labeling Systems." To some degree, a heading
label, like a link label, also relies on the text that follows to convey its meaning
(see Figure 5-5). However, unlike link labels, there is no guarantee that the user
will read the associated chunk of text. So there is extreme pressure on heading
labels to draw the user's attention to the accompanying chunk of information.
Figure
The obvious heading labels here are Submit a Guide, Comments &
Suggestions, and Opportunities. These were designed so that users could
understand what the labels represent without reading the actual copy.
Navigation and Contact Information could also be considered heading
labels, in this case for broader areas.
To ensure that your heading labels work well as a system, display the heading
labels from each page in your site as a single outline. Look for two
characteristics: consistency in terminology and consistency in granularity.
Consistent terminology means that the wording used among labels is uniform
and cohesive. Consistent granularity means two things: 1) that the chunks of
information represented at each level of labels are roughly of equal importance,
and 2) that the levels of labels don't vary greatly in how deeply they cover parts
of a site.
In the following example, we see the outlines for a site's main page and two of
its component pages:
Heading Labels from Main Page

GPSC: Global Psychic Services Corporation
Call our Telephone Hotline
GPSC Publications for Sale

For Prospective Employees
Search This Site
Questions/Feedback
GPSC Publications for Sale: The Bon Vivant's Guide to Nouvelle
Psychic Cooking
What is "Psychic Cooking"?
Synopsis
About the Author
What People are Saying About The Bon Vivant's Guide to
Nouvelle Psychic
Cooking
Testimonials
Reviews
Ordering Information
By Fax
By Telephone
Via the Internet
Publications for Sale-"Your Psychic Pet"
How to Order This Book
The main page's problems with consistent terminology are due to a poor
organization system. These labels are a mix of tasks (e.g., Call our Telephone
Hotline, Search This Site), audiences (e.g., For Prospective Employees), and
general topics (e.g., GPSC Publications for Sale, Questions/Feedback). Because
the organization system is poorly designed, the labels that represent it are
confusing.
The two GPSC Publications for Sale pages have inconsistent labels for the main
heading and the ordering information:
Cooking vs. Publications for Sale-"Living with Psychic Pets"
Ordering Information vs. How to Order This Book
One echoes the original heading on the main page, while the other omits the
GPSC. One uses a colon, the other a dash to separate the generic label from the
publication's title. One uses italics, while the other encloses the title in quotation
marks. Also, these two pages have radically different sets of headings for no
particularly good reason. Mightn't users also want a synopsis and author
information for Your Psychic Pet?
Lastly, the first publication's page goes into much more detail than the second.
The first has a much finer level of granularity than does the second. For
example, on Page #1, there are heading labels for ordering By Fax, By
Telephone, and Via the Internet, but on Page #2 the granularity is coarser: we
only know How to Order This Book without mention of how it can be ordered.
Is there any good reason for this? This sort of problem is caused by carelessness
or, in other words, lack of planning.
Heterogeneity
Heterogeneity refers to an object or collection of objects composed of unrelated

or unlike parts. You might refer to grandma's homemade broth with its
assortment of vegetables, meats, and other mysterious leftovers as
heterogeneous. At the other end of the scale, homogeneous refers to something
composed of similar or identical elements. For example, Oreo cookies are
homogeneous. Every cookie looks and tastes the same.
An old-fashioned library card catalogue 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 catalogue. Each record contains the same fields: author, title, and
subject. It is a high-level, single-medium system, and works fairly well.
Most web sites, on the other hand, are highly heterogeneous in two respects.
First, web sites often provide access to documents and their components at
varying levels of granularity. A web site might present articles and journals and
journal databases side by side. Links might lead to pages, sections of pages, or
to other web sites. Second, web sites typically provide access to documents 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, info arch, and interactive applications. The
web site is a great multimedia melting pot, where you are challenged to
reconcile the cataloguing of the broad and the detailed across many mediums.
The heterogeneous nature of web sites makes it difficult to impose highly

structured organization systems on the content. It doesn't make sense to classify
documents at varying 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 (GIF, TIFF, etc.) and resolution (640x480, 1024x768, etc.). It is
difficult and often misguided to attempt a one-size-fits-all approach to the
organization of heterogeneous web site content.
Labelling System Scope and Size
Decisions about which terms to include need to be made in the context of how
broad and how large a labelling system is required. First, determine if the
labelling system has obvious gaps. Does it encompass all the possibilities that
your site may eventually need to include? If, for example, your site is an online
store that currently allows users to search a product database but does not
support online ordering, ask yourself if eventually it might. Even if you're not
certain, assume it will. Then devise a label for online ordering that fits within
the rest of the labelling system. Or, if the site's labelling system is topical,
anticipate the topics not yet covered by the site. In both cases, you might be
surprised; you might learn that the addition of these phantom labels has a large
impact on your labelling system, perhaps sufficiently enough for you to change
its conventions in terms of wording, and so on. If you avoid this exercise, you
might learn the hard way that future content doesn't fit well into your site
because you're not sure how to label it, or it ends up in cop-out categories such
as Miscellaneous, Other Info, and Stuff. Plan ahead so that labels you might add
in the future don't throw off the current labelling system.
Balance this planning with an understanding of what your labeling system is

there to accomplish. If you try to create a labeling system that encompasses the
whole extent of human knowledge (instead of the current and anticipated
content of your web site), you will encounter the sorts of nasty problems that
the folks who created the LCSH have discovered. Keep your scope narrow and
focused enough so that it can clearly address the requirements of your site's
unique content and the special needs of its audiences, but be comprehensive
within that well-defined scope.
Also consider the overall size of the labelling system. Obviously, if the goal is
to label a navigation system, five or ten terms may be all you need. On the other
hand, if you're creating a system for indexing the content of a large site, the
labelling system may include hundreds of terms. What you'll want is the right
level of granularity for your labelling system. Granularity, as mentioned before,
refers to how specific you want to be in identifying and labelling your site's
content. If you have ten thousand documents, can you use a labelling system of
ten terms to label them? Sure, but under each label, you'd find hugely long and
unusable lists of documents. On the other hand, if you use a three-tiered
labelling system with hundreds of terms, users might shy away from its
complexity. Is there a middle ground that makes sense in terms of labelling
system size, a solution large enough to appropriately label the content, but not
too overwhelming for users? If not, you might have to adjust the granularity that
your labelling system is addressing. Perhaps instead of attempting to label every
document, you'll have to address a coarser level of granularity by labeling
logical groupings of documents (e.g., all the documents from the same
department or by the same author) instead of each individual document.

Lecture Notes: Srilakshmi - CH Iinformation Management: Unit-Iv

Uploaded by

Copyright:

Available Formats

Lecture Notes: Srilakshmi - CH Iinformation Management: Unit-Iv

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture Notes: Srilakshmi - CH Iinformation Management: Unit-Iv

Uploaded by

Copyright:

Available Formats

IT6701 LECTURE NOTES: SRILAKSHMI.

CH IINFORMATION MANAGEMENT: UNIT-IV

UNIT IV INFORMATION ARCHITECTURE Principles of Information

Principles of Information architecture and framework

1. The structural design of shared information environments.

Basic concepts of information architecture :

We use the term information to distinguish information architecture from

Structuring, organizing, and labelling

It’s what information architects do best. Structuring involves determining

Finding and managing

Findability is a critical success factor for overall usability. If users can’t

Art and science

Disciplines such as usability engineering and ethnography are helping to

Differences between books and web sites

Differences between libraries and web sites

BENEFITS OF INFORMATION ARCHITECTURE

The value of education

The cost of construction

The cost of maintenance

The cost of training

The value of brand

The Anatomy of an Information Architecture

Visualizing Information Architecture

Information Architecture Components

Types of browsing aids include:

Ways of enhancing a query’s performance; common examples include spell

Content and Tasks

Controlled vocabularies and thesauri

Predetermined vocabularies of preferred terms that describe a specific

Organizing Web Sites and Intranets

The organization of information in web sites and intranets is a major factor in

Organization systems are composed of organization schemes and organization

Before diving in, it's important to understand information organization in the

We navigate through organization schemes every day. Phone books,

Exact organization schemes

An alphabetical organization scheme is the primary organization scheme for

Figure 3-1. An alphabetical index supports both rapid scanning for a

Certain types of information lend themselves to chronological organization. For

Place is often an important characteristic of information. We travel from one

Ambiguous organization schemes

There's a simple reason why people find ambiguous organization schemes so

Ambiguous organization supports this serendipitous mode of information

The success of ambiguous organization schemes depends on the initial design of

Organizing information by subject or topic is one of the most challenging yet

Figure 3-4. Research-oriented web sites such as the Argus Clearinghouse

Task-oriented schemes organize content and applications into a collection of

On today's Web, task-oriented organization schemes are less common, since

well to a task orientation, since they tend to integrate powerful applications as

Audience-specific schemes can be open or closed. An open scheme will allow

Second, metaphors can introduce unwanted baggage or be limiting. For

Figure 3-7 shows a more offbeat metaphor example.

audience-specific or topical organization. However, when you start blending

Figure 3-8. A hybrid organization scheme

Figure 3-9. Notice that the audience-oriented scheme (contributors,

The hierarchy: A top-down approach

The foundation of almost all good information architectures is a well-designed

parent-child relationships of hierarchies are simple and familiar. We have

Figure 3-10. A simple hierarchical organization model.