SIGIA-L Mail Archives: Re: SIGIA-L: Site Map vs. Site Index
Re: SIGIA-L: Site Map vs. Site Index
From: Samantha Bailey (a2slb_at_earthlink.net)
Date: Tue Jan 15 2002 - 13:48:58 EST
I'm inclined not to be a big fan of a site map, for more or less the reason
you state--if the hierarchy and categories are clear, it may not be a huge
value-add to replicate them. (On the other hand, with a highly complex
portal-type site (like Yahoo), perhaps there is a value to bringing all
these disparate elements under one roof). Reservations about site maps
aside, I'm a huge fan of the site index, from the perspective that all sites
should have more than one route/path to access information. This is
something I've posted here before, but I'll add it below in case anyone is
interested.
Samantha Bailey
samantha_at_baileysorts.com | http://baileysorts.com
Samantha's take on site maps vs. indexes (written as an informal memo for a
colleague, 9/01):
Site maps and indexes are two very different finding aids (also
known as information retrieval tools).
Site maps are generally graphical representations of a site in whole or in
part. They attempt to help users develop a mental model for the site by
representing the hierarchical groupings and categories of the site.
Site maps can range from very sophisticated graphical representations to
more simple text-based views of the information space. This URL discusses
some of the more sophisticated approaches to site maps:
http://www.peterme.com/browsed/browsed050101.html. You've already
identified a very basic approach in the Wachovia site, and we also looked
at Vanguard's site map yesterday:
http://www.vanguard.com/site/sitecontents.html
Site maps can help users get a sense of the breadth and depth of a site and
are most useful from a broad perspective--helping new users get a sense of
how the site is structured and helping repeat users return to a general
area of the site. Site maps are *not* very helpful in locating specific
pieces of information (e.g., finding a page in the site they recall having
seen, finding the pages that reference a concept in the site).
Site indexes are text based information retrieval tools that are generally
alphabetically ordered and allow users to identify key information
regardless of level of granularity in a site. For example, a site map will
have to identify a "cut off" point in the hierarchical representation
(usually 2-3 levels deep) to avoid being completely overwhelming and
unusable. That means that page level information will typically not appear
on a site map, even though there will be important pages that appear
relatively deep within the site structure that it can make sense to "pull
up" into an index, making that content more accessible to users. Indexes
tend to be very valuable to new users who want to get a sense of the topics
and content covered in the site and to return users who are seeking "known
item" information (at times site indexes are used first by users who want
to scan/browse content, other times indexes are referred to when full-text
searching has either turned up too many or too few/no results).
I am a strong proponent of providing a site index in conjunction with the
search interface (there is actually evidence that a full-text search
engine can actually make it harder for users to successfully find
information) for several reasons--users may not know that indexes exist or
are useful, users may be inclined to use an index following a failed search
(which is why it's critical for the index or links to the index to appear
prominently any search results page that doesn't produce results).
Here are some example site indexes:
Sun Microsystems has a very comprehensive site index:
http://www.sun.com/siteindex/
Vanguard's is pretty sophisticated; it uses a controlled vocabulary to
suggest synonymous ("see") and related ("see also") information. It also
has the glossary integrated with the index results.
http://www.vanguard.com/site/search.html
Some site indexes cover a specific area of a site in detail rather than
presenting the entire site. For example, there is a "diseases" index on the
Web MD Health site: http://my.webmd.com/condition_center_all and the Adobe
site has a product index:http://www.adobe.com/products/main.html
Note that many sites opt to provide both maps and indexes because they
support different kinds of information seeking needs.
Because site indexes and site maps are different tools that produce
different retrieval effects for users, it's important to consider what need
we're trying to meet by providing one (or both) these tools.
To generalize, a map helps users develop a mental model of how we organize
the site. It helps them get a sense of depth and breath. It can help locate
information that appears at higher levels of the site and it can help users
find sections/areas of the site. (Note: keep in mind that providing a map
becomes complex when a site is going to change radically because the map
needs to change to reflect that structural redesign in ways that an index
will *not* (the alphabetical organization is going to stay the same
regardless of where an area of a site "lives" logically).) An index helps
users locate important information on the site regardless of granularity
and it has an organization scheme that people are very familiar with and
that doesn't change when the site structure changes (on the other hand,
indexes are generally more labor intensive to develop than site maps).
----- Original Message -----
From: Mike Combs <mike_combs_at_yahoo.com>
To: <sigia-l_at_asis.org>
Sent: Tuesday, January 15, 2002 6:54 AM
Subject: RE: SIGIA-L: Site Map vs. Site Index
> I would argue that a well designed site, with clear categories and
> information hierarchy, eliminates the need for a site map.
>
> ____________________________
> Mike Combs
> mike_combs_at_yahoo.com
>
>
> -----Original Message-----
> From: owner-sigia-l_at_asis.org [mailto:owner-sigia-l_at_asis.org]On Behalf Of
> Karuna Venter
> Sent: Tuesday, January 15, 2002 1:19 AM
> To: sigia-l_at_asis.org
> Subject: SIGIA-L: Site Map vs. Site Index
>
>
> Jakob Nielsen's most recent AlertBox column was about "site maps":
>
> http://www.useit.com/alertbox/20020106.html
>
> In it he flat-out says "we strongly recommend having a clear link to the
> site map on every page. Call the link Site Map. This label worked well in
> our study, and is the one used by 63% of sites with site maps."
>
> He makes no mention of the other oft-used term, "site index", which I have
a
> personal preference for. I like the word "map" for its implication of a
> visual aid to navigation, but since the most effective designs for these
> areas of a site are collections of well organized words, I think the word
> "index" is more accurate here.
>
> But do users (ummm or Interactors?) understand the word "index" to mean "a
> place where you can go to get help finding what you're looking for"?
Jakob
> doesn't say, and I am wondering if anyone on the list has any hard data to
> support "map" vs. "index", or vice versa.
>
> Certainly the site index of which I speak bears little resemblance to its
> print counterpart, the extremely helpful and totally (IMO) underestimated
> book index. But does that make the term "index" any less accurate or
useful
> in the context of web navigation?
>
> Here's my guess: probably this is a purely semantic distinction that
doesn't
> make much of a difference at the end of the day. If users (ummm,
> customers?) can't find the link in the first place (as Jakob laments), and
> in the second place may not use it even if they did find it, it would seem
> probable that the people who might differentiate between a "map" and an
> "index" would also understand that in the context of web navigation, the
> terms are basically interchangeable.
>
> But I'm open to being wrong, so if you have data and/or a strong opinion,
> would you let me know?
>
> Thanks,
>
> Karuna Venter
> Information Architect
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:58 EST
|
