Libraryh3lp + Twilio = Text-a-Librarian!

We launched our instant messaging reference service, based on Libraryh3lp, in the summer of 2008. Since we've been so happy with Libraryh3lp as our IM platform, we were thrilled to learn that they offer three methods for adding SMS capabilities to create a text-a-librarian service. The first requires that libraries purchase and maintain an Android phone; the second uses the SMS functionality of Google Voice; and the third uses a service called Twilio, which provides web-service APIs for building voice and SMS apps. We went with the Twilio version, largely because it integrates so well with our existing IM setup.

So a bit about that setup. When we launched our Libraryh3lp-based IM service in July 2008, we opted to use Pidgin, a free Jabber client, for client software for library staff to use to monitor our IM queues. (Note for fellow Mac users: Pidgin is Windows-only, but Adium accomplishes the same same thing. And it has a cute little duck icon to put in your dock, and he jumps up and down and quacks when you get an IM/text.) When staffers are ready to take IMs, they open Pidgin (or Adium), connect to our queue on Libraryh3lp's server, and wait for the IMs to roll in from the widget on our Ask A Librarian page. Libraryh3lp has since launched web-based operator access that doesn’t require use of client software like Pidgin and Adium. The user chats in the widget in the web browser, and what the library staffer responds via the web-based interface. This method has the benefit of not requiring installation of client software on operator workstations.

Enter our Ask a Librarian page and integrating it into the reference and instruction spiels in dealing with students, that was all that need to happen on the technical side.

Here's the beauty of the Twilio method: incoming texts are received by library staff in the very same “place” as the IM, which means that little additional training was necessary prior to launching the service as a pilot in the summer of 2011 and as a full service for fall semester 2011.

Here's what it looks like to a student; this screen shot is from my iPhone:
Patron view of text interaction on iPhone

...and here's what library staffers see in Pidgin:

Librarian view of text interaction on iPhone

The only difference between what this window looks like if the incoming message is an IM versus a text is the string of info circled in pink; it shows the phone number of the user. (Smudged out. No calls, please. :) )

On the downside, it may be difficult for staffers to identify incoming transactions as IM or text. Knowing whether a question came via IM or text would affect how library staff answer the questions, i.e., assuming that a student was sitting at a computer IMing versus standing in the stacks or riding the light rail with a phone or mobile device. Also, students and faculty might be incurring costs under their phone/mobile plans, so brevity would prevent additional charges, although--again--they assume responsibility for those charges. In our training with reference staff, we covered using URL shorteners like bit.ly so that if they need to send monster catalog or database URLs, they'll fit under the SMS limit.

There are two other, but seemingly less desirable, options for detecting the origin of an incoming question. First, we could have set up texts in a separate queue from IMs, but then library staff would have to monitor incoming questions in two windows. Second, with the web-based operator interface, as opposed to using Pidgin/Adium client software, queues can be assigned their own avatars; we could create an SMS queue and assign the avatar to be a picture of a cell phone. The web-based operator interface also has a character countdown that only appears for messages coming from phone numbers to reminnd staff to limit responses to 140 characters or less. However, our current Pidgin/Adium model has many virtues over the web-based operator interface—including internal use as a means of staff communication—and re-training all staff to use it instead of Pidgin would be time-intensive and possibly frustrating for staff. There is also a character countdown plug-in from dossy.org that has worked very well with Pidgin for us so far.

"But Nina, what if no one is monitoring the queues and a text comes in?!" you ask? Excellent question! If a text message is sent when no one is monitoring our queues, this message is returned: "We're currently offline but will get back to you as soon as possible." This message is currently not customizable, but the good folks at Libraryh3lp say that enough Libraryh3lp customers have been asking for that that it will likely be prioritized in development. Here's what the user gets in response-again, from an iPhone screen capture:

patron view when no librarians are monitoring

When the first librarian or library staff member logs in the next day, any texts received during off hours are effectively assigned to him or her (see screen capture below). They can be transferred to others if necessary. Library staff can take a bit of time in replying to the text, as the communication is not synchronous, as IM is. For example, if a library staff member logs in to Pidgin/Adium, and there are two chats waiting, and an IM comes in right away, the staff member should attend to the IM first, and then respond to the chats.

what librarians see in Adium when they log in again

After a librarian responds, the user simply gets a response as a text, which looks like this:

what patron sees when staff send message

Cost of the service, you ask? As with the "regular" Libraryh3lp cost, it's a steal. The IM pricing structure is based on student FTE for academic libraries and community size for public libraries; we pay less than five hundred dollars a year for our medium-sized student population. Adding Twilio to the mix costs $1.00 a month for the maintenance of the phone number and $0.03 per individual text. We paid $42.00 for a year's worth of the phone number and 1,000 text messages, but we can add to that at any time if the service is a raging success. Students and faculty using the service will incur costs per their own mobile/data plans, for which they are responsible.

We are still sorting out some service management issues, but the summer pilot was successful, and we are seeing an increase in the service into fall as our users have returned to campus and are attending instruction sessions, where all of our reference modes are advertised. In terms of staffing, there was some fear initally that we would be overwhelmed by text questions, but that has not been the case. Other issues include creating a budget based on tracking use of texting, and how to secure funds on a semester-by-semester basis, and how to market the text service-and our full suite of services-in appropriate venues. If you are interested in giving Libraryh3lp a try, have a look at this information on their blog about signing up for trials. In short, I highly recommend them all around; we have been very satisfied with the quality of the service and support we get from them, and adding text service was a snap!