[Web4lib] RE: library automation vendors
campbell at virginia.edu
Tue Jul 19 09:39:25 EDT 2005
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
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
> -----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
> > 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
More information about the Web4lib