Migrating to LibGuides 2 Without Murdering Your Co-workers (iCon 2015)

Editor's Notes

• #3: Linscheid Library is an intensely collaborative environment where all of our decisions, including migration decisions, are made collaboratively. Most of the times these decisions look like this—colleagues debating civilly. However, our last migration, from HTML to LibGuides1 back in 2011, looked a little more like this. With two librarians who had gone through this migration still working at the library, we paced and planned our transition a bit differently
• #4: As the Instructional Services Librarian, I was the ringleader for this migration circus, meaning that I did a lot of the planning and coordination. As the ringleader, I made the conscious decision to wait to start the circus until the time was right. When you’re embarking on a software migration or upgrade like this, it’s crucial to take your institutional context into consideration. At ECU, we didn’t have a lot of coding experience in the library at that time, IT is unable to help with projects like this, and we all do a lot so we tend to only be able to work on projects a little bit at a time. So we were better off waiting until other libraries, including some of you, had migrated and helped Springshare work out some kinks and improve some of their documentation.
• #5: We decided to begin the migration process in late January 2015, with the goal of going live at the beginning of the summer semester in June. That way, if we ended up a bit behind schedule, we could set a later “live” date, but still be up and ready by the start of the fall semester.
• #6: With this general timeframe laid out, my first step was to prepare a fairly detailed migration schedule, which you can see here. Yes, it is two pages long…It had been over three years since we implemented LibGuides1 so we knew that it was time to reconsider some of our previous decisions and that we’d need to do some clean-up. You’ll also notice that we were migrating to LibCal2 at the same time so some of this time was spent on that, too. I put this together by reviewing all of the documentation that Springshare has on migrating to LibGuides 2. Although they don’t have as much documentation on 2 as they had when we went to 1, they have enough to give you a good idea of what needs to be done. And if you know your colleagues and staff well, you’ll be able to figure out more or less how long everything will take. We have a standing weekly Librarians’ Meeting and a bi-weekly Instructional Services Committee Meeting and LibGuides was a major point on the agendas for both meetings for the whole spring semester. We also ended up scheduling a few extra meetings to wrap up all the loose ends toward the end of the semester so that we could finish by our goal date.
• #7: Throughout migration, we relied on a few guiding principles which we’ll call the six C’s: collaboration, consistency, customization, convenience, compliance, and clean-up.
• #8: I’m sure that many of you have heard the saying that a camel is a horse made by committee. Well, at Linscheid Library we like camels and we like committees and collaboration, for everything that we do. We find that our work is invariably of a higher standard and we can provide better service to our community when we work together. I think it’s especially important to have many voices weighing in on such a big project like this. However, you can’t expect someone to contribute meaningful opinions if they don’t speak the language of the conversation. Similarly, I knew that I couldn’t ask my colleagues if they wanted to go with a tab or side-nav layout if they hadn’t at least seen the different options. So the first step of the migration process and the most important part of ensuring successful collaboration was for everyone to review the relevant guides and training videos. Everyone also explored the sites listed in the LibGuides2 community to get a sense of how other libraries were implementing LibGuides2. Furthermore, I felt that it was important for everyone to have the opportunity to experiment within the system from the beginning so everyone was encouraged to make a guide or two or three and start playing.
• #9: This background research and experimentation really came into play with our second “C” of Customization -- One of the best things about the LibGuides system is that it allows anyone to customize the basics like the color scheme and the overall guide design. When we approached our guide design for LibGuides 1, I just mocked up a few guides and had everyone vote on their favorite. However, for LibGuides 2, I asked everyone to play around with the color schemes and box and tab design in their own guides and present their favorites to the group. We ended up with a much broader range of options than I would have come up with on my own. We decided on this simple and clean color scheme of light grey and dark grey with rounded tabs and square boxes which we’re all really happy with. We also customized the system with our own header, added in a favicon, and made a lot of other changes to the custom CSS and the templates to make the site look exactly how we wanted it to.
• #10: And at this point I have to give a shout-out to the Springshare support folks who helped us figure out how to make all of these changes to the CSS. These are just a few of the many changes that we made in the CSS area. Our main impetus for these changes was just looking at other sites to see what they were doing and spending time in the system to figure out what would work best for our patrons. Another big component of customization was getting our databases set up in a way that would be most beneficial for our patrons.
• #11: I am the DB person – I purchase, license, and maintain all DB links in the catalog and in LGs.
• #12: LibGuide2 assets and LibGuide2 database assets are two different camels, or maybe the same camel but with two humps. They are stored in two separate areas in the Content area of LibApps. They cannot be copied, only mapped – unlike other LG assets You get it all when mapping – title, description, resource icons, etc. However, you can ‘create’ your own ‘copy’ using the friendly URL that I’ll talk about later Therefore, it’s advisable to have your electronic resources person be your database assets owner as they will already be familiar with the resources.
• #13: In all three cases – you need a spreadsheet Title of Database Link to the database (with your proxy) Description of database You’ll need a few other things as well that we’ll discuss along the way
• #14: Before beginning any work in LibApps, as Chelsea has already alluded to, you need to work thru a checklist with your team to make collaborative decisions on: What to call the page What to put on the page How to incorporate: Subjects Types And Vendors There are a lot of decisions to be made, and I’ve provided a copy of the pre-checklist we used at ECU to guide us.
• #15: In LG1, we had a huge debate over electronic resources v databases. Do you see job ads for database librarians? No, their called electronic resource librarians. So, we went with electronic resources. However, this time around, no debate ensued. Springshare called them databases, and we were fine with that. We use that word a lot with our students, so it made much more sense to make the change. Changes to titles and labels are make in the language customization – be sure to choose A-Z Database List. #52 & 53 are where you change the title and description of the A-Z page.
• #16: Out of the can, Springshare includes: Database assets (covers left and middle column widths) The Right columns consists of New databases (optional) Trial databases (optional) If you don’t select any new or trial databases, you get the box you see in this first image – it’s kind of empty We chose to hide that coding in the A-Z template (thanks Chelsea!) However, that made the column completely blank and useless So, we created our own Database Help box that resides in Reusable content, that links patrons to those items we felt they used most from LG1 This box was then added to the A-Z Template What’s nice about LG2 is that you can create a guide – Database Help – but you can ‘hide’ boxes on that page as well. I was able to create the box you see here on the database help page, however, it is NOT seen when you go to the database help page.
• #17: Subjects – database assets can have multiple subjects Subjects are not database specific but for all guides – Admin -> Subject, Tags & URLs Assigning subjects to guides and database assets creates subject homepages showing Subject guides Course guides Database assets, and the Liaison Specialist It also allows you to create a “best bet” database(s) per each subject You can have multiple best bets per subject We chose to emulate the wording we used in our EBSCO databases and changed All Subjects to Limit by Subject
• #18: Best bets will always show at the top of the database list, with non-best bets showing below. I suggest you review each page to ensure the look that you want to achieve for your patrons. Ask them to review Have student assistants review
• #19: Like subjects, database assets can have multiple Types Unlike subjects, Types are just for databases Can Boolean, e.g., Subject by Type Articles, Ebooks, Newspapers, Other (can’t change order so OTHER appears alphabetically) Beware of making your list too long and making patrons have to scroll. The goal is to make their life easier – these limiters are for them not us (the librarians) We chose to emulate the wording we used in our EBSCO databases and changed All Database Types to Limit by Type
• #20: Unlike subjects and types, you can only have one Vendor/Provider Unlike subjects, but like types, Vendors/Providers are just for databases Can Boolean, e.g., Subject by Type by Vendor We chose to name it Platform as we have way too many vendors to put in this list (and the students don’t care about the vendor – we talk platform in instruction) - our rule of thumb – if we have more than 2 databases from one vendor, they appear in the list We chose to emulate the wording we used in our EBSCO databases and changed All Vendors/Providers to Limit by Platform
• #21: We chose to NOT use More Information as it appears as a link. When you click the link, the screen expands, and then the user has to click yet another link or read the information placed in the More Information box. In LG1, we used the blue I icon as a link to a vendors get help page. We opted to continue this in LG2. NOT using the More Information box meant a friendly user experience, in our opinion. However, you may have more than one ‘help’ page to direct patrons to or other necessary links. These can be hard coded into the description as you can see in the third screen shot here.
• #22: These can be used to access vendor help guides or internal help/FAQ guides. You can link to anything you want, or you can opt to not link and keep them purely decorative. Descriptions and URLs are optional Be careful as they can clutter your site They must be 16 pixels We opted to only have two: The blue I icon used in LG1 for the same reason – vendor Get Help guides You notice that the URL is blank in the admin screen shot However, the specific URL is added in the database asset itself ODL icon indicating the source of funding – whether paid in whole or partially.
• #23: Friendly URLs – see share (chain link) icon Recommend since we are doing with all pages of all guides Nicer looking URL – don’t have to worry about proxys as they are already imbedded in the original link Easy way to remember – ecok.libguides.edu/friendly_url We chose to use the full name with underscore between words Patrons can opt to email the link Easy way to create YOUR version of a database asset that can be customized and not reused from A-Z page. However, the asset won’t update if the A-Z asset is updated
• #24: Thumbnail Images [alt text is always ‘thumbnail’ – can’t edit (yet)] Can only have one per DB asset They do not show up on the Database page, but when you map from your guides Sizes are problematic and they won’t all look the same. One may not be available – do you create a generic one as a placeholder? It gets lost in the list We opted to NOT use them 
• #25: You may have to do the review more than once Set deadlines! Now you’re ready to import
• #26: Springshare has wonderful LibGuides that walk you thru the whole process. If your LG Administrator is not your database person, then the LGA needs to work with the DB person to coordinate this step. For us, we already had an A-Z list from our first setup with LG1, so this process went fairly easy. If you don’t already have an A-Z page, then If you have a lot of DBs, it might be easier for you to download Springshare’s DB spreadsheet, populate it, and have them create the page for you. If you only have a handful, it might be easier to enter them one-by-one Even after our import, I had to go thru each DB asset to add items that we’ll discuss soon
• #27: You can import a spreadsheet that Springshare can help you create, and you can also import one from Serial Solutions. Just follow the very useful LibGuide Migration Guides/Videos to help you thru this part.
• #28: Finally, you can add them one by one.
• #29: Even though we migrated our LG1 databases, I still had to go into each one of them to assign (from the spreadsheet): Types (you can have more than one) Updated descriptions Remove the More Info and place the vendor’s help guide URL into the Resource Icon FURLs Resource Icons – both help guide from previous More Information and ODL, if applicable
• #30: The final step is to assign, using the spreadsheet, best bet(s) and other associated subjects. Finally, I used student assistants to check and double check each entry, link, and subject association. Chelsea will now talk to you more about the importance of consistency.
• #31: In her discussion of setting-up and customizing the databases, you’ve already heard Dana mention consistency quite a bit. We feel that consistency is important for at least two reasons – It helps your patrons navigate your site more easily and it helps your creators put together their guides more quickly.
• #32: In addition to standardizing the color scheme, navigation, and tab and box design across guides, the main method that we used to ensure consistency was creating blueprint guides for our course and subject guides. Springshare defines blueprint guides as guides that serve as a pattern or plan to create other guides. You can create these guides with the LibGuides2 Template type and then reuse them as the basis for other guides. We’ve set these guides up so that they have a fairly prescribed number of tabs which all use the same language and contain roughly the same boxes on each tab. For instance, the Books & More tab of our subject guide blueprint always lists the relevant call numbers for that subject and on the Course guide blueprint, the Evaluate tab always features the CRAAP Test. This way, once students become familiar with one guide type, they can easily navigate all guides of that same type. We had already developed the basis for these blueprint guides in LG1, but we did take the migration as an opportunity to improve upon them. For instance, we took advantage of the draft mode feature to add boxes on each page of the blueprint guides to remind the guide creators exactly what should remain on the page and which components are completely optional. I will admit that the blueprint guides do present some disadvantages, however. First of all, when students encounter a course guide that looks the similar to the course guide they had for a different class last semester, they may think that they are getting the same lesson and automatically tune out. Additionally, creating new blueprint guides in LG2 presents a challenge at migration time. It might not be a simple task to update your existing guides to comply with the blueprint guides after migration. You may just need to delete your subject and course guides and start from scratch. That’s what we did. We decided to go ahead and recreate our subject guides before going live. Now we will just recreate our course guides as needed throughout the academic year. However, overall the blueprint guides do save time for the librarians. We don’t have to reinvent the wheel every time we make a new guide, and, in fact, that is discouraged.
• #33: To further promote consistency and save the librarians time, we developed a reusable content repository when we were still in LibGuides 1. This contains boxes and other items that you might want to reuse throughout the site. This does help to maintain consistency, but this isn’t really a new thing with LibGuides 2. However, your migration to LibGuides 2 is a great opportunity to see if anything in your repository should be updated or deleted. Once again, we were able to distribute the workload for this task, because we had documented who owned each item within the repository so everyone just needed to look at their own content.
• #34: Another piece of documentation that is really key to consistency is your local Standards document. If you don’t have design and content standards, get started on them now. We have developed a very robust standards document which details many of our decisions throughout the migration process. This documents exactly what is expected of the librarians when they are setting up their LibGuides profile and developing guides. These go into great detail about guide settings such as when to use what guide type, whether or not to use tags and prev/next links, and guide layout issues such as how many tabs to use. The standards also talk quite a bit about accessibility and usability which brings us to the C’s of Compliance & Convenience.
• #36: Resources:
• #47: Springshare has created some wonderful reports for you to run as you’re approaching migration. These will tell you about guides with low usage and stale content, inactive users, content that won’t migrate, and broken links. However, your clean-up shouldn’t stop with these automated reports. There’s also a lot of manual work that needs to be done. For instance, each of your users should look through their image libraries for images that they know are outdated and not being used. Unfortunately, there isn’t an automated report for this that I know about. In terms of keeping your system as streamlined and up-to-date as possible, this is something that you want to always have in the back of your mind, rather than just thinking about it during migration. For instance, we have written into our standards a summer maintenance process whereby all the guides get reviewed for adherence to the standards and currency. For LibGuides 2, we’ve revised the annual maintenance to include reviewing assets and deleting anything with zero mappings.
• #48: Really all six of the C’s are important throughout the LibGuides lifecycle, not just during migration. You should always be collaborating with your colleagues to make sure you’re addressing their needs and getting a broad range of perspectives. There are always new customization ideas being posted to the springshare Lounge, so be sure to subscribe to those updates. It’s very easy to become inconsistent as time goes on, so you have to make sure to have some sort of maintenance component to keep everyone on track. Accessible and responsive web design is an absolute necessity and again there are always new tips being posted in the Lounge about this.