When I finally got control over the library’s Web presence last year (a long process better discussed in a post of its own), the first thing I did was take down the library “subject guides.” You could hardly call these things subject guides; they were just a bunch of Web links in different areas. Some were more useful than others. The guide for “science” had three links. In addition, a very high percentage of the links were dead, because it wasn’t anyone’s job to check them and for a long time, there was no one to make changes to them. This just wasn’t a priority for anyone.

When our Coordinator of Public Services started a little over a year ago, she was really gung-ho about creating useful subject guides for our patrons. There were a few barriers though. The first was (or is) time. Each librarian is a liaison to a whole lot of programs. One person is liaison to “Social Sciences.” Another is liaison to “Humanities.” As Distance Learning Librarian, I am the liaison to 10 academic programs (from Masters in Business Administration to Masters in Civil Engineering to Masters in Nursing to Masters in Military History and more). I’m lucky, because I’d been creating subject guides for my programs over the past two years and have pretty well-developed ones already in use. My colleagues are starting from scratch with our on-campus students, so it’s a lot of work and for everyone, subject guides are more of a “when I have free time” sort of task. Were I running the show, I would probably set a deadline for when people had to be done with these, because otherwise, there are always more pressing things to do.

The second barrier was technology, which wasn’t really seen as much of a barrier by anyone but me. Currently, the way the website runs is that people give me content and I put it up online. This seems to me like a recipe for disaster with the subject guides. Sure, it’s not so hard to initially put some subject guides online, but what about when links change? Or when a database changes its URL and I have to make the change on 20 separate pages? I’d originally thought that we were just going to link to the relevant area on the “databases by subject” page, but the Public Services Coordinator wanted the individual databases to be explicitly linked to in each guide. I wanted to figure out a system where I wasn’t totally in control of maintaining the content, because it would be a full-time job in itself (and, as you can imagine, I do have a few other duties… just a few!).

So began my exploration of the options for low-threshold, sustainable subject guides. I say low-threshold because I’m not a coder. I can’t rig up some fancy ColdFusion CMS like the lovely Karen Coombs did at the University of Houston. The main goal for me was to have my colleagues be able to update as much of their own content as possible and to not have a situation where when a link changes, I will have to change it in a million places.

The first thing I thought of was using del.icio.us. On the companion website for my book, I have a dynamic list of relevant links for each chapter. These lists actually pull from the things I’ve bookmarked chapter1, chapter2, etc. in del.icio.us. It would certainly be easy for my colleagues to bookmark web content in del.icio.us and add an annotation. And it’s definitely easy also to display it on a website. del.icio.us has a took called link roll which will display a chosen portion of your links. It allows you to choose what tag(s) you want to display, how many you want to display, and how you want the list sorted (alphabetically or chronologically). It will then give you the JavaScript that will enable you to display it on your website. If you know anything about CSS, you can even style the output to look like the rest of your site.

del.icio.us would also work for the database lists. I could create a bookmark record for each database in our library (with the proxy prefix). I could then tag each of these databases with the names of the subjects they should be placed into (such as db_political_science, db_mathematics, etc.). That way, if the URL of a database changes, I would only have to make the change in one place in del.icio.us.

I actually got so far as training my colleagues on how to use del.icio.us before I changed my mind. The main reason I didn’t go with del.icio.us was because I didn’t want to be so dependent on a third-party vendor; especially one that we didn’t pay to provide the service. I know del.icio.us isn’t going anywhere, but it can and has gone down. When it does go down, lots of the content from our subject guides will inexplicably disappear. While I don’t imagine that disaster will strike del.icio.us and it will be put out of commission forever, I’d just hate to be that dependent on it. As bad a server administrator as I am, I’d rather have the data living on our server. Also, I’d still be responsible for maintaining the rest of the content on each subject guide (contact info, subject headings, book lists, journals, etc.), so it wasn’t a perfect solution for the whole site. Still, I think this would be a great option for many libraries, especially those who don’t have regular server access to update their web content.

Our Electronic Resources Librarian and I discussed LibGuides, but we knew that the library was not going to spend the money on it. I must admit that LibGuides is very cool, but we don’t currently need a lot of the features they offer. I like that they have a bookmarklet for web resources, that you can easy embed search tools (for catalog, databasese, etc.) and that you can easily display RSS feeds on the site. Usage stats are very nice too. The rest of the stuff is cool, but not really that important to us. I think it’s a great tool for larger libraries where there are lots of subject guides and lots of hands in those guides. For the number of subject guides we’d create at our little library with six liaisons contributing, we don’t need something we’d have to pay for. It’s also great for libraries that are integrated in social networking software or have blogs and websites they might want to embed subject guide content on. It’s cool, but not really something we need. For more views on LibGuides, check out reviews from the Academic Librarian, the Librarian in Black, and BiblioTechWeb.

Next, I started looking at open source options. There are plenty of libraries that have created their own homegrown systems for creating and maintaining subject guides. Some (like the one that Karen Coombs created at the University of Houston) are Cold Fusion-based and are not something one can easily just install and get going with. Others are much simpler. Some libraries/librarians have been kind enough to make the products of their labor open source.

Here were some of the tools I looked at that seemed at least remotely feasible for me to take on:

  • Research Guide – From the University of Michigan. Wayne State also uses it. Looks good. Was updated in 2006. Was just concerned about how to set up the authentication stuff.
  • LibData – from the University of Minnesota. Hasn’t been updated since 2003 or 2004. library is not using it anymore. (update: looks like they are still using it; not sure where I got the idea that they weren’t)
  • Pirate Source – This one was developed at Eastern Carolina University, but is used at a bunch of libraries. The install script didn’t work so I had to create the tables and SQL queries manually. Had trouble trying to get it to work with PHP5. Not sure I like the initial page since people are inundated with choices and it may confuse some.
  • Subjects Plus – my personal fave. This is an enhancement of Pirate Source developed by Ithaca College. It’s great-looking though it takes up a lot of screen real estate. In the sidebar you can put info about the liaison, links to tutorials, call numbers and syndicated news feeds. I love the “Try these First” feature since students usually just want to know what the very best resources are. I still don’t love the initial page where they choose the guide and then have the option to select the types of resources they are looking for. It’s good to give people options, but sometimes less is more, I think.

I was actually all set to go with Subjects Plus (which really does rock as far as subject guide software goes) and had it installed on our server, but then got cold feet. While it’s a great option now, will I (or my successor) be able to successfully maintain the software? These are all software projects developed by one or a few people. If these universities end up implementing another tool in the future, there probably won’t be continued development of the software (as was the case with LibData). For libraries without coders, open source software like this is probably not a good long-term option. I can usually muddle around enough to get something installed, but if we eventually upgrade our versions of PHP or MySQL and something breaks, I won’t know what to do to fix it. And when I leave my job in the future, I have no idea if they will make web skills a real priority when hiring my successor. Non-coders are better off relying on thriving community-driven projects with lots of people fixing stuff, extending the functionality, and writing documentation. That was my next stop.

It’s kind of funny that it didn’t dawn on me to try MediaWiki until I’d exhausted most of the other reasonable options (does that mean I can’t be called the Queen of Wikis anymore?). It’s not that a wiki is a bad idea, but I worried about getting my colleagues on-board with using it. While MediaWiki is not the most difficult thing in the world to use, wiki markup isn’t intuitive, which I see as the big barrier to its use. Anything that involves learning a new way of doing things is going to be difficult for some people. I thought about installing a WYSIWYG editor, but I have a bad taste in my mouth from recently upgrading Drupal and having TinyMCE and the chat extension break. I want to be as little dependent as posible on extensions that could break when I upgrade the software. This is an important thing to consider when you’re using wiki/blog/CMS software. These extensions are great, but if they are dependent on a specific version of the software, you will either be stuck not upgrading or will have to make it compatible with the latest version on your own. Just like the wiki/blog/CMS itself, make sure there is a community behind the extensions you choose; a community that will make absolutely sure these extensions work with the latest version of the product.

There are a few key benefits of using MediaWiki software for this purpose in my opinion:

  • It’s the software that runs Wikipedia, so it isn’t a project that’s going to go South anytime soon.
  • Granular permissioning allows me to give my colleagues only the rights they absolutely need and to give a select few more rights.
  • If we want faculty or students to contribute in the future, it’s possible.
  • The full-text of the wiki is searchable.
  • We can assign each subject guide to categories so that the guides can be browsed as well.
  • It’s completely flexible; we can make the pages be however we want.

The two big negatives in my opinion are the lack of a WYSIWYG editor (which is something they said was soon going to be a part of MediaWiki back in August 2006) and the fact that it’s a pain in the behind to monkey around with the look. Because it’s designed specifically for the Wikipedia, making it easy to change the look wasn’t a big priority. I think I “broke” the wiki 20 times while messing around with the PHP for the skin I’d chosen. I’d make a change, get an error message, back out of my change, figure out what I did wrong, fix it so that the syntax is correct, make another change, get an error message again… I think I’ve made it look halfway decent (click on the pics below to view the full-sized images of the template I created for my colleagues), though there’s still a lot of tweaking I want to do, like adding our logo. We don’t have any content up yet, because no one has given me any, but once I receive it, it shouldn’t take me long to have it looking good. I’m itching to get some guides up there already!

libguide_notloggedin

libguide_loggedin

To deal with the problem of database links being scattered all over the place, I came up with a decent, but not perfect, solution that I borrowed from UNC Chapel Hill. I noticed that in their subject guides, they didn’t link directly to the database but to what was essentially an “authority record” for the database; a single page where the link to and description of the database resided. I decided that I’m going to create a page for every database we have and in the subject guides, we will simply link to that page. Therefore, if the link to a database changes, we’ll only be fixing it in one place in the subject guide wiki rather than a million places. It means two clicks for the student, which sucks, but I’ll try to make it as obvious as possible what they need to click on once they get to that intermediate page.

I don’t think MediaWiki is the perfect solution and other solutions will work better at other libraries. I think it’s important when looking at any alternative to static HTML subject guides that you sit down and really think about what functionality/features you absolutely need vs. what would be cool but isn’t totally necessary. The simpler you can make things, the easier it will be to maintain. Then, look at what is already out there. Will anything out there meet your needs or do you need to create something yourself (or pay someone to create something for you)? Finally, think about whether this is a sustainable solution. What will it take to maintain this next month? Next year? In three years? If it’s an open source tool, is it developed by a community or just one person? If that person stopped development, would someone on your staff (or in IT) be able to continue development so that it continues to work and isn’t a security hazard? The same goes for something you create yourself or pay someone to create; think about what it will take to make this work in the long-term, not just to get it working now.

Honestly, I have my doubts that these subject guides are going to make much of a difference for our students. Looking at our Web stats, I see that our undergrads simply aren’t visiting our site, and I don’t think that is going to change. I’ve been putting course guides up for my own and my colleagues’ instruction sessions and it hasn’t impacted Web traffic (beyond the day of the session). I think the key is to focus on being where our students are, both physically and online. If we can understand their information-seeking behavior and put ourselves in their path, right at reach, we’ll be much more likely to have an impact. I think the library resources should be like the impulse buy area in a store. It’s just so easy when you’re paying for your groceries to reach out and grab that Star Magazine or that pack of gum. I want the library to be that pack of gum (or Star Magazine… that would work too). And while we truly have achieved that with the online graduate students, who have the library right in their classroom, we haven’t even started to move in that direction with the on-campus folks. Putting our stuff where our users are… now that would be 2.0.