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.

Offline messaging on SMS and IM gateways

Offline messages just became enabled on gateways. This means that now, you'll receive messages sent by patrons who message your gateways when your queues are offline. You'll get these messages the next time an operator assigned to that queue signs in. This is especially important for the SMS gateway, since patrons texting you may not know your status, and since texting is more asychronous-communications friendly.

If you'd like to test our our SMS gateway, please let us know. We can temporarily add our G1's phone number to one of your queues as a gateway so you can see it in action.

Offline messages are also enabled for IM gateways. Most IM patrons won't message you when you're offline since your presence is plainly obvious, but if they do, you can reply now. If they happen to have gone offline in the meantime, they'll get your message when they return online.

Offline messages are *not* turned on for widget chats. Past experience with widgets that provide offline messaging led us to this. Patrons that chat an offline widget will navigate away before you reply in nearly all cases, so there is no reliable way to reply back to them. They almost never leave contact information. Patrons viewing your offline widgets will see "Chat is offline" and so typically won't chat. If they try anyway, they'll get "Chat is offline" in response to their first message. And if you're using the presence API to hide your widget when it's offline, patrons typically won't see your offline widgets anyway.

Enjoy!