LibGuides has been a long-time coming at my library. But after languishing on the wish list for several months, it’s back on track, and I’m happy to report, ready for launch. Here’s how we pulled it off.
The idea to adopt LibGuides goes back over a year at my university. The reasons were obvious, we needed an easy, non-technical content management system for non-technical staff to be able to produce research guides, course guides and other online instructional materials that worked seamlessly with our other library systems (our catalog, our databases, etc.). LibGuides fit the bill.
Unfortunately, the LibGuides project came at a time of major organizational changes at my library, part of which led to my position as Web Services Coordinator. So, not long after starting, I was told to prepare the way for an eventual rollout.
To begin, two teams were assembled, with me serving as the information architect working with both groups. One team focused on subject-oriented research guides. The other team focused on course guides. As it quickly became clear, these teams really needed to coordinate closely since decisions on the interface and best practices would apply largely across both research guides and course guides. Eventually, a third group was also created for our Special Collections team to get in the game.
Much of my own role was in generating a list of best practices and standards, which I gleaned from other LibGuides sites, and especially from observations made from poor implementations of LibGuides. In fact, it seemed to me that the majority of LibGuides out in the wild were usability nightmares. My guess was that this arose from having librarians without a background in usability and web design building web content without guidance or oversight. Avoiding these kinds of fiascos then would be my first priority.
After creating a draft standards and best practices policy I delivered it to the two teams who then gave me feedback, which led to our final document. This also included a governance structure to ensure compliance. Meanwhile, sub groups within the teams worked out interface/design standards, editorial standards and began building widgets that would be most commonly used.
Also concurrently, our online resources experts began importing our resource database into LibGuides. At first we hoped to maintain our current in-house resource database and have it communicate with LibGuides automatically, but this proved a technical challenge that we finally decided was not worth the effort. Instead, we just imported everything into LibGuides and planned to use it exclusively for managing our resources.
Once this preparatory work was completed, we went about creating a research guide template that other librarians could use when building new guides. This involved surveying how other schools did this and considering what organizational structure would work best.
Finally, this month, our work came to an end and it was time to begin training our librarians on using LibGuides. Such is where we stand now. Today we had our first training session and people seemed quite eager to begin building their guides. The schedule from here is to have each library liaison build at least one subject guide for their area by April 15th. All new guides will need to go through my Web Services team to make sure that they conform to the best practices and standards we established. By the end of April, all guides submitted to me will then be reviewed and published in time for a soft launch during the Summer Quarter.
Our goal is to have a hard launch in the Fall, with our old subject guides running parallel to allow faculty and students time to adjust. By next winter, we will turn off the old guides and move exclusively to LibGuides.
Quite wonkish, I know, but I’m excited to see our progress.