 |
 |
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 >>>>