A Librarian Reads the News

Publications and Presentations

In my classroom...

Microfilm Whimsy

Last year one of our microfilm reader/scanners bit the dust, and we know that our ancient analog reader/printer is one service call away from the junk yard. And oddly enough, our microfilm gets fairly regular use here, so being down to one machine was going to be a pinch. So now, as of last week, we have a new machine.

Our dear old T-Rex

Gemini wasn’t exactly this, but it was a lot like this. (Image from here.

This means that we had to come up with a name for our machine, of course. We’ve been naming our machines for at least the last decade when a former colleague said that our first reader scanner should be called Gemini, because it looked like twins.

Then I said our ancient analog machine should be called T-Rex, because it’s ancient but powerful and a fan favorite.


My first year here, we got a fancy new machine that had a silhouette that reminded me of Yoda meditating on a rock, so we called it Yoda. This machine was also mostly a mystery to all who tried to use it, not least because it had no less than 7 on/off switches. Plus a light made to look like a mouse, but wasn’t a mouse, and was actually completely unnecessary unless you were looking at opaque microcards. But nobody could ever remember that. So being simultaneously powerful and utterly mysterious also fit with its name.

You can see Yoda sitting on a rock, right? Right??

Time passed. At some point Gemini was beyond support. And eventually we got a new machine.

Our next machine reminded one of our campus IT folks of the character Crazy Frog, and the name stuck.

And now, as of last week, we have this new machine which looks almost exactly like Crazy Frog, but it isn’t Crazy Frog, and it will be taking over for both deceased Yoda and (eventually) T-Rex. So we spent some quality time this week naming it, and we ended up merging ideas from another campus IT person and from a librarian in my department. The new name? Yandu-Bot. It’s a robot version of a Yandusaurus. It merges the old and the new. It’s way more automated and powerful than our other machines. And as an added bonus, because it has the letters Y and D in that order in its name, the desktop systems administrator doesn’t have to make any changes to the computer and related systems it’s hooked up to, which all have the letters YD for Yoda.

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.