When we have a lot of data about a series that we want to make
searchable, we typically create an online index. The EAD finding aid
provides the basic description on the material, and then a link to the
index search is offered as part of <otherfindaid>. For instance, we have
a photo collection whose index is searchable at . We also have
name indexes which genealogists love at . Several of the
name indexes will pull up a copy of the actual record (death
certificates, animal brand books, etc), although the photo collection
hasn't been scanned.

Elizabeth Perkes
Electronic Records Archivist
Utah State Archives
346 South Rio Grande
Salt Lake City, UT 84101-1106
[log in to unmask]
The State Archives' hours of operation are Monday-Thursday, 7:00 a.m.
to 6:00 p.m. and closed on Friday. Please make a note of these hours.

>>> Jennie Levine Knies <[log in to unmask]> 2/8/10 7:23 AM >>>
I have found this discussion interesting, because this is something we

have also grappled with for a long time. Because I didn't want to fool

with breaking up a finding aid, we have gone ahead and mounted our 
largest ones in full, with the hopes that peoples' home connections, 
etc. would eventually be able to handle it.  Our largest to date (Spiro

Agnew papers - - is about 5.2 MB. We

had a lot of discussions about breaking it up, but in this case, the 
largest subseries really is the bulk of the finding aid, so there never

seemed to be a logical place to split it. We did some user studies a
years back showing that users did like to scroll and skim (for a while,

we experimented with a more fragmented view of our finding aids, and,
anything, it was frustrating to staff who were used to being able to 
scroll through a browser window.  Since we don't have a very advanced 
internal search or discovery feature, simple scrolling seems to be the

best option for now.

HOWEVER, we have a monster waiting in the wings.  We have a photograph

collection that is currently described in an Access database.  Initial

tests of the size of making the finding aid for the first series of
collection puts it in the 10 MB range. If we add the second series, I 
think we're talking more like 25MB. We had a project in the works,
has dwindled due to lack of staff time at present, to experiment with 
ways to make this collection viewable and understandable from within
confines of an EAD-encoded finding aid.  Since the collection is 
basically an alphabetical list of biographical and subject headings, we

had thought of creating alternate displays that might allow the user to

limit or sort in ways that would be more manageable.  It is something I

would really like to revisit sometime soon and address, as we really 
would like to make this collection's finding aid available online. For

example, in the biographical series, each heading also has a "category"

(like "actress" or "athlete"). We were exploring the idea of putting 
these terms into <controlaccess> subject tags within each <c0x> and
developing a style sheet that would allow users to click to limit the 
finding aid by each broad category.  I think we were almost there, and
still have the files... somewhere... but we got pulled into something 
else and never finished it.

Has anyone else played around with the idea of offering different 
displays to make the user experience more interactive?

Jennie Levine Knies
Manager, Digital Collections
2216 Hornbake Library
University of Maryland
College Park, MD 20742
(301)314-2558 TEL (301)314-2709 FAX
[log in to unmask] E-MAIL 

Custer, Mark wrote, On 2/7/2010 4:13 PM:
> Hi Jennifer,
> How long is long?  The biggest finding aid that we currently have is

> still under 3 MB, and I wouldn*t want to break it up (at least not
> canonical view of that page/finding aid).  I personally like to
equate a 
> single finding aid with one (possibly) long scroll (but I understand
> opposing view as well, and I nevertheless think that some delivery 
> options will change if EAC gains widespread adoption).  Of course,
> sure that there are EADs out there that easily exceed what most email

> clients would permit as an email attachment, so those might have
> concerns.
> One of the reasons that I like the *single scroll* approach,
though, is 
> because I often access finding aids straight from an external search

> engine (and it*s much easier to figure out where I land if
> contained therein).  The flipside of this, though, is that those very

> same search engines only index up to a certain, set limit (I*ve
> past quotes as low as 150 KB, but I just did a quick, informal test,
> both Google and Bing have indexed one of our finding aids up very
> to the 1 MB milestone; but after that, there*s nothing).  So, I
> expect Google to index everything (and researchers, of course, would

> need to make use of the tools that we provide at the site level
> and it just goes back to the fact that it*s best to have a finding
> with an excellent, narrative description.  Alternatively, I
wouldn*t use 
> the *search engine index-limit* as an argument for breaking up
> traditional view of a finding aid, since I*m sure that there are 
> container list series out there that also exceed that limit (in
short, I 
> wouldn*t try to break everything up just so that you think that 
> everything will be indexed by a search engine). 
> If delivery/size is an issue, though, my guess is that it would be 
> advisable to follow Yale*s route if you want to separate the
finding aid 
> (that way, you wouldn*t always have to create multiple EAD files
for a 
> single collection; you*d just be portioning out the sections that
> define).
> This begs the question:  what*s the biggest EAD online right now
> wouldn*t it be nice if there were an easy way to figure this out)? 
> largest one that I know of is for the Hugh Morton collection at UNC: 

>  (it*s HTML
version is 
> getting close to 8 MB, and it still has a long way to grow before
> complete).
> Mark Custer
> *From:* Encoded Archival Description List [mailto:[log in to unmask]] *On 
> Behalf Of *Betts, Jennifer
> *Sent:* Friday, February 05, 2010 4:28 PM
> *To:* [log in to unmask] 
> *Subject:* Long finding aids
> Hello all,
> Are there any repositories out there who are separating long finding

> aids into separate EAD files?  If so, would you mind sharing your 
> documentation of that process?  I have an idea of how we might do it,

> but would like to see how other repositories are handling this.
> Best wishes,
> Jennifer
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
> Jennifer J. Betts
> RIAMCO Project Manager
> John Hay Library, Box A
> Brown University
> Providence, RI  02912
> E-MAIL:  [log in to unmask] <mailto:[log in to unmask]>
> TEL:  (401) 863-2148