> From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf Of Junte Zhang
> Sent: Tuesday, November 12, 2013 1:34 PM
> To: [log in to unmask]
> Subject: Re: Very large finding aids
>
> What are the options that you don't like? :-)


Good question :)  

We thought about breaking it up by series, and clearly that's the most common solution (and the simplest).  The drawback is that if users do ctrl-F to find a term and don't realize that they're only seeing part of the finding aid, they may miss something.  In addition, in at least one case, it's one enormous series that's the culprit.  We'd have to break it in the middle of the series.  Doable, of course, but not ideal.

We thought about replacing the HTML with a PDF for these two, but our search interface is set up to exploit EAD tags to create facets and advanced search capability; if we add PDFs they won't be accurately represented in the index which feeds into the search results.  I suppose we could add some kind of file-size-checker that would bypass loading the file if it were too big and send them to a PDF instead, but that seems like overkill since it's only two finding aids out of 2000 that are a problem.

We thought about revamping our entire XSL so that the output wouldn't have tables -- personally I really would love to get rid of tables entirely! -- but again, for only two finding aids the cost/benefit didn't really seem worth it.  

I hadn't thought about using JSON or jquery/ajax  to serve up the file in pieces; I'll have to check into that and see what would be involved.

Thanks for all the many suggestions, everyone.
 
Michele