Hi Nathan,
FWIW, here's an example of how we've split up a large finding aid at
UMass. Each series title links to the in-depth dsc for that series.
http://www.library.umass.edu/spcoll/ead/mums312.htm
Nothing fancy but does the trick.
Aaron
-----
Aaron Rubinstein
Digital Project Manager
Special Collections and University Archives
UMass Amherst Libraries
On 12/6/10 4:29 PM, Jonathan Rochkind wrote:
> There is no magic way to make a 2.5M file load quickly in a browser --
> let alone be actually useable once in a browser window. (What human is
> going to read 40 or 50 or 100 pages all at once in a browser window?).
>
> 2.5M is just too big for a web page. You're going to have to split it up.
>
> On 12/6/2010 3:41 PM, Nathan Tallman wrote:
>> Ethan: All of our online finding aids are static HTML files, with a
>> handful
>> generated from EAD 1.0 files. I'm working towards getting all our finding
>> aids in EAD and will probably use XTF to publish them, but that's a
>> ways off
>> at this point. In regards to this example (EAD v. 2002), yes, the<dsc> is
>> causing the file to be so large. The collection is over 1200 boxes and
>> the
>> description is at the folder level. There's not much external content to
>> point to, so I'm not sure if XInclude or EAD pointers will help. I'll
>> look
>> into using AJAX.
>>
>> Dave and Brian: I've been trying to avoid breaking the page into multiple
>> files, but it may get to that point. If I split the page into say three
>> parts and then combined them on one page using the include function of
>> PHP,
>> would I still have to same problem? I'll look into gzip too.
>>
>> There's another live version of this finding aid that's been up for
>> years<
>> http://americanjewisharchives.org/aja/WJC/wjc-main.htm>. It's generated
>> from an EAD 1.0 file and uses (gasp!) frames. You can probably tell by
>> looking at it why I would like to replace it. It was encoded a bit wonky
>> too, with separate<dsc> section for each series. That's been corrected in
>> the new EAD v. 2002 file.
>>
>> Thanks for your replies!
>>
>> Nathan
>>
>> On Mon, Dec 6, 2010 at 3:02 PM, Ethan Gruber<[log in to unmask]> wrote:
>>
>>> Hi Nathan,
>>>
>>> A 5 MB EAD XML file will result in an HTML file of at least that
>>> size, so
>>> certainly 5 MB will result in a long load time for people on a slower
>>> DSL
>>> connection, or God forbid, dialup (does dialup still exist?).
>>>
>>> A few questions first:
>>> Are your finding aids transformed into HTML files that are served up
>>> statically or generated dynamically?
>>> Is it your list of components (<dsc>) that is so large?
>>>
>>> You may be able to find your way around the filesize issue using Ajax to
>>> dynamically load content only when the user asks for it. There may
>>> also be
>>> an alternate way of encoding your finding aid in order to reduce its
>>> filesize, either by using XInclude or EAD pointers to external content.
>>> XIncludes in conjunction with Ajax calls can alleviate problems in
>>> rendering
>>> in the public interface as well as make it possible to view the XML
>>> files
>>> in
>>> Notepad/Dreamweaver again.
>>>
>>> Ethan
>>>
>>> On Mon, Dec 6, 2010 at 2:49 PM, Nathan Tallman<[log in to unmask]>
>>> wrote:
>>>
>>>> Hi Cod4Libers,
>>>>
>>>> I've got a LARGE finding aid that was generated from EAD. It's over
>>>> 5 MB
>>>> and has caused even Notepad++ and Dreamweaver to crash. My main concern
>>> is
>>>> client-side load time. The collection is our most heavily used and the
>>>> finding aid will see a lot of traffic. I'm fairly adept with HTML,
>>>> but I
>>>> can't think of anything. Does anyone have any tricks or tips to
>>>> decrease
>>>> the load time? The finding aid can be viewed at<
>>>> http://www.americanjewisharchives.com/aja/FindingAids/ms0361.html>.
>>>>
>>>> Thanks,
>>>> Nathan Tallman
>>>> Associate Archivist
>>>> American Jewish Archives
>>>>
|
