It’s particularly frustrating to be at a small library without a big budget or programmers. I can think of so many things that would benefit our patrons (federated search, a better catalog interface, etc.), but without $$$ and tech experts, we’re limited to providing the best instruction we can. I push for all of these technologies at work (and have been begging my Director to hire a coder since I started), but there are always competing priorities at budget time. At least I was able to push through the purchase of a link resolver this year; it’s lead to its own set of frustrations for students, but it’s a lot better than before.

I t’s awful to send a college student to his/her local public library for ILL just because something costs a lot!! The public library has far fewer resources than a university library does. Thank you for helping with this.

Marianne

The result is that when a user look at our link resolver (once we deploy Umlaut next week) for a book or article, it will let them know if the book is available in OCA, or article in OAIster. Of course, how often do our users check a link resolver for a _book_? Not neccesarily very often (except that for us, coincidental to this project, users are already going through our link resolver to make an ILL request. Hmm.)

It’s not perfect due to metadata issues (ie, lack of controlled metadata access to either of those sources). I haven’t integrated Google Books in (yet?), because Google doesn’t offer much of an API, and the word is that they don’t take kindly to too much traffic to check this stuff. (Can’t find the link now and can’t remember whose blog it was on now).

Anyway, I think it’s our responsibility to try and get our technology in a shape where it shows the users things like this with easy to understand user ‘task flows’. I believe our users _will_ use our technology services if we provide actually useful and easy to use services, and that our technology-mediated services can be both (but are currently often neither).