Print

Print


For year's I've used the rule of thumb to not send an HTML page with more data than you could fit on a 1.4MB floppy drive. �As a pre-processing step in my EAD files before I send them to XTF, I have a perl script that scores each c0x of the dsc based on trial and error heuaristics. �In the XTF prefilter, I actually physically restructure the XML heiarachy at index time so the lazy tree is preset with 5000 point chunks. �I then have pageination set up, so you can page through the EAD file 5000 points at a time.


On Wed, Nov 13, 2013 at 4:02 PM, Mark R. Carlson <[log in to unmask]> wrote:
Hi Michael, I agree that such a large file would be very hard to navigate on a very small mobile device, but I'm including iPads and the like, whose screen size is equivalent to a netbook/small notebook computer. � There are two issues here: �1) optimizing display for mobile devices 2) processing large amounts of data in the most efficient way possible. � My solution, in contrast to complex/verbose HTML tables, does the latter. �It's also a low-cost solution for those who don't have the resources to implement more complex solutions. �If I recall, Michele is using XTF, which is what we're using, so doing a bit of stylesheet tweaking is definitely the easiest solution which wouldn't require any additional coding other that modifying the stylesheets. � When the cookbook stylesheets were created, CSS was in its infancy. �There wasn't much alternative to using HTML tables for layout and positioning. �That's not true any longer. �Much like, HTML frames, HTML tables are a relic from the past (in computer years, 10 years = an eternity).

Mark


On 11/12/2013 10:27 AM, Michael Fox wrote:
Mark's solution illustrates many useful features, not the least of
which is the simplicity that the use of CSS classes brings to the
rendered HTML and undoubtedly as well to the stylesheet. �Though I
would doubt the sanity of anyone who would want to display an HTML
document that is 115K lines long in a mobile device.

But Mark, are you not in effect creating a separate table with all the
details of cell padding for each component?

I wonder what the relative XSLT transformation and html display times
would be for this approach as opposed to a transformation that creates
an individual, traditional table (for want of a better term to
describe it) for each component.

As a clarification, the Cookbook stylesheets have always created a
separate table for individual each c01, not for the entire <dsc>, but
there is no reason that this could not be done at every component
level. �However, in that case, Mark's solution would have to be
speedier and much less verbous.

I have experimented with nested <div>s as Mark employs but with
relative and absolute positioning rather than cell-padding. � However,
I have encountered problems with some browsers rendering this
properly. � As anyone else tried this and, if so, have you found a
work-around?

I too would like to get away from tables. �Ugh.

But as Chris Prom points out faster HTML would not be the only
solution in this situation. Other technologies and other approaches
such as delivering the finding aid in segments have been used and
would seem to have advantages in several areas where large files are
involved. � �Who, after all, would want to scroll through 115,000
lines or even 5,000 lines in a single pass whatever the device they
are using? � This seems to me to be the very sort of problem that
hyper-linking is good at solving.

Michael Fox



On Tue, Nov 12, 2013 at 10:38 AM, Mark R. Carlson
<[log in to unmask]> wrote:
Hi Michelle-

The main problem with HTML tables is that the entire <table> must be
processed before the browser will display it. �I think many of us who based
our stylesheets off the original cookbook stylesheets are in this position
for these types of files. �Many modern browsers and *all* mobile browsers
choke on large HTML tables. � Some mobile browsers won't render them at all.
There's really no good reason to use them anymore because CSS can handle
this positioning much more efficiently. � I'm currently working on a "proof
of concept" CSS that will work in both regular and mobile browsers. �The
following file is 4.2 MB and comes out to 569 printed pages. �It's one of
our largest finding aids, but this CSS renders pretty quickly and it works
in mobile browsers. � View the source to see how CSS affects positioning.
It still needs work and tweaking, but the proof of concept is there: that
you can render large amounts of data quickly and efficiently.

http://www.lib.washington.edu/static/public/specialcollections/temp/JacksonMobile.html

I hope this helps.

Mark Carlson
UW Libraries, Seattle, WA

On 11/12/2013 7:36 AM, Michele R Combs wrote:
Hello collective wisdom --

We have two EAD-encoded finding aids whose size is causing problems for
some patrons -- their browser locks up or otherwise fails to load the file.
We don't render on the fly; we create static HTML files. �The problem is
partly file size (one is 3.4M and the other is 5.8M), and partly that the
inventory section is a ginormous HTML table (yeah, I know) which takes a lot
to render and load in the browser.

We've come up with a number of options, none of which I feel are ideal, so
I'm curious if others have encountered this, how you chose to handle it, and
what if any impact it had on search/discovery.

Michele
+++++++++++++++
Michele Combs
Lead Archivist
Special Collections Research Center
Syracuse University Libraries
315-443-2081
[log in to unmask]
scrc.syr.edu