More on feedback

In a recent post I mentioned giving real feedback to vendors and people designing systems and services for us. Sue left a comment that the vendor basically acts like she's alone in this - and they say that to me, too, but we soldier on. (oh, and AIAA says we're the only ones who have any problems with their digital library)

Right now, AIP Publishing has a beta of their new journal pages that you can try out and then either e-mail them or fill out a survey with your feedback. Please do, they're some of the good guys.

Similarly, Jonathan Rochkind is impressed by the feedback he got at a recent session on Umlaut, an open source software that's sort of a middle layer thingy for open URL link resolvers (ok, I can't describe it, but it is amazing).

One of the most exciting parts to me was that various (non-IT)  librarians in the room, un-prompted, starting throwing out ideas of what it could do in the future. Quite good ideas. I had to resist the techies urge to respond to them with "Well, yeah, but see, that's harder than it might seem to make work like that...", and instead try to be encouraging and positive, because it was great to have such a conversation. We hardly ever have such conversations.

I hardly ever give Jonathan feedback he can use - typically he is about 10 steps ahead of me.  Like adding in web services from Scopus and Web of Science that provide an abstract, related articles, and citations to the article you're looking up on the sfx item page.  So if I'm reading an article on a website - even the full text - I can click on the DOI which my LibX toolbar highlights for me, look it up in Findit (sfx + umlaut), and use that to find related articles or citing articles.   Anyway, it's hard to give him feedback sometimes because it's hard to know what's possible.  Heck yes, that's useful... didn't know they had web services.

Likewise, who knew we could add a link to search inside the book on Amazon or Google Books or HathiTrust from within our catalog?  But this isn't about complementing Jonathan.

I actually disagree that just because we outsource some of the heavy lifting for coding, supporting, and maintaining IT that we can't influence it's design or evolution. All library coders or tech support staff are *not* like Jonathan either - in competence, in creativity, or in listening to the librarians and even pushing back when something won't work.  I think we need to be very critical of vendors who are offering us services, and then partner with them to influence and provide feedback on the evolution of the product.  Library advisory boards are a must, but if you buy it, you should surface your concerns in a usable way.

More like this

Is that all our vendors hear when they ask us to try out their new interfaces?  A couple of us were kvetching on friendfeed about this.   Lemme tell you a little story.  A little while ago a really important society publisher in the geosciences re-did all of their web pages and they were pretty -…
I'm still on this kick on recommender systems. I'm further encouraged by happening on a report on "discoverability" by the Minnesota librarians when looking for something else on JR's blog. The report agrees that recommender systems are a more important trend. In standard information retrieval…
On January 10, 2013 Rick Anderson published a post at The Scholarly Kitchen published on six mistakes library staff are making when dealing with our vendors. Most of them were fairly standard stuff like don't be rude, don't waste people's time. That sort of thing. (Yes, sometimes I think that every…
Book of Trogool has just been added to Planet Code4Lib, a library-technology blog reader. I am of course honored to be in some very fine company. I have a mixed readership here: librarians, technology pros, researchers from several disciplines. I encourage all my readers to pop over to take a look…