[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Finding Aids Navigation



Amy Cooper wrote:
> Our FAs are not EAD at this time.  Yet we're re-vamping the "front
> matter" or "cover page" as we begin to make more of our guides available
> online, and have stumbled upon an interesting question of how much
> navigational information to provide from the FA itself.

An important consideration here is the persistence of links.  Since you said your finding aids aren't
in EAD, I'm guessing (?) that you're presenting them as HTML.  Any links that you hard code into that
HTML will need to be changed when the links are no longer appropriate (moved Web pages, changes in
email addresses, etc.).  If possible, you may want to consider some sort of server-side includes.
These will tell the server to dump a chunk of content onto the page at the time that it is requested
by someone.  That way, when one of those chunks needs to be updated, it can be updated just once,
rather than for each individual document.  There are several different ways to do this, depending on
what software you're using.  The Society of American Archivists (SAA) site has actually moved in this
direction recently.  If you visit the site, you'll notice that pages have consistent headers and
footers for each page.  These are generated dynamically using active server pages (ASP):
http://www.archivists.org/

As you suggested, you could also use frames for this purpose, though frames do have a number of
disadvantages that should be considered seriously
http://www.useit.com/alertbox/9612.html
At the very least, you'll probably want to include a non-frames option if you do decide to use them.

> And from anyone interested in discussing it, this opens up an entire set of
> issues here about how users actually get to us:  that is, how do users find
> out about our online finding aids and what happens when they get there.  Do
> they do a Google search, drop into the finding aid itself and find
> themselves stranded when they can't get to the repository to figure out how
> to use the collection?  Or do they more often find the repository, and work
> their way down from there?

I think these are excellent questions, and ones that we can only answer through empirical data
collection.  In James Roth's study that he describes in his article from the latest edition of
American Archivist "Serving Up EAD" (Vol. 62, No. 2, p. 214-237), he reports that 61% of responding
institutions do not track the hits on their EAD finding aids.  This is quite unfortunate, since part
of the MIME header that's captured by server log software is the last URL that a user visited, i.e.
where he/she just came from.  This sort of information is extremely valuable in identifying usage
patterns.  It's important to remember that analyzing server logs is not just about adding up the total
number of hits.  Widely available server log software can provide a great deal of information about
access patterns, search terms, potential navigation problem areas, and popular content areas.  If
there is more than one view of the same finding aid, patterns of use of the various versions can also
be very revealing.

My armchair speculation is that the extent to which users enter finding aids directly will vary
considerably from one collection or institution to another, though I think it's fair to say that
allowing them to do so is extremely desirable.  Finding aids will always provide much more detailed
descriptive material, and thus potential access points, than the front page of a repository site.
Deep linking is a long-standing practice on the Web, and sites can live or die by it.  We cannot
assume that anyone with a potential interest in some specific aspect of one of our collections happens
to know what repository to visit in order to find the appropriate material.  Web sites of archives do
not have front doors in the same way that our buildings do.  People can enter from numerous
directions, and we should make it as easy as possible for them to do so.  The result will be a lot
more use and visibility for our collections.

For those institutions that serve up finding aids from EAD (or any other server-side format)
dynamically, search engines such as Google won't find that dynamic content.  There are a number of
ways around this issue, such as periodically creating static HTML versions of all finding aids or, at
the very least, "doorway pages" that are static HTML and include the most important access terms
within the finding aids, so there's some way to get to them through a major search engine.

Some other ways that users can get to finding aids are through links to them from other pages, online
public access catalogs (OPACS), third-party aggregators (a site that points to finding aids from a
consortium of different archives), or even email messages.  All of these entry mechanisms require a
consistent URL that either points to the finding aid directly or leads into a resolving mechanism that
can point to the finding aid.

It is important that users who get to a page have some way of travelling up the hierarchy of the site
or navigating to other finding aids.  Deep linking implies that each page must, on its own, allow the
user to get some sense of what the page is and how it fits into the general architecture of the site:
http://www.useit.com/alertbox/20020303.html

=========================================================
 Cal Lee
 University of Michigan
 School of Information
 Phone: 734-647-0505
 http://www-personal.si.umich.edu/~calz/
 "The boundary is the best place for acquiring knowledge."
                                      - Paul Tillich, 1930

A posting from the Archives & Archivists LISTSERV List!

To subscribe or unsubscribe, send e-mail to listserv@listserv.muohio.edu
      In body of message:  SUB ARCHIVES firstname lastname
                    *or*:  UNSUB ARCHIVES
To post a message, send e-mail to archives@listserv.muohio.edu

Or to do *anything* (and enjoy doing it!), use the web interface at
     http://listserv.muohio.edu/archives/archives.html

Problems?  Send e-mail to Robert F Schmidt <rschmidt@lib.muohio.edu>