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.