Image

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

Publications and Presentations

In my classroom...

Result lists as a genre of writing

Idea – by me

I’ve been having a bit of an up-and-down teaching term this Fall — some classes going really well and some falling flat — but one thing that I’ve really enjoyed is that so many of the classes I’m working with are in new subject areas for me, or are taking different approaches than I’ve taken before. It’s felt like everything is new, an experiment, and if I look at it in that light I feel just a little better about the term as a whole.

One recent experiment consisted of actually speaking words in a lower level class that I’ve been mulling over off and on for years but have only ever uttered once in an advanced seminar several years ago. And I think it was ok. I think it was worth the few minutes of time it took, and I’ll think about where I can work it into other teaching I do.

The words? “Result lists are a genre like any other genre of reading. They may look different from tool to tool, but they all conform to certain conventions, and you can read a result list like a type of document, applying genre-specific reading strategies just like you’d approach an article differently than a mystery novel.”

The class I was teaching was of a type that I generally really enjoy: teaching students how to read instrumentally in order to do better research. And we talk about different kinds of reading: skimming, deep reading, and reading instrumentally. In lower level classes this generally involves me passing out a short reading (usually a newspaper or magazine article) and having students work together to generate lists of topics, key terms, and names associated with those topics by reading the article carefully. Sometimes I have them do this with the aid of a worksheet and sometimes I just do it with them on the chalk board.

And this time I added reading result lists as a type of reading that has its own specific place in a research strategy. Result lists come in many forms, but they will all help reveal the range of questions authors seek to answer that involve the search terms you use, patterns in authors or publications that revolve around the terms you used, and clues about the vocabulary of your topic which you can then take note of and use to revise your searches. They are highly condensed, jargonized reference “entries” that teach you a lot about patterns of publication, about vocabulary, and about where you can go next with your searching.

In this particular class I didn’t elaborate on speech genres in general, or explain that they’re “relatively stable types of utterances” that operate within a particular context and reflect “specific conditions and goals” (Bahktin 60). I didn’t even indulge in a geeky digression into the ways that “secondary” speech genres “arise in more complex and comparatively highly developed and organized cultural communication” (Bahktin 61-62). Does this remind you of scholarly communication pathways and norms? Disciplinary discourse conventions? Yeah, me too. But in a 45 minute class with first year, first term students I thought maybe Bahktin was a bridge too far.

Even so, understanding result lists in this way has really helped me, over the years, to get away from the frustration of “failed searches” and become far more comfortable with the idea that spending time opening results here and there and quickly gathering vocabulary and a sense of publishing patterns is one of the quickest ways to arrive at useful results, even if it at first feels like taking detours through a swamp full of weeds. I hope it will help those students, too.

Bakhtin, Mikhail. 1987. “The Problem of Speech Genres.” Speech Genres and Other Late Essays. Edited by Caryl Emerson and Michael Holquist. Translated by Vern W. McGee. Slavic Series. Austin: University of Texas Press. pp. 60-102.

A librarian plays with javascript for the first time

A few times this summer my work with libguides left me turning to people for help with what felt like basic stuff, and each time the answer was “Oh, here are 2 lines of javascript that’ll solve your problem.” So I got jealous. I want to be able to know when two lines of javascript will solve all my problems, and what two lines those might be. Plus, I hate bothering busy people for tiny stuff.

Meanwhile, the other librarians and I were trying to figure out a clear and consistent way to link to catalog records from our Book assets in Libguides. Sure, there’s a URL field there, but over and over we’ve seen people think that if the title is a link, that means that the full text is behind the link. So they open the catalog, see what is clearly information about a book, and then proceed to use the catalog’s search bar to “search inside the book.” Then they’re confused when they just get results for more books. So they open their book again, and try it again. Endless frustrating loop. Also, we actually do have quite a few ebooks, so it’s extra confusing when some of those linked book titles go to ebooks and some go to catalog records. Not a great usability scenario.

So I thought “Well, we can just put a little HTML link in the book’s description box that makes it clear that this link, unlike the title link, leads to a catalog record. But 1) writing a bunch of HTML by hand can lead to errors, and worse, 2) not everyone is comfortable writing HTML by hand. But we did really want a second URL field with clarifying language, reserving linked titles for ebooks.

This, then, was the perfect project for me to learn Javascript. What could possibly go wrong? Here are my two methods of teaching myself from scratch:

  1. W3schools (especially fiddling with their “try it” setups to see if I can figure out how and why things work)
  2. Googling everything I want to do, one thing at a time, and hoping someone else on Stackoverflow has asked a similar question, and that whatever answers they got there will work if copied and pasted into my code.

I started thinking I could get away with making a bookmarklet, but since it turns out that browsers generally don’t allow you to access your clipboard except in very limited circumstances, and that many websites (including our catalog and libguides, the only two sites I cared about) don’t let me inject HTML to build a popup form to get around the lack of access to the clipboard, I finally had to admit that a bookmarklet would not work for me.

So then, according to the developers who helped and encouraged me along over on Mokum, it was time to start thinking about coding a browser extension. It took me a couple of days to admit this to myself because it sounded scary and complicated, but eventually I took this tutorial and its sample files by the horns and dived in. Along the way I got valuable hints from a friend to pay attention to the order of operations (at this point that means I just try things in various orders, but some day soon I hope to actually know what I’m doing), and to use the built in “Inspect” console in Chrome to debug the Javascript (which until now I’d only thought about as being a tool for HTML and CSS stuff).

And today, nine days later, I published my extension to Chrome and to Firefox! Now adding links to catalog records is quick and consistent for everyone in my department. (And if you want the unpacked files to mess around with, here you go, though I must warn you that I am NOT an expert so there may be stuff in here to make an expert weep, or laugh. Any and all suggestions for improvement are welcome.)

At this point I’m only just barely good enough to try lots of things in hopes that one of the things will work, and then to move on to the next thing. And I’m still very hampered by only having the vaguest idea what’s possible and (almost more important) what’s impossible. But who knows, maybe sometime soon I’ll have another tedious workflow that I can speed up by getting my computer to do a bunch of the tedious part for me. The world is my oyster!

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/search.do?…
    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/display.do?…
  3. Primo Journals A-Z list
    1. Old: [your institution].com/primo_library/libweb/action/dlSearch.do?…
    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.