The Source Documents Behind the News (A librarian reads the news...)

Publications and Presentations

In my classroom...

Custom LibGuides Page Layouts, Terminology, and CSS

As you probably figured out from my last post, it’s been a Libguides kind of summer around here. We updated all our links to our catalog, got things ready to publish the Libguides databases list rather than our old other-CMS databases list, changed all internal links to database lists, migrated from WorldCat on FirstSearch to WorldCat Discovery links, and did the annual (painful) clean-up of the assets inventory (merging duplicate assets, deleting un-mapped assets, fixing wonky assets…).

For me the most fun part, though, was updating the custom page layouts, custom terminology, and custom CSS. And I thought I’d share my work in case it’s useful to others.

Custom Page Layouts

Under Admin > Look & Feel > Page Layout, I’ve customized several of our page types. If you want the code for these just let me know and I’ll share.

Guide pages now don’t display that tab name after the Guide name, plus various small tweaks.

We don’t use the system-generated homepage and instead made a guide to use as a custom home page, entering its URL into the redirect URL spot under “Homepage boxes/Redirect.”

For Subject Pages, I flipped the order of the tabs so that people are presented first with useful databases for the topic and then with useful guides for the topic. And I completely hid the tab for blogs because we don’t have any of those and don’t plan to.

For Database A-Z pages, I changed things up so that our QuestionPoint chat widget could sit in the upper right-hand corner, and to hide elements we didn’t want.

Custom Terminology

I’d thought this was only to set the system language, like “English,” but no, there’s a whole section where you can change system-generated labels for things. Go to Admin > Look & Feel > Language Options, and then click on the Language Customization section. Behold, a whole trove of system language that you can tweak to match your local terminology.

Custom CSS

Here’s my custom CSS as of July 2017. You can feel free to take or modify whatever you like from my style. (If you’ve never done this before, just copy and paste everything in my text document into the code box in Libguides under Admin > Look & Feel > Custom JS/CSS and then delete bits or tinker with bits as you like. I use w3schools with wild abandon as I cobble together my amateur CSS.)

My guiding principles

  • Make it so that the librarians can let the CSS do most of the formatting work for them.
  • Clean, uniform looking lists of databases, assets, system-generated lists (widgets), etc, so that no matter how a librarian decides to add pointers in their guides, things will look relatively uniform.
  • Allow for the flexibility that our librarians really value. We value uniformity when that helps the users and when it helps us re-use each other’s assets, but we value the ability to make guides work for a variety of contexts and not tie one librarian to another librarian’s style (though I’m the CSS overlord, so my style is a little more equal than other people’s styles, I guess).
  • This is also why we have a Style Sheet for librarians who create guides, with the idea that the more specialized your work, the more you can do whatever you want, but if you’re doing stuff that others might want to pull into their own guides, some uniformity is useful. (It’s also a handy place to dump little “how to do this complicated thing” tutorials.)

What my custom style sheet does:

Since the Libguides CSS editor doesn’t seem to allow me to comment out my code, here’s some narration about what my code does.

  • First (from the line starting at “body” to the line starting at “li”), I lay down some ground rules for fonts and colors, especially changing links to be bolded rather than underlined, which worked better in our style.
  • The next several lines make the various kinds of things you can put into a box in libguides conform to the same style rules (so that book elements look similar to database elements or link elements, etc), and also hides some elements that we considered less necessary and more apt to contribute to clutter.
    • Removes bullet points and fiddles with spacing around asset lists and system-generated lists so that they’re all uniform.
    • Unbolds the names of guide owners under guides linked using the “guide list” feature in the add/reorder dropdown.
    • Makes book call numbers italicized
    • Hides ISBNs and publication dates in Book assets
    • Hides “last updated date” and number of views from “guide list” links.
  • The next section deals with the layout of some of the most common elements on research guides, removing shadows from boxes and setting fonts and basic styling for tabs and boxes.
  • The next section governs headings and block quotes – very basic stuff
  • Then comes four lines that clean up the Databases A-Z list, hiding the “share” buttons on database lists and hiding both the automatic search box that appears throughout Libguides and the “search within the databases a-z list” search box. This is because we have YEARS of data from our old cms showing that if there’s a search box on a page that lists databases, people enter search terms into it that make it clear that they think they’re searching within the databases. If they want to find a particular database, they use control-F on the web page instead. There was also an interesting talk at this year’s ACRL where people used eye-tracking software and found that people can’t help themselves — they’re drawn to search boxes. And if there are extra search boxes on the page it’ll just confuse the issue.
  • The .dont-break-out line in the CSS is a thing that librarians can employ if they need to display a very long URL and they want to make sure it won’t bleed out of its box, particularly on smaller screens. I didn’t apply it to the system as a whole because I’m not quite sure what all it’ll mess up, but on our Zotero guide I have to make it easy for people to copy and paste our OpenURL resolver link, and the thing is ridiculously long, and this was the only way to force it to wrap in Chrome. So in a Rich Text content item I wrapped the URL in a div tag that called this special class, thusly:
    And now even in Chrome at very narrow browser widths the URL wraps neatly onto new lines.
  • The remainder of the style sheet changes the way that image gallery boxes display, making things simple and clean, and usually even readable if there’s caption text.

So there you have it. That’s what I’ve been up to in the Look & Feel department this summer.

Updating URLs after transitioning to the new Primo interface

If you work at a library that has or soon will be transitioning to the new Primo interface, and if you have research guides or other web pages that link into content from the old interface, read on because you may want to consider doing a URL updating project even though there’s an automatic redirect.

First of all, if you link to searches done in regular Primo (not the journals a-z list), those apparently don’t redirect. If you link to items from regular Primo or to Journals list items or searches, there’s a redirect but it takes a long time to resolve — about 25 seconds in my library’s configurations. Long enough for me to click a link, get a drink of water from the fountain outside my office, come back, and still wait a bit for the screen to load. (Plus it flashes through a couple of weird pages including a “zero results” page that just isn’t true.) And finally, the old Journals list didn’t have an option to search by ISSN, so many results (like if you’re looking for the journal Science) were pretty messy. The new platform does have an ISSN search, which is far more accurate for direct linking.

Given all of this, I’m updating every URL from our libguides to our catalog, both to make it resolve directly to the new interface and to have journals resolve to an ISSN search whenever possible. If you want to do something similar you can follow (or improve upon) my process.

Learn how to distinguish between old an new URLs.

The main distinguishing features of my campus’ configuration is that the old URLs contain /primo_library/ and the new URLs contain /primo-explore/ instead. In addition, there are three sub-types of URLs that might be useful to know:

  1. Primo Query URLs (the ones that probably won’t redirect)
    1. Old: [your institution].com/primo_library/libweb/action/…
    2. New: [your institution].com/primo-explore/search?…
  2. Primo single record permalinks
    1. Old: [your institution].com/primo-explore/fulldisplay?…
    2. New: [your institution].com/primo_library/libweb/action/…
  3. Primo Journals A-Z list
    1. Old: [your institution].com/primo_library/libweb/action/…
    2. New: [your institution].com/primo-explore/jsearch?…

Pull your list of old URLs

So now you can go into the Search/Replace feature of Libguides and do a search for all content items containing the URL snippet either for all of the old versions, or for each of the three sub-types of the old version, depending on your workflow.

NOTE: You cannot use the Replace feature built into Libguides because the old URLs put search terms at the end of the URL, but the new URLs put the search terms both into the middle and at the end.

So, do your search, and then select all the records Libguides pulls back for your search, and paste them into a spreadsheet. I then delete the messier/unnecessary columns so that I end up with a first column to indicate whether I’ve fixed that URL or not followed by three of the columns that Libguides generated: Asset ID, Asset Type, and Asset Title. (I used Google Sheets for this.)

If you’re like us, you’ll have several hundred links to update, all told. And obviously this will be a lot less painful if you do a project BEFORE starting this project to go through and consolidate multiple copies of links. And unfortunately there’s no automated option to do that consolidation project, either.

Updating Libguides assets

Now the fun part ends and the tedious part begins. Here’s a little screen cast of how I change each link. And if you prefer words, here’s the process:

  1. Have two tabs open: your new Journals A-Z search and the spreadsheet from Libguides.
  2. Click on the link to the Asset ID to open the Libguides record for that asset
  3. Open the asset for editing
  4. Collect the URL and open it in a new tab – you now have two tabs that are “temporary,” the Asset and the Redirected-and-Resolved Primo tab
  5. For journal records, open a record for the correct journal and collect its ISSN
  6. Back in the tab for the Journals search on the new platform, search for that ISSN
  7. Collect the URL from the new platform’s ISSN search and paste it into the Libguides asset’s URL field.
  8. Click “Save” and close the two “temporary” tabs.
  9. Mark the column in your spreadsheet so that you know that this asset has been updated.

For URLs that don’t need any special investigating (figuring out exactly which journal was intended or if there are special limiters invoked in the original Primo search that you need to recreate in the new search, etc) it takes nearly a minute per asset, so it’s definitely a good idea to listen to podcasts or audio books or something while you work your way through the spreadsheet.

The Affordable Care Act (aka ObamaCare): The source documents behind the news

The Primary Source Crusader (my own mashup of images)

With accusations flung from both sides of the isle about health care bills and how they they get moved through Congress, I found myself curious about just exactly what went into the creation of the ACA (the Affordable Care Act, aka the Patient Protection and Affordable Care Act, aka ObamaCare).

I’m still working on fleshing this out with links to full text, but I’m ready to share my initial gathering of all the bills, debates, hearings, reports, and presidential documents that ended up creating what we now call ObamaCare.

In this collection, I included the bills themselves and bills that were related (either directly referring to or incorporating substantial wording from each other) and ultimately building on each other until finally the ACA became law, as well as Hearings and Reports that directly related to or mentioned those bills. I also included a few presidential documents that were directly related to health care reform prior to the ACA’s passage, though I have not combed through all speeches and press releases.

I did not include the 60 committee prints that went into the drafting of this law, but if there’s a compelling reason to go back and list those, please let me know. I also stopped including Congressional Research Service Reports that were produced after the bills were finally passed, though CRS of course continues to study issues and impacts of the ACA.

Here is a preview, but if you want to sort and search rather than just scroll, have a look at the full sheet.

Best Practices for Groups using Zotero

I was recently asked to write up some best practices for groups using Zotero, and I thought I’d share them here. While the language and specifics of these practices are all Zotero-centric, I’ve done very similar things with Mendeley and EndNote as well, though they don’t have standalone notes, so you have to make a well-named citation and use its notes fields to fulfill similar functions.

First off, it is worth it to pay for storage from Zotero. There are work-arounds using Box, but that adds a layer of complexity that I have seen go wrong when, for example, you have collaborators spread all over the place and not everyone is tech savvy or has library or IT support.

I’ve also seen people register a Zotero account and then share login credentials to that account with a group. This is not a good idea for a bunch of reasons. Everyone should have their own account and then be added to a group library.

With those two things as ground work, here are some things to consider as you launch a group project using Zotero. The larger your group or longer-term your project, the more these practices will matter.

Setting up the structure

  1. Create a space that serves as your “inbox” for new stuff, before it’s processed/corrected/tagged/whatever. That way you can go merrily along collecting collecting collecting, but not mess up the organizational structure or lose your unprocessed stuff in the giant pool of processed stuff. If it were me, I’d make my own personal zotero library into my inbox area, and only move things to the Group library once it had its PDF associated, metadata cleaned up, etc. Alternatively, you could have a tag that you associate with new stuff so that you can gather it all together and process it.
  2. In the main Group library, have a standalone note that describes the workflow of the group and defines how you are using tags, folders, and “related” items in this group. For example, some people use folders for procedural steps and tags for topic categorization, some people do the opposite, and some people do something else entirely. But this note will make it clear to the whole group how folders, tags, and “related” items function in this space.
  3. In the main Group library, have a standalone note for tag definitions. Name it something that will guarantee it’s at the top of an alphabetical list (like _TagDefs). Apply every tag to this note (so that it comes up whenever any tag is selected). In that note, list each of your tags and a brief definition so that everyone on the project knows what it means and how to apply it. Whenever you create a new tag, be sure to update this tag definitions note and then add that tag to the note as well.
  4. In each sub-folder in the Group Library, have a standalone note that describes what that folder is meant for.
  5. If you’re going to use tags systematically, I suggest UNCHECKING the preference that automatically gathers subject headings from databases, because these are all over the place and will clutter up your tag list. All the other check boxes on that main screen of the preferences help, but this one doesn’t unless you really only use one database/catalog and it has good set of subject terms.
  6. Plan on not having too many tags/folders. “Too many” is subjective, of course, but once you get scores of them they become very difficult to scan through and select. They should hit that sweet spot of functioning to gather together useful chunks of items rather than having only 1 or 2 items per tag/folder or having nearly all your items in a tag/folder. Novices to tagging tend to come up with too many, and constantly add new ones, which really doesn’t help with organizing a group library.
  7. It can be useful to have a way of tracking procedures, either using tags or folders. These would be like “needs ILL” or “follow up” (which I use for things where there’s a gold mine of a bibliography that I know I’m going to want to go back to and start looking up and saving relevant items from the references).

Saving/organizing items

  1. Save into your “inbox” space, however you’ve set that up. (Be aware that whatever folder is selected in Zotero, that’s where all your new saved items will go, so check this before going on a saving spree.)
  2. Check all the metadata Zotero pulled in when you save an item. Frequently there are capitalization/spelling/data errors that need to be corrected manually.
  3. If Zotero wasn’t able to pull in the PDF automatically, download and then drag the PDF in (and having the OpenURL resolver set up in preferences can help you with this — and if that didn’t sound like English to you, check out the instructions under “Making the “Library Lookup” option work like the library’s “Find It” button” in the top left-hand box on this guide for an example, though of course Carleton’s URL won’t work for other colleges).
  4. Once you’ve saved and cleaned up your item information, open the list of sub-items (the little triangle next to the item citation in Zotero) and right-click on the PDF, and then select “Rename File from Parent Metadata.” That way the PDF itself will have citation information in its file name, which saves headaches if you download it later on and end up with a million “out.pdf” or “1957ty3593.pdf” files on your computer.
  5. A single item can be saved to more than one sub-folder, which is far better than having multiple copies/versions of a single item.
  6. An often-overlooked function is the “related” function. This can link together versions of the same work, or an item with items it cites/is cited by, etc. In group work this helps other people see the connections that you’ve found between works. (It can be helpful to have a written definition of how people think of “related” so that, for example, someone doesn’t put all the books on cats together as “related” rather than just tagging them with the subject “cats.”)

So basically, the theme of all of this is to make it so that there’s explicit shared understanding of how to use the various functions, and then give every new item the TLC it needs in order to coexist with all the other items.

Have a favorite tip or practice? Leave it in the comments here!