LibGuides 2 is coming, and everyone’s eager to make the make it happen. The creation of beta sites — a key step in the process — will be getting started soon. (Admin accounts: if you haven’t requested one yet look for the “Request LibGuides 2 beta site” button when you sign in to your current LibGuides site. Check out our blog post for more info.)
There’s another key step — an opportunity, really — that’s easy to overlook: getting a handle on your existing LibGuides content before making the transition to LibGuides 2.
It’s a simple idea, one that will save work during the transition and after. But how should you go about it?
User Experience Team, University Libraries, University of North Carolina at Chapel Hill
Librarians on the User Experience team at the University of North Carolina at Chapel Hill have a plan. It was developed not with LibGuides 2 in mind, but as part of an earlier transition to LibGuides from an older content system. (The UX team includes Kim Vasilliadis, Emily King and Chad Haefele.)
We thought a look at their process would be useful to other libraries as they prepare for LibGuides 2. Emily King, on behalf of the team, agreed to share with us — and with you — how they have gone about it. Here’s part of our conversation.
Q. Tell us a little about the background of library guides at UNC. What did you have before LibGuides and why did you decide to switch?
UNC Libraries have a long history with subject guides. Librarians started creating online pathfinders in the late 1990s. These early guides were basically online bibliographies and were mainly designed by librarians who felt comfortable writing in HTML and managing files on a server. As our web presence grew, so did our guides. In the early/mid 2000s, we created an in-house database to manage our guides. Librarians would enter in the guide’s medadata (title, owner, creation date, subject area, etc). This database allowed us to automate where guides were linked on our website and it also sent a yearly email to the guide owners reminding them to review their subject guides.
Around 2005, we noticed that many librarians were using these subject guides as instructional tools. The automated system did not provide an easy way to sync up the guides with the associated course. We then rebranded these instructional tools Course Pages and built another database to hold the metadata about course pages. We created a HMTL templates for this new type of guide. We were able to tie this database into the campus learning management system (Blackboard and later Sakai), which helped to put the course pages at the most likely point of need.
We knew that before we moved to a new content management system that we needed to have a sound content management strategy in place.
Until we moved to LibGuides, both Subject Guides and our Course Pages were created in HTML. We created css/html based templates to brand each type of guide. We also had style guidelines and naming conventions to help the guides to look uniform. When subject guides were each initially published we did a technical review and a content review. Librarians were responsible for monitoring and periodically updating the guide when prompted by a reminder email. It was also up to the librarian to remove the guide from the system when they thought it was no longer relevant.
Q. What prompted you to put a new management plan in place for LibGuides? What were some of the issues you were trying to address or anticipate?
We knew that before we moved to a new content management system that we needed to have a sound content management strategy in place. By the time we began to consider Libguides, we had been managing subject guides and course pages for over a decade and we were intimately aware of the issues. We had guides that no one knew existed or were thought to have been deleted years before. We also had guides that had been created as a student project but no longer had a guide owner when the student graduated. We also didn’t have a defined strategy for how to deal with guides when the guide creator retired or left. In some cases the guide just languished on our servers for years. We also had a very busy staff who often felt crunched for time and just didn’t have the resources to go back and evaluate their guides.
Q. How did you go about evaluating what guides you should and shouldn’t have?
When we started this process, we wanted to make sure that our guides were well designed so that patrons would find them useful. We used three sources to help with shaping the goals: general web design studies, usability studies that other academic libraries have done on their LibGuides, and the results of usability studies we had done on our own instructional web pages (subject guides, course pages, and other online learning objects).
Some of the findings were not that surprising; we did not want to have broken links, we wanted to use formatting to convey meaning when possible, we wanted to give good white space, and we wanted to have scannable content. Other findings were more interesting, how students viewed the pages. What content students were drawn to and what features were ignored. One of the most striking findings was that we needed to have a clear purpose for the pages and meet student expectations about what they would be getting. This purpose needed to make sense to patrons that came to our website. For example, for our course pages, students expected everything on the pages would be related specifically to their course work.
Going through this process does take time and a lot of discussion if you have a large number of guides, but once the time is invested patrons and librarians benefit from the results.
Q. Are guide authors given the opportunity to make the case for guides that might fall outside the parameters you’ve established?
Yes, in a way. We are a LibGuides CMS campus, so we have parameters for each group that we have in LibGuides. There is definition for each group that the guides in that group need to adhere to (http://guides.lib.unc.edu/usinglibguides).
If someone wants to create a guide outside of the set parameters we meet to discuss the need they will be addressing and either create a new group to meet that need or determine an alternative solution. Our goal is not to restrict content creation, but to make sure that we are planning for the content we add.
Q. Who manages the process? How do you define the roles of the team managing the guides vs. those of the individual guide authors?
Currently the User Experience team for UNC Libraries manages this process, but librarians and department heads have ultimate say over the content as long as it adheres to our guidelines. They are the subject experts. That being said, the UX department worked closely with subject librarians to develop the guidelines we have. Our approach is very much a partnership to help librarians identify the goals of their subject guides and course pages and help them meet those goals.
I think that librarians feel better about the time that they choose to invest in their subject guides because they see how the guides fit into the strategic web presence of UNC Libraries.
Q. How have the guide authors/librarians responded to having rules and processes and procedures in place for their guides?
We have gotten this question a lot, and the answer seems to surprise people, but I don’t think it should. We have had really positive feedback from our librarians. I think it is because we are working together to meet the same goal: help our patrons connect to the resources they need. That is how the guidelines are presented and practiced. I don’t think any librarian wants a patron to come to a library web site and receive bad or out of date information. I think that librarians feel better about the time that they choose to invest in their subject guides because they see how the guides fit into the strategic web presence of UNC Libraries.
Q. You have a timeline for guide maintenance. Can you describe the different tasks it calls for at different times of year and how they are carried out?
We do. It is published as a LibGuide that all librarians can access (http://guides.lib.unc.edu/usinglibguides). Our major review happens over the summer because that is when the librarians at UNC have the most time to review their subject guides.
In April/May, we go through the guides and try to “measure” them to give librarians a sense of how long they will need to spend updating the guide and identifying specific problems that need to be fixed (broken links, display problems, etc.). Then when the spring semester finishes, we run the Google Analytics statistics for each page of the guide. We only pull two metrics, unique users and average time on page to give a snapshot of use. If librarians want to go more in depth with the metrics for a particular guide, they are able to look at the raw data in Google Analytics. We think it is important to include a maintenance time estimate with the usage statistics so subject librarians can see all their guides together and compare. Each librarian considers how much time they have to devote to guides and then sees which guides have the highest impact and spend their time on those.
We have found the most important pieces of this process is to define what user needs your guides are meeting and let those needs define the creation of guidelines and the review process and to plan for the whole lifecycle of the guide.
Q. Can you describe how you estimated the time it would take to update a guide based on the data you had on it?
To get our minimum time estimate to update the guide, we add together the following:
- 20 minutes times the number of pages – We estimated this as the time it would take to look over the page as a page and ask questions like: Do I still want these boxes? Is this still the best way to organize the page? Are there any new resources that should be added? This estimate also includes time to fix any stylistic problems that were identified in the yearly review.
- 3 minutes times the number of resources – Because a web page can be any size, we decided to count the number of books, databases, services, and other library resources that were listed on the page. It is going to take librarians the same amount of time to review 500 links no matter how many pages they are on.
- 7 minutes times the number of unlinked resources – One of our web goals is to minimize repeated content on the web. To meet this end, we require all subject guides to link to the original digital material (if it is a digital item) or the official digital surrogate (for example, the catalog record for print items). Because librarians have to track down the correct link for this, we know that it will take a little longer than a simple review of a resource.
- 15 minutes times the number of broken links – I think it goes without saying that we don’t want broken links on our pages. If there is a broken link, librarians need to either track down the right link, delete it the resource, or replace it. This investigation takes a bit of time, which is why we have 15 minutes for this.
Kim and I came up with the numbers based on our experience working with subject guides and course pages. We know that actual time may vary greatly, but this does help compare apples to apples when subject librarians are trying to figure out how to prioritize their guides.
Q. What did you use to gather usage reports with the old guides? Are you doing it differently now that you have LibGuides? How have the built-in statistics in LibGuides been useful?
We have used Google Analytics in the past for these reports. Because it took us a while to migrate all our existing content into LibGuides (we completed in February of last year), we wanted to make sure that the numbers were consistently generated for the guides in LibGuides and guides in HTML. Now that we have all our guides in LibGuides, we will explore if we can generate the stats we need with the LibGuides statistics. The most important stats for us are unique users and average time on page. It allows our subject librarians to see how much use the subject guides are getting and how much time people are spending on specific pieces of the guide.
Q. Your plan was developed to coincide with the change from your old guides to LibGuides? What advice would you have for libraries that already have LibGuides in place?
We have found the most important pieces of this process is to define what user needs your guides are meeting and let those needs define the creation of guidelines and the review process and to plan for the whole lifecycle of the guide. Ask questions like: “How will we know when we don’t need this anymore?” “How will we know when this is out of date?”, etc.
For our subject guides we have a thorough yearly review process because these are semi-permanent additions to our web site that anyone coming to our website could use. For our course pages that have a very specific user group for a specific length of time, we don’t do an annual review. It’s much simpler to just unpublish the guides when the user group doesn’t need them anymore.
This is definitely something that is easier to do when people have to rethink their guides anyway, but I think it can be done at any time. Going through this process does take time and a lot of discussion if you have a large number of guides, but once the time is invested patrons and librarians benefit from the results. It is almost like a library building renovation.
One happy side effect of this process is methodically reviewing guides exposes content that may have been created as a workaround for a problem elsewhere in the library. This is a way of identifying needs that are not being met in your other library tools. For example, if we have a page that explains a complicated policy or process in the library, every year when you review that guide you have a chance to think again if that process could be improved to eliminate the need for the guide. If you can, then you are improving the patron experience and taking extra work off of a subject librarians’ plate.
For more on the UNC plan for managing LibGuides, see the slides from Kim Vassiliadis’ presentation at Computers in Libraries 2013: “LibGuides: Sustaining & Embedding Strategies”