LibGuides, you’re not “Web 2.0” without an open API

Update: I’ve been in touch with a Springshare representative who tells me that things like the contextually aware D2L widget from Portland State University will work in LibGuides 2.0 and apparently, the responses we’d received from support were based on hypotheticals (though we’d explicitly sent the link to PSU’s code in our emails to support). This is very good news, but I am dismayed that it takes a blog post to receive a straight answer, because what we’d heard from support originally was that there was a change in access to the API. What I do know for sure is that if you want to use JSON data and full access to the API, you will need to upgrade to the CMS product and that what they used to call an API wasn’t a true API. So there isn’t access to the full API with LibGuides 2.0, but apparently there never was, FWIW.

When you think of Web 2.0 (a term I know you know I dislike), what do you think of? Rounded corners? The read/write web? Social media? Collaboration? The wisdom of crowds? How about open APIs? Maybe that last one doesn’t come to mind for most people who aren’t web developers, but open APIs are critical to so many of the “2.0” web services we rely on. For those who don’t know what an API is, it is short for Application Programming Interface, and it is what allows developers to pull content or data from one web service into another. One application will make a call to the other through the API to pull in updated data/content regularly. It is the technology behind many incredible mashups out there (I’m particularly in love with those that layer data on top of Google Maps) and is how so many of our web services connect to one another. Use the wonderfully clever IFTTT (if this then that)? Won’t work without APIs. You don’t have to be a programmer to recognize the value of all that.

I thought APIs were so integral to social software back in 2005 that I wrote about them in my book Social Software in Libraries. My writing on the topic was originally going to be an entire chapter (Chapter 2 to be precise), but the powers-that-be wanted it edited down, so it ended up in the chapter on “the future.” And, as predicted, it has become an increasingly important part of web 2.0 services in the ensuing years.

LibGuides was originally marketed as the Web 2.0 version of subject and course guides. It offered a Web 2.0 look-and-feel as well as tools to gather user feedback. And it certainly made it easier for web design novices to develop decent-looking guides (and ugly ones too as I’m sure we’ve all seen). One great 2.0 feature of LibGuides was the open API, which allowed you to pull content from LibGuides into other websites, like the library website or a Learning Management System (like D2L, Blackboard, Canvas, etc.). This was what my colleague Mike at Portland State relied on to create our contextually aware D2L widget that connected students from their D2L course homepage directly to the appropriate course guide (where one existed) or subject guide to support their research. I led our adoption of LibGuides at PSU and this widget was one of the best things to come out of it.

I’m now in serious deja vu mode as I work with colleagues here at Portland Community College to implement LibGuides (they’d been using the open source Library a la Carte for many years). It’s actually great to have a second chance to implement LibGuides knowing what I know now and what I wish I’d done early on. Many of our students transfer to Portland State eventually, so the college tries to create a consistent experience for students wherever possible. Moving to LibGuides is another positive step in that direction and we planned to use the PSU widget to make our D2L instance even more in-step with PSU (and easier for students to use). However, all our plans went on hold when we were told by Springshare that the open API was not a part of their LibGuides offerings in LibGuides 2.0 (they told us we have access to Tools –> Widgets, “many of which replicate what you might recall as API in v1”). I was pleased to find that this was an issue with how they define API (and did in the past), so apparently nothing has changed in 2.0 access.

LibGuides promoted itself early on as being different from other library vendors, yet this move is exactly what I’d expect from a vendor that knows they have a critical mass of customers, next-to-no competition, and knows users by and large won’t leave. So, in order to pull more customers into their more expensive product, they make a certain feature that was part of their cheaper product now only available in the more expensive one. This is similar to the move EBSCO made when they pulled certain critical history journals our of Academic Search Premier and made them only available in their America: History and Life and Historical Abstracts full text products (which mostly otherwise contained junk at that point). Do you really want to be on par with EBSCO, Springshare?

But the funny thing in this case is that I can’t find this information about the API no longer being open to LibGuides customers anywhere on their website. In fact, I find evidence of the opposite being true. So, if this is the case, it is not only a crappy thing to do, but, unless I’ve lost my ability to search a website, on nebulous legal ground, because people are making purchasing decisions based on the evidence on their website that they will have the same API access in LibGuides as in the CMS. As the person who promoted and helped get LibGuides adopted at two institutions, I am seriously pissed off.

My next American Libraries column is all about how we can’t be complacent with library vendors, some of whom continually change (and in many cases decrease) their offerings without decreasing their price tag. This is just another example of the sort of stuff that goes on all the time and that we should not accept without a fight. These companies cannot survive without us, yet they know that ditching them will be painful for the library and for our patrons. We have to find ways to flex our collective muscle even when it hurts (especially when we are part of large and powerful consortia… cough cough…Orbis Cascade Alliance… cough cough) to advocate for what will best serve our patrons. Otherwise, we are not acting as good advocates for our patrons nor good stewards of the funds we receive.

Image credit: From 2007 LibGuides website, which focused on how it brought “the benefits of Library 2.0 to your institution.” Courtesy of the Wayback Machine.