Making time for R&D

2009 May 11
by Karen

One of the things that I found interesting about the comments to my last post was the fact that people talked about the fact that their institutions didn’t have time to learn about the OCLC Grid Services or time to do Research and Development. It isn’t that this fact surprises me, but rather the fact that libraries haven’t figured about what to let go so that they CAN do R&D. While my unit at UH has responsibility for keeping the library website and other elements of virtual presence running, I also see R&D as a huge part of our job. This is because in order to better serve our users (whether internal or external) we always need to be looking at how to make improvements to existing systems. Case in point, we continue to work on an API for the library website which will allow us to distribute library website content to a wider audience. What do I mean by this? Well, this summer we are embarking on a partnership with a professor in the Computer Science department to build iPhone apps for the library. This wouldn’t be possible if we didn’t have programmatic access to the data in the website. We’ve also spent a great deal of time exploring Drupal and its ability to serve particular functions and take the place of proprietary purchased systems.

If you are thinking that we have tons of staff or are privileged, I’d like to dispel you of that notion. The department consists of myself, another librarian (Web Services Coordinator) and two developers. We do it is by settings priorities so that R&D gets its fair share of the time. This means that we don’t build pages for people, we give them the tools and training to build the pages themselves. Rachel, the Web Services Coordinator, is a huge part of our ability to do this. She spends significant portions of her time, teaching, training, and helping staff throughout the library to use the system we have. She also gathers feedback as part of this process and we use this to influence development decisions. Ultimately, we don’t build systems from scratch we adapt existing OSS or off the shelf software. The major exception to this is the CMS that drives the library website and is the glue that holds all the pieces together.

By running things this way, we make R&D a part of our daily work and priorities. This helps us build better tools for the librarians and staff and provide better experiences for our end users.

4 Responses leave one →
  1. 2009 May 11

    Y’know, the timesink on R&D isn’t even the actual R&D — it’s the convincing everybody else that R&D is on to something valuable that should become a real live library service.

    “I don’t have time for R&D” may be code for “I’m so burned out I don’t have the strength for one more tussle with my colleagues.”

  2. 2009 May 12

    Yeah and I find that beyond annoying. R&D is what it takes to improve services. There is no other way to do it. People ask us for stuff, we have to take the time to figure out how to do it. Let’s face it the “how to do it” part is R&D.

  3. 2009 May 12

    I think that Library techie people should always try to stay ahead of their clients… and yes, I know that this is hard (believe me, I’m the only person who does this for our library & clients. Our library has 4 staff.).I also know that, if you’re smart, you can get a lot of recognition from your clients! The hardest thing is probably having support from within your organisation (& library)… I’ve been lucky that my present boss had the foresight to give me enough scope to do the things I’ve done!

  4. 2009 June 5

    I agree with Karen in that R&D is a crucial part of any techie department. How else could we be aware of what’s coming down the road and develop the skills to implement many of the cool ideas out there? I appreciate that my role as liaison to other parts of the library is valued because they too are doing R&D in their own way, and I think part of my job is to be aware of what is on THEIR horizon. Karen and I aren’t reference librarians, but we are still in tune with their needs. (Well, some areas of the library don’t know what is possible technologically and don’t stay ahead of the curve, so support for them can often be more difficult.) In my position, I feel like I’ve become more of a Jack of all trades rather than an expert in any one thing, but I can communicate the public service staff’s vision with my techie colleagues and incorporate their ideas into our research and development opportunities to support them. Without communication between the techies and the rest of library, R&D would be more difficult and less valued. Communication outside your department helps focus and speed up (even if a little) the R&D process, producing stronger and more appreciated products in the end.

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS