[Web4lib] RE: library automation vendors

[Suzanne M. Gray]

So I wonder what is it that libraries are going to stop doing to invest in 
usability testing and interface development?  Cataloging?  Reference? 
Material Selection?

It seems that a lot of this work is being done on an ad hoc basis by 
committees.  I would be interested in learning how many libraries have 
dedicated staff that focus on usability testing.  We do ours by 
committee here, and most of the folks on these committees are non-tech 
staff. Having committees do this work seems to limit the frequency and 
number of tests that can be completed, and extends out the time that it 
takes to pull the results together.  It seems to work fine for one-shot 
tests, but I think a usability testing program integrated into the 
development process may not be well served by this model.

I also wonder how sustainable it is to build all our own interfaces 
through API's.  I know that we are fortunate to have two full-time web 
programmers here, but I am not sure to what extent we would be able to 
build and support these interfaces, along with a content management system 
for the rest of what we need to present to patrons.

It seems that staffing models in many libraries have not yet shifted 
enough resources toward the systems/web programming areas to accomplish 
all the work that needs to be done to integrate and improve these systems 
for our patrons.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Suzanne Gray
Web Services Manager
University Library
University of Michigan
sgray at umich.edu
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

On Tue, 19 Jul 2005, David Walker wrote:

>
>>> Who does this?
>
> Who does usability testing?  A lot of libraries. Take a few moments to
> peruse the library literature from the last five years, and you'll see
> this is widely done.  I don't see how you can effectively address
> end-user needs without doing it.
>
>
>>> What systems do we have that use APIs?
>
> SUNY is an Ex Libris customer.  Your Aleph, SFX, and Metalib systems
> have XML-based APIs.  Some of your other systems may also, depending on
> what you have.
>
> You can also make APIs where they don't exist by programming against the
> databases of a system directly.  We've done that here for some of our
> smaller systems.
>
>
>>> Where would the one person library IT
>>> (systems librarian) staff get such skills
>>> or even the time?
>
> By hiring someone with the skills.
>
> Or, in the case of an academic library, you can hire someone with some
> of the skills and pick up slave -- uh, er, student -- labor to fill in
> the rest.  Morrisville even has a bachelor's degree program in Web
> Development.  Or, in the case of a large academic system like SUNY, you
> could pull your resources to hire people.
>
> Libraries spend a lot of money on technology.  But if we don't devote
> resources to hiring good, talented people to actually implement,
> integrate, and improve on that technology, then we aren't really getting
> the most out of our investment.
>
> Having just one or two people who "install and maintain" the systems
> while the rest of the personnel are in public services worked when the
> ILS was it and the dumb terminal ruled the day.
>
> But libraries in the 21st Century are technology-rich institutions, with
> a half-dozen or more local systems, 100s of remote databases, and
> end-users who expect far, far more than what the vast majority of
> academic library web sites are offering them.
>
> We need to reallocate our resources into making better use of our
> technology.  It won't always be easy to do that.  But can we afford not
> to?
>
> --Dave
>
> =================
> David Walker
> Web Development Librarian
> Library
> Cal State San Marcos
> 760-750-4379
> =================
>
>
>
>
> -----Original Message-----
> From: Drew, Bill [mailto:drewwe at MORRISVILLE.EDU]
> Sent: Tuesday, July 19, 2005 5: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/
>
>
>