Wednesday, July 16, 2008

Replace, all or part?

Thanks for the question, Mark, on what gives--are we looking at replacing our whole ILS, or do we maintain our OPAC interface AND put up additional resource discovery interfaces such as WorldCat Local, VuFind, Primo, or Blacklight.

In reading over the posts to this blog, I am noticing two things that folks have mentioned. One is that their libraries are either in the process of replacing their ILS or looking to decouple their public library catalog interface and offer something completely new.

From my limited pointed of view, replacing the whole ILS is a long, slow, tedious process involving a lot of decision makers. Yet so much innovation is going on in user interfaces now. I'd hate to be stuck with my clunky Voyager interface for years longer while I wait for it to slowly upgrade, or wait for the whole RFP process to take place.

Some of my library patrons have told me "your library catalog is 10 years out of date." And "I can't find anything unless I know what I'm looking for." Frankly it isn't really true that the catalog is 10 years out of date. People forget how fast things have changed! But it sure seems like it when other interfaces around us like for Amazon and Google seem to be updating all the time and are so simple while our catalog is still using old search strategies. We've only last month implemented relevancy ranking in search results as the default, and this is only in one type of search--words anywhere. If you do a title search, it's still alpha order. And we still can't really do any sort of faceting of search results.

So for all of these reasons, I'm looking to make our public library catalog software something that runs far faster and is far easier to revise and update than what we have currently. And I don't want to wait. Long ago we used locally created interface software called NLS--it was decoupled from our ILS. Frankly with live linking out to grab the circulation status, I'm thinking decoupling our OPAC interface a better choice for library patrons now, given that there are far better indexing and web searching tools available than there were when we moved off the old NLS platform. By decoupling our catalog interface from our ILS, we'll be able to more quickly innovate and more quickly integrate journal article searching and other types of data with our catalog data. (Yes we have MetaLib and we can do metasearching, but in real-time it isn't quick. I'm really thinking pre-harvesting and indexing of various data feeds is a better solution for patrons in most cases.) Because if it's one thing I hear and see all the time, it's that people won't wait. If it's not fun to search and the results are overwhelming, they soon leave.

And besides, I think my co-worker Steve Meyer, and other library bloggers whose names I am not currently remembering have a good point that it's time to make software much faster than we've been able to in the past. It's time to actually control the interface our public sees. And maybe we'll learn something about indexing in the process.

1 comment:

Stephen Elfstrand said...

You're right that we need it now and can't wait. These features should already be included in the LMS decoupling makes sense right now but we must insist on better user interfaces as part of our next LMS