LibraryH3lp Blog

• facebook

Recently, we released for testing one of the most unique components of libraryh3lp: Queues and Routing. This is where we begin to crack one of the tougher nuts in the library chat puzzle, that of one public identity being served by multiple librarians. Solving this problem begins to allow a library a lot of flexibility in their staffing model. Want to have librarians working in their individual offices, coming and going in shifts? No problem, and no worries over disconnects or interrupted patron chats at shift change time. Want to have two (or more) chat computers at a service desk, with incoming chats appearing on both, so that you can easily have two librarians handling the service? That works too, and only one of them will become actually connected to the patron. You can also have a whole gaggle of librarians, distributed around campus or elsewhere, simultaneously watching your service. They'll all see each incoming chat, but again, only one of them will wind up talking with the patron. The others will get a message that someone else took that chat, and they'll become disconnected from the patron.

Let's talk about how this might work to grow a chat service. Think of a Queue as a public entry point. Right now, you're probably just testing and experimenting, but some day, you might want a queue for Reference and one for Circulation. You might want one for each library, if you're in a big system. You might even some day want one for various areas of subject expertise, if you have several specialist librarians who will be online at various times during the day. Then, patrons could expect to connect immediately with an expert in their field (maybe you'll put a link to this queue in your more advanced subject guides).

But I digress. Let's walk through a basic setup. Our hypothetical situation will be for one library with a Reference and Circulation queue and several librarians.

How to set this up? Here is a conceptual overview:

1. Visit http://libraryh3lp.com/ and register for a new account. Think of this as your "admin" account.
2. Use this admin account to create your Queues: MyLibRef and MyLibCirc. Note that libraryh3lp will give you the URL for the queue, and you can use that to make your chat widget.
   
3. Now, create some users. These will be your librarian "operator" accounts. Let's hypothetically create sally-mylib, ed-mylib, jane-mylib, and eric-mylib.
4. You need to assign your users to their queues. Sally and Ed are reference librarians, so you'll assign them to the MyLibRef queue. Jane and Eric work in circulation, so you'll assign them to MyLibCirc. Sally is cross-trained to work in circulation, so you'll also assign her to MyLibCirc in addition to MyLibRef.
5. Note that when you're creating these accounts, libraryh3lp is offering randomly-generated passwords, but you don't have to accept them. You can fill in whatever password you would like. Operators can change their passwords using their Jabber client; later, they'll also be able to change their passwords through the web administration tool.
   
6. You'll probably want to spend some time working on your web chat widget and figuring out what you want to do with your Presence. The queues will assume offline presence if there are no associated librarians online. You could hide your chat widget entirely when offline, or you could have it offer an e-mail form, or whatever you'd like. In our example, if Sally is the only librarian online, both the MyLibRef and MyLibCirc queues will appear online. If only Jane is online, MyLibCirc will appear online and MyLibRef will appear offline.
   
7. Your librarians will need to sign into their accounts with a suitable Jabber client, and you'll want to spend some time making sure you get it set up as best suits your needs. Pay particular attention to how it is set for Away status. If your librarians are signed in, but keyboard inactivity is making them appear Away, your patrons will see whatever you have setup for your offline presence.

Note about naming your queues and users: Libraryh3lp has typing notification built-in everywhere, and so the names do, in fact, matter a bit, since patrons will see them. For a queue, the patron will see "queue-name is typing," regardless of what librarian operator is actually working on the chat. For an individual's chat widget, the patron will see the individual's account name. So, it might be nicer for your patron to see typing notification from something like MyLibRef or pam-mylib than queue1 or user23. Your individual librarian account names will not really matter unless you plan to actually have entry points for individuals (as opposed to queues) in your system. For instance, perhaps your librarians will have their own staff pages, and they might want their own personal, non-queue, widget there, and having something recognizable in the typing notification is a nice touch. As an aside, the chat widget on this blog page is a queue that Eric and I both monitor, and its Presence is available if either one or both of us are online. If we are both online, we'll both see your message, but only the first one to type will be connected with you.

Another note that becomes important during testing: each patron can have only one active libraryh3lp widget chat per browser instance, even if using different queues. For this reason, if you wish to simulate more than one patron, use separate browsers (such as Firefox and IE) on one computer, or use multiple computers and multiple browsers to simulate many patrons. This is an HTTP restriction that Eric has explained to me repeatedly, and I can only nod my head. Librarian operators can have multiple patrons.

That's it in a nutshell. The wiki has a lot more detail. The administration interface, as you'll see, is very basic and bare bones right now. That will get fancier in the future. Currently, we are not storing any transcripts, but it will be possible to opt into that in the future.

Next major development milestone: gateways for external IM networks, like AIM. Coming soon. We're already running test gateways internally and will release this for public testing within two weeks.

• facebook

I've been needing to write about the technology behind LibraryH3lp, but, as these things inevitably go, I've been too busy creating that technology to have much opportunity to get meta. As a compromise, I've decided to do a short post about the most visible piece of the system---that little chat box sitting in the sidebar.

The first thing that stands out about this widget is that it's written in JavaScript. As you may know, most (not all) XMPP chat widgets out there currently are made using Flash. And everybody chooses Flash for a very good reason: it's easier. Quite a bit easier, in fact. So, did I have some specific motivation for bucking the trend or was I just being contrary? (It's been known to happen.)

Well, here's one reason: accessibility for patrons with visual disabilities. I'm not good with screen readers, so I can't really say how well this widget works (compared to what alternatives, I don't know), but with Pam's help I was able to muddle through and determine that at least it does work. It needs real testing by someone who actually knows what he or she is doing, but it's looking promising. That's a big plus.

And here's another reason: portability. Arguments about the relative portability of JavaScript vs. Flash can go on forever. In a nutshell, Flash gives you better "write once run everywhere" (a big part of the reason it's easier to write a Flash widget), but JavaScript gives you more "everywhere". Flash may or may not ever come to the iPhone and other portable devices, but I know this widget works today. (I also have grand hopes that it will work on the Wii, but so far haven't had the opportunity to test it.)

Those are two solid reasons that I know you librarian types care about, but I'm a programmer type, so my real reasons are, perhaps, a bit twisted. I chose to do a JavaScript widget fundamentally because it's hackable.

I don't mean hackable in the scary bad-guys-are-going-to-steal-your-identity sense, I mean hackable in the you-can-do-what-you-want-with-it sense. It's designed from the ground-up to be as open a system as I can make it: the HTML is as purely minimal as I could make it (there's a little cruft that was necessary to make it layout correctly on IE6, alas), everything about the look-and-feel---even the layout of the boxes---is controlled by CSS and you can completely substitute your own CSS, and the JavaScript is open, with server-side APIs to the n-th degree.

Here's the idea: I can make certain things simple, but I have to make choices about what's simple and what's not-so-simple. (I can't make everything simple because that would involve both telepathy and clairvoyance, and if I had those skills I wouldn't be wasting my time programming.) Since my choices aren't going to be right for everybody, I don't want you to be limited by my own lack of imagination and foresight. And so, I did my best to create the hackable widget.

At this point there are only about half-a-dozen people outside of UNC using the widget, and most of them haven't yet gone public with it. But one of them has, quite independently of me, taken me up on the hackability challenge. They've not only written their own CSS, but they've dug in to the APIs and written their own JavaScript for it.

Oh, man! I'm still geeking out about it!

I'm striving to apply the openness principle to the design of the rest of the system too. As a quick example, the web-console back end that you'll use to manage the queuing and routing is designed entirely around RESTful resources. This will translate into an API that anyone can use to write custom clients or mashups for librarian use, in addition to customizing the UI for patron use.

Before closing this post I want to emphasize that little bit up in the header that says "open-source." No, I don't have a nice prepackaged download available as of yet, and no the code is not checked in to the Google Code project (I use Git, they use Subversion, it's this whole big culture-clash thing). If you're my target audience, however, I don't expect that to stop you. It's JavaScript---again, another reason not to go with Flash---I'm sure you're perfectly capable of choosing "view source" and going from there. It's GPL3: take it, run with it, have fun, send me patches.

And, lastly, just so no one overestimates my contribution, this widget is built on top of JSJaC and jQuery, both of which are totally awesome libraries that I just can't say enough good things about.

Happy Hacking!

• facebook

This weekend, I played with the CSS hooks a bit. I am far, far from a designer, but I managed to give the little Davis Reference pop-up chat widget a bit of a facelift with some colors and rounded corners in Firefox (only). If you're curious, you can view it if we're online here: http://www.lib.unc.edu/livehelp/

My CSS file only contains the parts of the CSS I'm changing; for the rest, I'm just taking the libraryh3lp defaults.