Code4Lib: Feb. 15: 20 minute sessions 2

By reeset / On / In Digital Libraries, Programming

Lipstick on a Pig: 7 Ways to Improve the Sex Life of your OPAC
Jim Robertson
This was interesting, but most of the information presented would be difficult to implement within Innovative.  The ILS that this presentation utilized was Voyager, one of may systems that is much more open that our ILS.  This actually is one of the many complaints that I have with Innovative.  Many ILS systems seem to print their HTML as a templates that can be modified.  III on the other hand provides a type of ini file that can be utilized to turn on buttons, change styles, but do little else.  I’m sure some of these things could be accomplished by inserting javascript into areas where button images would usually be stored (fortunately, III doesn’t validate their HTML), but it certainly wouldn’t be very clean.

AHAH: When Good is Better than Best
Casey Durfee
Using scriptlets or widgets rather than coding directly to the OPAC.

  • Scales well
  • Language agnostic
  • Upgrade proof
  • Reusable

 Another good idea, but again, this is for a system very different from III.  I’ve got a few comments on this and other sessions below.

Standards, Reusability and the Mating Habits of Learning Content
Robby Robson
What’s the problem

  • Learning content tends to be
  • re-used in small chuncks
  • highly interactive
  • evolving in sophistication
  • Lots of legacy content must be converted to run (and report results) to learning management systems.
  • Reuse requires mixing apples and oranges
  • Interoperability requires SCORM (Sharable Content Object Reference Model)
  • What is the technical problem

    • Content should be highly interactive
    • comes in different formats
    • comes with different navigation schemes
    • We need:
    • “SCOs? (Sharable Content Objects)
    • A common content model for SCOs

    Some additional comments.  Jeremy had mentioned this to me later in the conference, but why are we looking at adding so much information to the OPAC.  Maybe we should be looking to put the OPAC on a diet and look for ways to get users to stop using the OPAC so much as a crutch.  With new resources and services coming online, I find it sometimes too bad that we are in some ways limiting their full potential by trying to fit them into an outdated OPAC model.  Of course, I can say this because our OPAC doesn’t allow use to do much of this type of modification easily (granted, we could purchase a very expensive XML Server module — something that I think should just be a part of our ILS product — but we don’t have it and am not sure if we will be getting it in the near future).