Pidgin 2.6.x: Houston, we have a problem

Well, we have less-than-good news. We'll get straight to the point.

The latest versions of Pidgin, 2.6.x, are not really suitable for monitoring LibraryH3lp queues. If you use a 2.6.x Pidgin to answer questions from queues in a multi-librarian environment, you are at risk for leaving patrons hanging when librarians change shift.

This is a big deal. Since the beginning, Pidgin has been the main external LibraryH3lp client used on the PC. It is open source, supports plugins, and is multi-protocol, so librarians can be signed into lots of different accounts as needed. Most importantly for LibraryH3lp, it always sent the Jabber protocol standard "gone" notification back to the server when the librarian closed a conversation window. This is a critical piece of the routing system that allows LibraryH3lp to work effectively in a multi-operator environment.

With 2.6.x, if a patron's original librarian has closed the patron's conversation window and signed all the way out of their account, new messages from that same patron will go off into the ether rather than getting routed to other librarians on the queue. Those messages will not appear until that original librarian signs back into their account, which may be hours, days, or even weeks later.

So, what can you do if you've been using 2.6.x?

The easiest thing is to stop immediately and downgrade. Version 2.5.9 is the most recent release that sends the "gone" notification. It was only distributed in source code format. We have compiled it for LibraryH3lp users and you can download it here. Happily, you can just run the installer and it will keep all of your existing preferences and account information.

We have a ticket in with the Pidgin developers to see if they will resume sending "gone" on window close in the future. No word yet, but we'll update when we know more.

In happier external client news, the Digsby developers were very responsive to a request to start sending the "gone" command. Digsby is now a suitable client for use with LibraryH3lp queues! Digsby also displays LibraryH3lp queue avatars and pulls the patron's IP address and referring URL extremely quickly; Pidgin takes about 30 seconds and doesn't display the queue avatars at all yet. Additionally, Digsby has a slick little floating chat window that sticks in the foreground while you keep a web page up. Very handy for chatting, researching, and sending links all at the same time as us librarians do so frequently. But this all warrants its own blog post... coming soon.

SMS Gateway (Android variety) updated

Back in March, we released the first version of our Android phone SMS gateway. It worked great on the original G1 phones, but then new models came out. A few libraries purchased G2 (Mytouch 3G or HTC Magic) phones and had problems, even though the phone's operating system should be the same.

Thanks to Derik Badman from Temple University physically shipping us one of these phones, the problem is solved. We were able to connect his phone to Eric's Mac and debug it pretty easily, once we had our hands on the actual device.

While we were working on the problem, we learned a couple of things that led us to add visible features to the phone portion of the application:

1. Now, when you press the Start and Stop buttons, the phone displays feedback that the app actually started or stopped.
2. There is a place to enter your phone's telephone number. As it turns out, not all Android phones actually know their own phone number, and without it, the LibraryH3lp gateway fails to deliver messages. Now, there is a field in the application where you can provide the phone's number. This is a lot easier than trying to get your mobile provider to correct this over the air.

The app should also work with international phone numbers now. We know it works for at least two libraries in two different non-US countries, anyway.

The updated app has the Android SMS gateway working for all libraries we're currently aware of that want to use it. Let us know if you're having trouble with it.

Derik, your phone is in the mail.

Updates to queue selection feature

Last weekend, we released the queue selection feature for the librarians' webchat client. It introduced a new button inside the client that let librarians select their queues. Queue selection is persistent across logins. That is, the selected queues stay that way across multiple logins until the librarian changes them.

This weekend, we tweaked queue selection in the webchat client a bit to address a couple of things:

• Librarians may not remember which queues they last had selected and may not always remember to check each time they log in. This may result in queues getting left unstaffed accidentally.

• Librarians may unwillingly receive offline messages (or just ill-timed new regular messages) from queues they do not wish to monitor since they cannot de-select queues before the messages arrive.

We're addressing these situations in the following manner if the librarian is assigned by the admin to more than one queue:

1. Upon login, the queue selection dialog is opened automatically.
2. The librarian will not receive any chats from queues.
3. Once the librarian has dismissed the queue selection dialog, they will be able to receive chats from queues.

This way, the librarian can see which queues they're monitoring at each login, can make adjustments if desired, and will not receive any incoming chats until they have selected the desired queues.

If the librarian can only staff a maximum of one queue because the admin has only assigned their account to one queue, then the webchat client does not display the queue selection dialog at login time.

Now, what about queue selection on external clients, like Pidgin, Adium, and the Meebo website? This question came up on the Group last week, and it's a great question. Initially, we didn't think we could do anything to support this feature in most external clients, aside from possibly Psi, in anything other than the long term.

However, we've been thinking about it, and we have a new idea, one that will work in ALL external clients and can be implemented quite quickly.

We will create a bot for queue selection, and then the bot can optionally be buddied by libraryh3lp users. If users have this particular bot buddied, each time they login, the bot will IM them with something like:

"Hi there librarian-pam, you are currently watching the following queues: ref-desk, refworks. You are NOT watching: endnote, circulation. Send "watch queue-name" to add a queue. Send "drop queue-name" to stop watching a queue. Send "status" to review your queues. Send "help" for further instructions."

Anytime they want to change queues during a shift, they will fire off an IM with the desired commands to the bot.

Of course, this is not as friendly as nice graphical interface, it will require training, and it still may intimidate some librarians. However, it will allow queue selection to be available to all clients, which is very exciting!

This queue selection bot is not yet available. We'll blog about it when it is, probably in a few weeks time.

New librarians' webchat client features: Queue selection, Profile pages, and Tag for followup

Lots of new features for the librarians' webchat client installed this weekend!

It's no accident that these latest things seem like they would be helpful for larger, collaborative services. We're grateful to the state of North Carolina for funding Eric's development time for creation of these features. Source code can be downloaded from Eric's github; these particular features are part of the webchat section.

We'll be providing more detailed documentation later (we're tired), but to briefly run down the changes:

• Queue selection. When your librarians sign in using the webchat client, they have a new option that allows them to control which queues they are monitoring. By default, they're monitoring all queues to which they are assigned in the admin interface, but they can opt out and opt back in to queues as needed. This gives you a lot more flexibility in how you build your service. For example, if you have a collaborative service, maybe your librarians should only monitor a particular shared queue for certain hours, but they should monitor some particular central queues for their own library at all times. Previously, this would have been accomplished using multiple LibraryH3lp accounts, but it's much easier now.

• Profile pages. In the admin site, there is a new tab for profile pages. These let you provide helpful metadata for the librarians who are staffing your services. Profile pages work with your administrative hierarchy, so that you can provide more general information at a high level and more specific information at the queue level. Librarians can access these in the webchat client by clicking on the queue avatar, which admins provide in the queue properties section of the users/queues tab. If no avatar is available, we provide a generic one.

• Tag for followup. This sends an email transcript, and optional note, for a specific chat to email addresses provided in the admin interface. Currently, the email addresses are for the top-level admin (the email address provided at account registration time) and for any email address provided in the user properties in the admin site for the queue owner AND the operator involved in the chat.

We know that some of these features would benefit from further customization, and we plan to get a lot of it done soon.

For example, with tag for followup, we want to show the operator which addresses will be used and also let them remove or add additional addresses. Also with tag for followup, currently, you can't see or change the email address for your top-level admin. In the future, you'll be able to edit this, but for now, if you need to change it, please email us.

We will also be providing tag for followup and profile pages on the chat management page used by external clients like Pidgin and Adium in the near future.

Google Voice SMS Gateway

We just installed our Google Voice gateway, and it's ready for testing.  You may know that  LibraryH3lp already has an SMS gateway, one that runs on a library-purchased Android phone.  The Android gateway continues to be a solid choice.  However, for libraries needing a completely free option, without the cost of acquiring an Android phone and service provider, there is the Google Voice gateway now. 

We prefer SMS solutions that let patrons text their library using a regular phone number, so that they can easily store it in their contacts list.  Since Google Voice provides a phone number and can receive text messages, it was a good fit.  By default, Google Voice wants to send text messages to a mobile phone you connect with your Google Voice account.  You can also reply to them on the Google Voice website, but alerting is a problem.  How do you know you have a text message in the first place?  Google does not provide email or Google Talk chat alerts in Google Voice currently.

But this is where LibraryH3lp comes in.  To configure your Google Voice gateway, sign into the admin site and select a queue for this gateway, or create a new queue for it.  Create a "voice" gateway, and provide your Google login (username and password).  Note that you never supply your Google Voice phone number.  You'll probably also want to setup your Google Voice account to ring one or more of your public service desks in case someone calls it expecting to have a phone conversation.  While you may advertise the number for your text message service only, once the number is in a contacts list, someone will very likely try to call it at some point.

Now, text messages sent to your GV number will arrive as regular LibraryH3lp chats.  If you were offline when the message came in, you'll get it the next time that queue comes online.  You reply from within your chat client, and these messages can be transferred just like any other chat in LibraryH3lp.  If you're using our webchat client, LibraryH3lp will detect that your patron is coming in on a phone number, and you'll get a character countdown to assist your staff with making shorter replies, like this:

You won't get this countdown by default in other clients, but there are still things you can do.  You can train staff to watch for a special queue name for text messages.  There is a character count plugin for Pidgin that looks very promising (I have not tested it, but I have no reason to believe it would not work).

All of that said, we need to add a few caveats.  Google does not currently provide an official API for Google Voice.  Thus, this gateway works through screen scraping and polling, just like the other Google Voice applications coming out now.  This means that if Google changes the code in the Google Voice SMS display area, it may break the gateway until we can account for the change.  It also means that Google may throttle traffic if it detects some magical and unknown level of activity; the gateway application already tries to account for this, but further adjustments may be needed.  Lastly, so far, Google has not shown signs of shutting down Voice applications, so we are optimistic, but we can't guarantee this will always be the case.

The Android gateway is still a safer bet.  It uses published APIs to work with an open operating system.  But as we all know, budgets are very tight these days, and free or very inexpensive solutions are extremely useful.

Show patron's IP and Referring URL

Besides the new version of the webchat client, we also pushed out two entirely new features today. Both of these features relate to patrons using the LibraryH3lp widget:

• Show patron's referring URL. This will be handy to give your librarians context when answering chats. Now, in addition to the queue name, librarians can see the exact page the patron is visiting from. This works for embedded widgets and pop-up widgets now. It will work for the follow-me widget soon.

• Show patron's IP. Again, this will give librarians better context for answering questions. In particular, it may help librarians identify on-campus versus off-campus patrons when dealing with e-access problems. One of our users also pointed out that they wanted this feature to help deal with the occasional prank chat coming in from library-owned computers.

So, how do you see this stuff? It depends on the client you're using. If you're using the webchat client, it will be plainly visible in the patron's conversation window. Like this:

If you're using an external Jabber client, it will show up wherever your client displays vcard information.

In Pidgin, it will show up in the Get Info area. There are two ways to get there. You can either pick Get Info from the Conversation menu in the patron's chat window:

Or you can right-click on the relevant guest buddy in your buddy list (be sure to get the right one).

A related feature, avatars for queues, is in the works...

Webchat client enhancements

We just rolled out a new version of the librarians' webchat client. A rundown of the changes:

• Improved ability to stay connected under various network conditions. The first version of our webchat client returned the user to the login page if it detected connection problems for five seconds. With this new version, a lot is going on under the hood keep you connected to LibraryH3lp. When network conditions get dicey, this new version keeps trying to reconnect for up to five minutes; it sets your status to unavailable when it can't connect and it returns your status to available when you are connected again.

• Improved new message alerting. The new chat alert noise has been amplified a lot and should be louder now. We've switched to a new sound library as well. We hope that this will fix the sporadic reports of the sound konking out at random intervals during long, busy chat shifts. It behaves the same otherwise: when a brand new chat arrives, the sound repeats every few seconds until someone answers or the patron leaves, and when a patron sends a new message during an existing chat, the sound plays once.
  

• Improved buddy list. The buddy list will import buddy groups your account has set in other Jabber clients. This will make your contacts easier to find since they will be more consistent across clients. Within each group, it sorts your buddies alphabetically. It pre-expands all groups other than the offline group.

We've tested this version pretty carefully, but if you find that you have a problem with the new version and the old version worked OK for you, you can still use the old version at http://libraryh3lp.com/webchat2 If you're in that boat, please let us know. We would like to phase out the original client at some point.

Those are the basics, but we'd like to talk a bit more about two things.

First, what about other kinds of new message alerting besides sound? The original version of the webchat client already did everything possible to flash the window and title bar when new messages arrive. It's really not possible to make it reliably pop up a new window that will actually jump to the front of other applications when a new chat arrives. If we could do that, so could advertisers, and that wouldn't be good. This is the reason that web browsers are so restrictive for alerting features. If you're using a tabbed browser, and the webchat client is not the tab in front, and you have another application on top of the browser you're using for webchat, you won't see the window flash. But you should hear the alert noise if your sound is enabled.

Second, one of the leading causes of problems with staying connected in the webchat client is internal use of a proxy server. Now, we're not talking about harmless kinds of proxy servers like EZproxy, which seems nearly ubiquitous across libraries for providing remote access to licensed resources. We're talking about proxy servers used internally to boost network performance by doing things like caching. This release of the webchat client doesn't do any proxy server detection, but the next release might. If you're having problems staying connected in the webchat client, please read our detailed doc on this topic.