Jul 282011
 

Repositories can be a little dry.  They can turn people off and take up can be constrained because repositories are, historically, a little drab.  JISC’s Kultur project looked in to this problem and discovered that researchers (especially from the Humanities) want some pizazz in the tools they use and so added lightboxes, thumbnails and slideshows to EPrints.  This part of EXPLORER aims to implement the same functionality.  There are two factors that make this a complex task.  The first is that EPrints is created using similar but fundamentally different technologies to DSpace.  The second is that research archives may contain many types of output from research.

A light box displaying thumbnails might look like this:

A lightbox with thumbnails

A lightbox with thumbnails of just images

Most examples of lightboxes showing thumbnails contain thumbnails of images.  Mixing thumbnails of images, videos, documents and datasets is hard when you consider that there are many types of document, many types of video, many types of dataset and that the first portion of an object, as a thumbnail, may misrepresent the research output.

The approach to take will be to expect the contributor to offer a thumbnail and put up a default thumbnail as an alternative.

As usual, we will try to use open source libraries for most of this portion of EXPLORER but from experience we expect most libraries will be an ill fit.  If you imagine a JavaScript library that displays thumbnails of images with a lightbox or slideshow of larger images, processing of the larger images to thumbnails must be carried out and the thumbnails must be stored or processed in real time.  The libraries will be unaware that their context is DSpace running as a Tomcat application.  As mentioned, most libraries will not be able to create thumbnails from all objects in the repository.

UPDATE 10th August

DSpace has a feature which creates thumb nails as a batch job.  This is the preferred route for thumbnail creation.  However, there is no support for video thumbnails and there are questions over the quality of thumbnails created.

Twitter’s @jukesie pointed me at:

Update 11th August
Discovered that you can upload thumbnails to an item but they are in a ‘bundle’ related to the item and are not associated with a bitstream.  I’m looking at a work around that allows this:
DSpace Thumbs And Bitstreams

DSpace Thumbs And Bitstreams

Without more code we can’t change the order of the bitstreams through this administration page.  The first thumbnail is the thumbnail that will be associated with the item but I might be able to use the description to imply the order.  ‘2 main’ would become the main thumbnail associated with the item.  This idea implies that the first 3 bitstreams of the item will have the 3 thumbnails.  If there are 4 bitstreams we need an extra thumbnail.  If ‘main’ appears by itself then it will be associated with the item but not displayed against a bitstream.  There might not be a bitstream bundled with the item.

Update 11th August 4.45pm

The above works for browsing.  Not too painful for administration.

 Update 26th August

This snippet of code allows the THUMBNAIL bundle to be available when processing the CONTENT bundle having sorted the THUMBNAILs by description:

      <xsl:variable name="thumbs">
        <xsl:for-each select="mets:fileSec/mets:fileGrp[@USE='THUMBNAIL']/mets:file/mets:FLocat[@LOCTYPE='URL']">
          <xsl:sort select="@xlink:label" />
          <xsl:copy-of select="."/>
        </xsl:for-each>
      </xsl:variable>

The following effectively zips up the to bundles:

 <xsl:for-each select="mets:fileSec/mets:fileGrp[@USE='CONTENT']/mets:file/mets:FLocat[@LOCTYPE='URL']">
 <xsl:variable name="pos" select="position()" />
        <xsl:variable name="description" select="@xlink:label"/>
        <xsl:variable name="format" select="@xlink:label"/>
 <xsl:variable name="thumbhref" select="exsl:node-set($thumbs)/*[$pos]/@xlink:href"/>
        <xsl:variable name="ahref" select="@xlink:href"/>

There is a problem.  The THUMBNAIL bundle will more or less need to be the same length as the CONTENT bundle.  It may be shorter but it can’t have gaps.  Administratively, this mean that dummy place holders may be needed to achieve the effect.

Complicating matters more I want to extend the proof of concept to include more control over the THUMBNAIL and CONTENT bundles by adding more to the THUMNAIL bundle descriptions:

Bitstreams and Descriptions

Bitstreams and Descriptions

 

Hidden in the descriptions of the THUMBS there are 3 layouts; a column of thumbnails and their attachments, a video video_1 and a carousel which displays thumbs using a sliding lightbox.  With the proof of concept code, right now, the three thumbs of video_1 all displayed.  This needs to be changed so only one thumbnail is used because video_1 is made up of an MP4, WebM and OGV video.

There are lots of ways to make life easier and lots to make them harder.  Through culture we could expect users not to include DOCs, PDFs etc in the carousel and have them displayed separately.  I haven’t come across, yet, a library that deals with every media type.  Video and image might be reasonable.  Video, image and audio may be going a step to far and including other media types in the carousel where there aren’t any handlers native to the browser (on any platform big or small) seems much too far.

 Posted by at 9:43 am