Dilettante's Ball

Why Dan is wrong (and, yet, totally right)

Dan has written (twice now) about the ‘ILS Bill of Rights’ and its complete lack of perspective.

He’s right in his equation (or lack thereof) of the OPAC to “Free Speech” and “lack of Government Oppression regarding which religion I choose”; however, I disagree with him about the ability to be able to freely change vendors at will when the vendor doesn’t meet our needs (which means we’d be changing vendors, like, weekly).

That being said… why bother with the ILS?

Art Rhyno and I have been trying for more than a year to extract our bib database into a Lucene index to work with as we please. It took until NCSU released their Endeca index for us to be taken even remotely seriously. Still, the question remains… why bother with the ILS? If we can change the public interface, are the staff interfaces so lacking? Do we need to AJAX-ify the cataloging client or the circulation interface?

Dan’s right, we don’t need an ILS “Bill of Rights”, but we do need to fix our problems. And we don’t have to change vendors to do so — we just need a bit of vision.

Posted

in

by

Ross

Tags:

Comments

2 responses to “Why Dan is wrong (and, yet, totally right)”

  1. Brad LaJeunesse Avatar
    Brad LaJeunesse

    Why did it take you a year to extract your bib database? (Perhaps your ILS was a little coy in revealing its secrets?) I don’t know, I am genuinely curious.

    Fixing just the public interface is like trying to cover rotten wood with a new paint job. Sure, it may look great for a little bit, but it’s brittle and transient. What happens when the underlying ILS changes? What happens with the next ILS upgrade? Take it from a person who has done a lot of work over a rotting ILS core, and who has been stung many times by (undocumented) changes in upgrades and patches. At least for me, maintaining the patchwork ended up being /more/ work than just writing the ILS myself.

    The foundation (the ILS) needs to be fixed first, so that any enhancements like your OPAC can be placed on top of open, extensible, and standardized interfaces. Otherwise you’re heading down a road with no headlights and no map.

    To another point: we’ve implemented so many work-arounds to get the staff-side sort of working with our current vendor-supplied ILS, it is not even funny. I am sure other ILS systems are similar. Pat your head, rub your tummy, make the book checkout. I have a feeling that many staff don’t openly complain about the crappy staff-side interface because /that is all they know/– it is their reality. Keep slogging in the coal mine.

    Why not migrate to an enterprise-class ILS built on open source components? Why not build your extra spicy OPAC on a real platform instead? Or would that be too /hard/? …or /scary/?

  2. Ross Avatar
    Ross

    Well, it’s taken this long for a couple of reasons — The first was our approach, since Art has somewhat different goals than I do (to pull the data out of Oracle on LCC and keep it synched via wget/WebDAV), so I was just piggybacking on his plumbing. The second was finding time to work on it since it was too abstract a concept (at the time) to try to pitch it to our respective libraries.

    Granted, it took about 3 hours for me to set up our Zebra database based on the MARC export tool in Voyager. So, it’s all about ‘approach’. Zebra has a somewhat different set of issues, though, so it’s a bit of a trade-off. A 364 day and 21 hour tradeoff.

    I guess I’m not really in a position to weigh in on staff interfaces; I don’t use them, I don’t have access to them. I also don’t hear very many complaints about them. I /do/ hear /lots/ of complaints about WebVoyage, though. And I can begin to address those.

    I guess we’re talking about two different issues — an environment I can control and an environment I can’t (and have little desire to). That’s not to say that I won’t keep promoting Evergreen (since it would make the environment I can control even easier), but I have little-to-no influence over migration to it.

Leave a Reply

Your email address will not be published. Required fields are marked *