[Web4lib] RE: library automation vendors

[Kevil, L H.]

Hi all,

This has been a most interesting thread, with some very telling comments from Dave Walker and Jim Campbell. Perhaps I could add my two cents, based on experience from long ago. 

The division of the problem into front-end and back-end is reasonable, but somewhat incomplete in library automation. The back-end database is limited in many important ways by the data and the difficulty of working with MARC records. Libraries normally have changed cataloguing policy over time. (E.g., twenty-five years ago my library found that LC cataloguing was not up to our high standards.) This factor and the inevitable differences of opinion among our fellow librarians leads to conflicting requirements that give developers headaches (and heart attacks, in one case I know of.) The collective personality of a library can be very finicky and insistent on a particular feature that may conflict with requirements of other libraries. The resulting functional limitations are the source of many problems often attributed to the user interface.

In the old days before GUI interfaces I tried to accommodate these factors by creating tables that individual libraries could use for customization purposes. But you can only go so far with that approach. Dave Walker hits the customization nail on the head when he mentions local use of xml. Bill Drew says he is not a programmer and wants vendors to do this for him. But given the right toolset I think savvy people like Bill could accomplish much on their own.

I particularly appreciate Jim Campbell's suggestion that we concentrate our resources on the metasearch engine, not the OPAC.  Why indeed do we stubbornly retain exclusive allegiance to a local file of MARC data, inconsistent, expensive, and not well suited for Internet resources? Why not use a national database such as WorldCat or RLIN for our books? And in particular why maintain the tradition of focussing our resources on books and journals alone and ignoring the articles in the journals? Really excellent questions, Jim. The ongoing progress in creating usable identifiers for bibliographic entities - the works, their containers, and individual library holdings - gives me a lot of hope.

Hunter

L. Hunter KEVIL
Collection Development Librarian
University of Missouri-Columbia
Columbia, Missouri 65201

KevilL at missouri.edu
573-884-8760

-----Original Message-----
From: web4lib-bounces at webjunction.org
[mailto:web4lib-bounces at webjunction.org]On Behalf Of Jim Campbell
Sent: Tuesday, July 19, 2005 8:39 AM
To: web4lib at webjunction.org
Subject: RE: [Web4lib] RE: library automation vendors


Couple of thoughts reading this discussion.

1. I'd agree that there are vendors who don't get public interfaces, but
there are some who do. The best make an effort to spend time with their
customers and their customers' customers and learn. I've been told by some
people who've done this kind of work for vendors that their main limitation
is the conservatism of many librarians, that things like RSS feeds and
interfaces that can be used with handhelds are just not something the
majority of their customers are asking for right now.

2. What we really ought to be thinking about is not the interface to the
OPAC, but the interface to the metasearch engine. The OPAC is essential for
some users, largely irrelevant for others, and it's time to break down the
information divide between books and articles, between local and remote,
bought and free. OPACs are among the easiest things to integrate into
metasearch. 

3. Just how much localization do you need in your OPAC anyway?  I don't
entirely understand why we all still have these local databases. Sure,
metasearch engines can bridge gaps and give our customers easy access to
local, consortial, national and international holdings, but aren't we
approaching a point where it would be simpler to use WorldCat or the RLIN
Bib File as the opac and get rid of a lot of the local overhead? It's not
just user interfaces that cost big bucks, so do hardware, systems staff,
software purchase and maintenance.
 
- Jim Campbell
 
Digital Access Coordinator and Librarian for German
E-Mail: Campbell at Virginia.Edu | Voice: 434-924-4985
 
Digital Access Services, University of Virginia Library
http://www.lib.virginia.edu/digital/das/
 

> -----Original Message-----
> From: web4lib-bounces at webjunction.org 
> [mailto:web4lib-bounces at webjunction.org] On Behalf Of Drew, Bill
> Sent: Tuesday, July 19, 2005 8:48 AM
> To: David Walker; Richard Wiggins; web4lib at webjunction.org
> Subject: RE: [Web4lib] RE: library automation vendors
> 
>  
> > We in libraries have four distinct advantages over vendors:
> > 
> > (1) Libraries can hire interaction designers and information 
> > architects to do this task.  That's feasible even for mid-sized 
> > academic libraries.
> 
> I disagree.  This costs big bucks!  Besides, most libraries 
> are not mid-sized academic libraries. Most are small.
> > 
> > (2) At the local library, we actually interact with end-users on a 
> > daily basis.  We understand them, even if we don't always 
> appreciate 
> > their point of view.  We can do regular usability tests 
> with our users 
> > and make updates to our API-based systems whenever we see 
> fit, instead 
> > of having to "lobby" vendors for years to "fix" problems.
> 
> Who does this?  What systems do we have that use APIs?  Where 
> would the one person library IT (systems librarian) staff get 
> such skills or even the time?  
> 
> > 
> > (3) It's ultimately more economical and sustainable to design an 
> > interface against an XML-based API than to have to mess with 
> > vendor-supplied interfaces, in which even minor customizations are 
> > vulnerable to upgrade incompatibilities.  We're separating the 
> > presentation layer from the application layer.
> > 
> Again, where do you expect me to learn these skills?  I am 
> learning XML but am not a programmer.
> This is a job for vendors based on our wants and wishes!!!
> 
> > (4) We can share our ideas and code with each other in open source 
> > communities, allowing even technology-poor libraries to 
> benefit from 
> > those who have the ability to build these systems.
> 
> Maybe.  Most of us have no choice as to what LMS or ILS we use though.
> _______________________________________________
> Web4lib mailing list
> Web4lib at webjunction.org
> http://lists.webjunction.org/web4lib/
> 

_______________________________________________
Web4lib mailing list
Web4lib at webjunction.org
http://lists.webjunction.org/web4lib/