2009 | Kang Bro Wiratma

Home > Archives for 2009

Admin site tweaks; HTTPS widgets; and Meebo/Adium news

Gosh, it's been a long time since our last blog post! This Fall, we were kept pretty busy with growing the system to keep pace with all-time-high levels of usage. We're happy that those efforts have been successful and things are currently stable and scale well. Several news items:<div><ul><li>Over the holidays, we pushed out an updated version of the Admin site. The main user-visible change is that now, you can resize the upper and lower panes in the Users, Queues, and Gateways panel. Previously, longer lists of gateways could be cut off on netbooks and lower-resolution wide screen displays. This should no longer be an issue. Long lists of users are also easier to manage, and the drag-and-drop functionality in Tree View is improved. Behind the scenes, the admin site underwent major code changes that make it easier to manage and update. Please let us know if you find bugs.</li><li>By popular request over on the <a href="http://groups.google.com/group/libraryh3lp">group</a>, secure widgets are working now, so anyone looking to integrate an embedded widget in a secure site (such as Illiad) should no longer be thwarted by mixed-content warnings in Internet Explorer.</li><strike><li>Now, the less-good news. As hopefully everyone <a href="http://libraryh3lp.blogspot.com/2009/09/pidgin-26x-houston-we-have-problem.html">knows</a>, recent versions of Pidgin no longer implement a part of the XMPP specification we need in order to properly end chats. We will eventually have a plugin to fix this problem in Pidgin. Additionally, the problem recently spread to Meebo, since it uses libpurple, the core part of Pidgin. Sadly, Meebo really is not a good choice for staffing LibraryH3lp queues at this time.</strike> In better news, we already have a handle on a solution that should allow Meebo and any Jabber client, even those that don't implement the needed chat state notification, to be suitable for monitoring queues. We'll update here when that is available. <strike>This problem will also spread to Adium when they publicly release version 1.4, so please do not upgrade to that version until we have our new solution in place.</strike> [edited 1/10/2010 because the upgraded routing is in place now, and all XMPP clients can now be used.] </li><li>[edited 1/1/2010 to clarify: Meebo Me gateways still work fine. The problem is with using the meebo.com website as the librarians' client for staffing the service.]</li></ul>We wish you all a very happy New Year!</div><div> </div>

Gosh, it's been a long time since our last blog post! This Fall, we were kept pretty busy with growing the system to keep pace with all...

Pidgin 2.6.x: Houston, we have a problem

Well, we have less-than-good news. We'll get straight to the point. <strike>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" <a href="http://xmpp.org/extensions/xep-0085.html">notification</a> 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 <a href="http://c0361712.cdn.cloudfiles.rackspacecloud.com/pidgin-2.5.9.exe">download it here</a>. Happily, you can just run the installer and it will keep all of your existing preferences and account information.<div> 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.</strike> [edited 1/10/2010 Any version of Pidgin, or any other XMPP client, can be used now. There is no longer a dependency on "gone" in the routing system] In happier external client news, the <a href="http://www.digsby.com/">Digsby</a> developers were <a href="http://forum.digsby.com/viewtopic.php?id=4024">very responsive</a> to a request to start sending the "gone" command. Digsby is now a <a href="http://libraryh3lp.com/docs/suitable-jabber-clients.html">suitable client</a> 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. </div>

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 m...

SMS Gateway (Android variety) updated

Back in March, we released the <a href="http://libraryh3lp.blogspot.com/2009/03/sms-gateway-released.html">first version</a> 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: <ol><li>Now, when you press the Start and Stop buttons, the phone displays feedback that the app actually started or stopped. </li><li>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.</li></ol>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.

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 mod...

Updates to queue selection feature

Last weekend, we released the <a href="http://libraryh3lp.blogspot.com/2009/08/new-librarians-webchat-client-features.html">queue selection feature</a> 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.<div> </div><div>This weekend, we tweaked queue selection in the webchat client a bit to address a couple of things:</div><div><ul><li>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.</li></ul><ul><li>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.</li></ul><div>We're addressing these situations in the following manner if the librarian is assigned by the admin to more than one queue:</div><div><ol><li>Upon login, the queue selection dialog is opened automatically.</li><li>The librarian will not receive any chats from queues.</li><li>Once the librarian has dismissed the queue selection dialog, they will be able to receive chats from queues.</li></ol><div>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.</div><div> </div><div>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.</div><div> </div><div>Now, what about queue selection on external clients, like Pidgin, Adium, and the Meebo website? This <a href="http://groups.google.com/group/libraryh3lp/browse_thread/thread/37b3b550e2fe622c">question</a> came up on the <a href="http://groups.google.com/group/libraryh3lp">Group</a> 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.</div><div> </div><div>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.</div><div> </div><div>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! </div><div> </div><div>This queue selection bot is not yet available. We'll blog about it when it is, probably in a few weeks time.</div></div></div>

Last weekend, we released the queue selection feature for the librarians' webchat client. It introduced a new button inside the client...

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<a href="http://github.com/esessoms"> Eric's github</a>; these particular features are part of the <a href="http://github.com/esessoms/webchat/tree/master">webchat</a> section. We'll be providing more detailed documentation later (we're tired), but to briefly run down the changes: <ul><li>Queue selection. When your librarians sign in using the <a href="http://libraryh3lp.com/webchat/">webchat client</a>, 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.</li></ul><div style="text-align: center;"> </div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDYF7vtqlJPLIKDvwx6D8Lm3nZqj-230T24VIAKuiPy6Dw2VBfy7HzjO8fOXW1YAw9Iioj4lgCu8ieoB1ehL2xSi-3tOo8MyVL4aH0-LKVwXLUQvS7m8wrdcsE8PlsfmBAVtKKtMZm6XU/s1600-h/queue-selection.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5373277970826809698" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDYF7vtqlJPLIKDvwx6D8Lm3nZqj-230T24VIAKuiPy6Dw2VBfy7HzjO8fOXW1YAw9Iioj4lgCu8ieoB1ehL2xSi-3tOo8MyVL4aH0-LKVwXLUQvS7m8wrdcsE8PlsfmBAVtKKtMZm6XU/s320/queue-selection.png" style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px; height: 206px;" /></a><ul><li>Profile pages. In the admin site, there is a new tab for <a href="http://libraryh3lp.com/docs/profile-pages.html">profile pages</a>. 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 href="http://libraryh3lp.com/images/profile-page-question-mark.png">a generic one</a>.</li></ul><ul><li>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.</li></ul><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmmrEbC57ODCaQpgeiHoa7kJs_Tr3pbJdfBQhyphenhyphenZym2UJVujbR0Gr1IPpz5sEBdJtdJWNDdvzG-gnQAgunVDUbMBPfR0_7nN8te2H7-Tq4WqWdoZgXaFa6YhQ7ou0v4cD9kIj3X96HUjOU/s1600-h/tag-for-followup.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5373280532878333490" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmmrEbC57ODCaQpgeiHoa7kJs_Tr3pbJdfBQhyphenhyphenZym2UJVujbR0Gr1IPpz5sEBdJtdJWNDdvzG-gnQAgunVDUbMBPfR0_7nN8te2H7-Tq4WqWdoZgXaFa6YhQ7ou0v4cD9kIj3X96HUjOU/s320/tag-for-followup.png" style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px; height: 218px;" /></a> 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.

Lots of new features for the librarians' webchat client installed this weekend! It's no accident that these latest things seem like ...

Google Voice SMS Gateway

We just installed our Google Voice gateway, and it's ready for testing.  You may know that  LibraryH3lp <a href="http://libraryh3lp.blogspot.com/2009/03/sms-gateway-released.html">already has an SMS gateway</a>, 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 <a href="http://libraryh3lp.blogspot.com/2009/07/offline-messaging-on-sms-and-im.html">offline</a> 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:<img alt="" border="0" id="BLOGGER_PHOTO_ID_5365898534950346850" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7xSG1VN6By38QQu4pXeQrwpDuNI4xsJRa7F15ETtzVwZDZTmeu9BsO-6M1Cm4G0vYUbWg1y3n02P2kMdBsrX5s5tpo1p1-8EKIzF5J-_AecLrU_FhxK-rLMrm7z4Sb53zLLDyE_DRYWE/s320/voice-gateway-char-countdown.png" style="cursor:pointer; cursor:hand;width: 320px; height: 248px;" /> 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 <a href="http://dossy.org/2007/10/character-counting-plugin-for-pidgin/">character count plugin for Pidgin</a> 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.

We just installed our Google Voice gateway, and it's ready for testing. You may know that LibraryH3lp already has an SMS gateway , one...

Show patron's IP and Referring URL

Besides the <a href="http://libraryh3lp.blogspot.com/2009/07/webchat-client-enhancements.html">new version of the webchat client</a>, we also pushed out two entirely new features today. Both of these features relate to patrons using the LibraryH3lp widget: <ul><li>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.</li></ul><ul><li>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.</li></ul><div style="text-align: left;">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: <div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi7JWLDYOdjxT8vKCno290lbdxBeC7gKOSkSikAD8WXjxVVnMOhcZF_3lMC-JtrPQrIfSls21llQjz99daZJZszPHicXTnrpCO70yTeEv59mu_fvSJ7J7eohC1U5w0IocXttDOMaE36Ws/s1600-h/webchat-vcard.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5357312063268430466" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi7JWLDYOdjxT8vKCno290lbdxBeC7gKOSkSikAD8WXjxVVnMOhcZF_3lMC-JtrPQrIfSls21llQjz99daZJZszPHicXTnrpCO70yTeEv59mu_fvSJ7J7eohC1U5w0IocXttDOMaE36Ws/s320/webchat-vcard.png" style="cursor: pointer; width: 320px; height: 100px;" /></a> <div style="text-align: left;">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: <div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh87GSBg-Fu5Jad8xzZ_HgGbetOnsDk_cB5hViIJM7JGvPvHkDlhHSXjulDhBy8XQW3w9xRq8A-DE7dKihGvrWPL7yOUbeLFY_uA4xDLpdo9-78fuZPZ2me7kUGnBCe3XlUb7vgXmzPYgc/s1600-h/pidgin-vcard.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5357312764232180962" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh87GSBg-Fu5Jad8xzZ_HgGbetOnsDk_cB5hViIJM7JGvPvHkDlhHSXjulDhBy8XQW3w9xRq8A-DE7dKihGvrWPL7yOUbeLFY_uA4xDLpdo9-78fuZPZ2me7kUGnBCe3XlUb7vgXmzPYgc/s320/pidgin-vcard.png" style="cursor: pointer; width: 320px; height: 125px;" /></a> </div> Or you can right-click on the relevant guest buddy in your buddy list (be sure to get the right one). <div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyvDxRu-lqWX2BA-41BqoM3rYC16z666GcK9BqponGGLwXSrzlb8L-x6blCxMeVEYuEPmTdcIwaTXxxU7fO33VG6UBXkFSIIQsi0UVOA6rGSuiIScHqR9yeHUNlN5f-jHflyUU7lJKg2Y/s1600-h/pidgin-vcard-blist.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5357993727547705538" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyvDxRu-lqWX2BA-41BqoM3rYC16z666GcK9BqponGGLwXSrzlb8L-x6blCxMeVEYuEPmTdcIwaTXxxU7fO33VG6UBXkFSIIQsi0UVOA6rGSuiIScHqR9yeHUNlN5f-jHflyUU7lJKg2Y/s320/pidgin-vcard-blist.png" style="cursor: pointer; width: 320px; height: 129px;" /></a> </div><div style="text-align: center;"> <div style="text-align: left;">A related feature, avatars for queues, is in the works... </div></div></div></div></div>

Besides the new version of the webchat client , we also pushed out two entirely new features today. Both of these features relate to patron...

Webchat client enhancements

We just rolled out a new version of the <a href="http://libraryh3lp.com/webchat/">librarians' webchat client</a>. A rundown of the changes: <ul><li>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.</li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbdEABVBF4pcLAAo1eER48Akz8BqpMJWwvtZkY4FrTROnUfDpngk3JlPK4f0JsN41uN3hcwsuC3MGlY9xa9wRd3VIodsxhTPND3i2d0uaIqEwHHaLpAy8_SoeNOcId9-kYCfdT3XXP6dQ/s1600-h/webchat-blist.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5357314084681098418" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbdEABVBF4pcLAAo1eER48Akz8BqpMJWwvtZkY4FrTROnUfDpngk3JlPK4f0JsN41uN3hcwsuC3MGlY9xa9wRd3VIodsxhTPND3i2d0uaIqEwHHaLpAy8_SoeNOcId9-kYCfdT3XXP6dQ/s320/webchat-blist.png" style="cursor: pointer; width: 233px; height: 170px;" /></a> </div> 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 <a href="http://libraryh3lp.com/docs/webchat-disconnects.html">our detailed doc</a> on this topic.

We just rolled out a new version of the librarians' webchat client . A rundown of the changes: Improved ability to stay connected under...

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 <a href="http://libraryh3lp.blogspot.com/2009/03/sms-gateway-released.html">SMS gateway</a>, 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!

Offline messages just became enabled on gateways. This means that now, you'll receive messages sent by patrons who message your gateway...

Widget tweaks

As you might have noticed, we've recently pushed out a new version of the widget. Notable changes: <ol><li>Improved sound feature.</li><li>New default English text for online widgets.</li><li>Widget is 30% of its original size, so it downloads even faster now.</li><li>Widget has real-time presence, except in older versions of IE.</li><li>Port 5280 no longer required for presence (good for restricted network environments). </li></ol>To run these down in more detail... 1) Sound. The previous sound solution behaved a little sloppily if you wanted to have sound on by default, and the patron's browser did not have Flash installed. It displayed an error message in that case, and that looked cosmetically untidy in narrow widgets. The new sound solution is backed by <a href="http://www.happyworm.com/jquery/jplayer/">jPlayer</a>, a jQuery plugin, and doesn't display any error messages if Flash is not installed. Sound-on-by-default is an option now in the Design Public Services wizard. If you prefer to do things by hand, it's explained <a href="http://libraryh3lp.com/docs/sound-on.html">here</a>, in the widget customization section of <a href="http://libraryh3lp.com/docs/">our docs</a>. 2) New default English text for online widgets. Formerly, this was, "Type here to chat." Now it is, "Type here to chat. Press ENTER to send." This change was made in response to usability tests done at a library testing LibraryH3lp a few months ago. They found that in their older demographic, pressing enter to send a message wasn't obvious to everyone. We hope this will help. We'd love to expand this change to the non-English translations as well. So, if you know how to say, "Press enter to send" in Czech, French, Chinese, Spanish (Europe), Spanish (Puerto Rico), or Russian, drop us a line. Now, this does mean that there is suddenly more text in that area. If your widget is really narrow and it doesn't look tidy, you can change the font size using CSS. The easiest way to do this is in the Design Public Services wizard area of the admin interface. Find the saved skin you're using for the widget in question, and paste something like the below in the Wicked CSS Hack area: #msg { font-size: 12px; } As long as we're talking about CSS tweaks, here is boilerplate CSS for changing font style attributes overall: <pre>#recv, #msg { font-family: tahoma, verdana; font-size: 12px; } #header h1 { font-size: 15 px; font-family: tahoma, verdana; } </pre>3) Widget is about 1/3rd of its original download size, thanks in part to new libraries, such as the new sound library and <a href="http://code.stanziq.com/strophe/">Strophe</a>, a BOSH library. 4) Widget has real-time presence in many browsers. This means that if a queue changes online/offline status while a patron is looking at its widget, the change will be immediate, rather than delayed by polling. (Note that polling is still required for the presence API -- we're only talking about presence on actual widgets here.) Alas, despite heroic efforts, we could not make real-time widget presence work in IE6 or IE7. Well, we could make it work, but not without unintended consequences that outweighed the benefits. 5) All presence calls are now on port 80 (standard HTTP port). Previously, port 5280 was also in use, and this didn't work in a few circumstances, such as some locked-down public wireless networks.

As you might have noticed, we've recently pushed out a new version of the widget. Notable changes: Improved sound feature. New default ...

Server Migration Status Update

We're about 90% done with the migration to the new server platform now. Everything is installed and running except for some "minor" parts of the admin interface (like reports... because, well, you don't need to be running reports on a Saturday anyway). Chat, webchat, queues, gateways, and all the features you need to staff a service are all good. But, we felt that we should post to explain some strangeness you might be seeing. It's possible to be logged in and see your gateways online, but a user visiting your web page might not see your widget, or might get notice that you're offline. You see, what is going on right now is that there are two distinct libraryh3lp servers, the old and the new. Both are working, but they are not talking to each other. (The old server will not be part of the cluster, it's just going away.) So, if you're logged into one server and your user is on another, you'll miss each other. Which server you are logged into is just an accident of <a href="http://en.wikipedia.org/wiki/Domain_Name_System">DNS</a> caching. If you logged in early this morning before we threw the switch, your machine is talking to the old server, and no amount of logging out and in again will get it to talk to the new server, because of <a href="http://en.wikipedia.org/wiki/Domain_Name_System#In_practice">caching</a>. The way to fix this is to just log out of libraryh3lp at the end of your shift, forget about it, go home, and your computer will load the new values from the DNS servers tomorrow morning. It's that easy, it's just not immediate. So that's where we stand right now. Because the new server is looking good, we'll be shutting down the old one sometime tonight, and once the DNS changes have had time to propagate throughout the internet, we'll all be running on the new server.

We're about 90% done with the migration to the new server platform now. Everything is installed and running except for some "minor...

The time has come...

As many of you know, LibraryH3lp has been growing rapidly. This is great! It also means that we've fairly well outgrown our current single-server architecture. Since the early planning stages, we knew that if LibraryH3lp became heavily-used, it would be best served by a multi-server setup, with clustering and load balancing. You can read all about it in <a href="http://journal.code4lib.org/articles/107">our Code4Lib article</a>. All of this planning means that we're ready to move, and we don't have to radically change too much code. Now that it's summer, and with a US holiday weekend on the horizon, we feel that the stars are aligned. We'll begin the migration in earnest this weekend. This will represent the initial conversion to the new platform. We always aim for minimal down-time around upgrades and maintenance windows, but this is a pretty big deal. We'll update our <a href="http://twitter.com/libraryh3lp">Twitter feed</a> along the way to keep y'all posted. We apologize in advance for any outages along the way, and we'll do our best to keep them brief.

As many of you know, LibraryH3lp has been growing rapidly. This is great! It also means that we've fairly well outgrown our current si...

Read-only permissions done

As mentioned in this post from last month, we've been working on read-only permissions for your users who aren't admins. Often, in ...

Facebook App

We just completed our Facebook Application, with help from Cliff Landis from Valdosta State University (thanks, Cliff!). As many of you know, the LibraryH3lp widget is composed mostly of JavaScript and runs in an iframe. Facebook does not allow iframes on Wall pages, and the space allocated to applications on Wall pages is pretty narrow to begin with. It's hard to follow a chat in a widget that is too small. So, our application shows the Facebook user your library's online or offline status, using images you provide. If you're online, clicking the image takes the user to your widget. Your widget is on a Facebook Canvas page, where iframes are A-OK, and where the widget is nice and roomy. Detailed documentation (larger view <a href="http://docs.google.com/Presentation?id=ddgrrvb8_135qqb4nffj">here</a>), with abundant screen shots: <iframe src="http://docs.google.com/EmbedSlideshow?docid=ddgrrvb8_135qqb4nffj" width="410" frameborder="0" height="342"></iframe> Brief instructions, for those that don't want to watch the detailed version above: <ol><li>Visit the <a href="http://www.facebook.com/apps/application.php?id=49894436853">app page</a>. </li><li>Click "Add to Page" button.</li><li>Navigate to the Page in question.</li><li>Click "Edit Page."</li><li>Find "LibraryH3lp" app and click little pencil icon in top right corner. Pick Edit and then Allow.</li><li>Provide queue URL for your widget (it can be fully customized) and online/offline images.</li><li>Click to Allow Constant Authorization.</li><li>App should be in your Boxes section now.</li><li>Move to Wall tab if desired.</li></ol>Now, if you really want your chat widget to be directly on your Wall page, you can still use a Meebo Me widget, but the user won't be able to tell if you're online or offline until they click. Meebo Me widgets are Flash applications. My wonderful colleague Chad Haefele long ago <a href="http://www.hiddenpeanuts.com/archives/2007/11/15/how-to-add-a-meebo-widget-to-a-facebook-page/">documented how to put Meebo Me widgets in Facebook</a>. You can gateway Meebo Me widgets into LibraryH3lp queues. With either approach, chat is one click away. Summary: <ol><li>With the LibraryH3lp app, the user can tell if you're online or offline with no clicking. If you're online, a click takes them to a separate page containing a nice big widget. </li><li>With the Meebo Me widget, the user has to click to see if you're online or offline, but then they chat directly from the Wall tab. Caveat: requires Flash, and widgets on the Wall tab will be very narrow, which can make the chat harder to follow. It is also possible to place a Meebo Me widget in its own tab, such as "IM Your Library," where space is not so tight. </li></ol>One more thing. Because the Facebook platform is really very locked down, we can only show visitors your presence on page load (no polling for presence changes). If you were online at their page load, and you go offline in the meantime, they'll see your newly-offline status on the widget page. If they try to chat anyway, they'll get "chat is offline" in response. Enjoy!

We just completed our Facebook Application, with help from Cliff Landis from Valdosta State University (thanks, Cliff!). As many of you know...

Hierarchy, Tree View, and Permissions

We've been working on a big new feature set: improved handling of different levels of hierarchy and permissions in the admin site. The first release, pushed out a day or two ago, provides a couple of important enhancements over the existing method, first explained by Eric in <a href="http://libraryh3lp.blogspot.com/2008/05/hierarchy.html">May of last year</a>. To rundown the changes: Tree View, found in the users/queues area, gives the admin a graphical display of their system's hierarchy. Admins can see what users own what queues, and they can assign users as owners of queues. Drag and drop works, too. You can switch back to the default display by clicking Flat View. Has Admin Rights is a checkbox that will appear when a user is selected. Ticking that checkbox will give the selected user admin rights at the same permissions level as his or her "boss" one level up in the hierarchy. Why would you want to do this? Let's say you work at a large university, with several libraries. You have a top-level account called big-admin registered with LibraryH3lp. Big-admin can create users to act as admins of their own individual libraries at the university: main-library-admin, law-library-admin, health-library-admin, etc... Big-admin can create and assign queues to those mini-admins using Tree View, or the lower-level admins can create their own queues independently. When law-library-admin logs into the admin site, they will only see queues that they themselves own, and they can create their own users to assign to their queues. They may also wish to share the task of running the chat system in the Law Library by assigning admin rights to one of their own users. This will grant that user the same permissions that they themselves have. This is also a good way to build a collaborative service spanning multiple institutions. If you have existing top-level admin sites that you'd like to put together, let us know, and we can do that manually. All of this can cascade through as many levels as you wish. As has always been the case, ALL operators anywhere in the hierarchy can transfer chats and IMs on queues to any other queue or operator within the same administrative domain (starting from the top-most level). Things still to come: <ul><li>Read-only access to reports and transcripts for ALL users on the queues to which they are assigned.</li><li>Write access to the transcripts/Monitor Activity area for "mini-admins" granted rights with the "has admin rights" function. </li><li>Way for top-level admins to connect with other top-level admins in order to merge admin domains with no intervention from us. </li></ul>

We've been working on a big new feature set: improved handling of different levels of hierarchy and permissions in the admin site. The ...

SMS Gateway Released

We've just completed our first SMS gateway (with some help from Ron DuPlain at <a href="http://espresso-labs.com/">Espresso Labs</a>). We've been thinking about and working on this for <a href="http://libraryh3lp.blogspot.com/2008/11/sms-texting-services.html">awhile now</a>. The main thing we wanted in our gateway was the ability for patrons to text their library at a real phone number, as opposed to using a shortcode technique such as the AIM hack. We have been able to achieve this goal by working with Google's Android phone (T-Mobile G1). Since it has an open architecture and allows applications to run in the background, Eric has been able to write an application that is installed directly on the phone. The application intercepts SMS messages sent to the phone and redirects them to a LibraryH3lp queue, where they are then delivered just like other IMs on the system. We like a few things about this: <ol><li>Patrons text a phone number and don't need to remember any shortcode tricks.</li><li>Libraries are fully responsible for their phone and texting package, which means...</li><li>LibraryH3lp fees do not need to increase one bit. This is just another gateway.</li><li>The phone's mobile number can be redirected to another line, such as a reference desk line, for voice communications, in case someone tries to call it rather than text it.</li><li>If you staff your service with our web client, you get a <a href="http://libraryh3lp.blogspot.com/2009/03/countdown.html">character countdown</a> when replying to texts, which is helpful in reducing the number of messages sent. (A long message will be broken down and sent as multiple SMS messages.) </li></ol>Of course, libraries will need to secure the phone and make sure it doesn't run out of power. We believe the application works well, but this is our beta release. Currently, text messages sent when a gateway's queue is offline will not be delivered; these offline messages will get delivered soon, after a bit more work. The application is available for free in the Android Market now. <div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyvRtkazLqHSmY0nKM9jf66vMuGs6J9V08OOtTce7Ed8XlJpKpUbJDvaDYM2gtaX6RBLeT6MpE_UT00xRMPB-3aiVy2wy-v-itqQ_OfmDmDw3RTPddwbpEWBwEdOv97GjqkgGHAtcLpCU/s1600-h/sms-gateway.jpg"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5313568756704404946" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyvRtkazLqHSmY0nKM9jf66vMuGs6J9V08OOtTce7Ed8XlJpKpUbJDvaDYM2gtaX6RBLeT6MpE_UT00xRMPB-3aiVy2wy-v-itqQ_OfmDmDw3RTPddwbpEWBwEdOv97GjqkgGHAtcLpCU/s320/sms-gateway.jpg" style="cursor: pointer; width: 320px; height: 230px;" /></a> </div> To setup an SMS gateway, start by installing the LibraryH3lp application on your G1. Go to the menu, click Settings, and give it a password (which can be anything). Then, go to the LibraryH3lp admin web site to define the gateway. This step is just like setting up any other gateway, just choose "sms", enter your ten-digit phone number as the username, and give it the same password you gave the phone. Finally, go back to your phone and click the "Start" button, and you're ready to start texting. Source code freely available on <a href="http://github.com/esessoms">Eric's Github</a>. The code will work with any Jabber server; it is not LibraryH3lp-specific.

We've just completed our first SMS gateway (with some help from Ron DuPlain at Espresso Labs ). We've been thinking about and worki...

Countdown!

There are a few unique challenges associated with trying to integrate a texting (SMS) service into an IM/chat reference workflow. Two of them are: <ol><li>Attempting to keep responses relatively short. SMS tops out at 160 7-bit characters or 140 8-bit characters. </li><li>Training librarians to notice when they have an SMS patron in the first place.</li></ol>Messages in excess of the character limits will be automatically split up into multiple messages, so going over the limit is not the end of the world, but SMS conversations flow more nicely if the librarian has an awareness of the limitations. Eric just added a nifty feature to the webchat client to help out with patrons sending messages from cell phones. <div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWUhmoic8p0V5fx1Mtvphrhgo3q2ApiPkZtAevKzZtym54IRx9mTvFmj200sw_5tVyUV9uRUYJe8rcVbrrGW4A6rY9_f6JkW4myaK6qx3t5MXaxm7HUGwgOHlJHDtJ60WALFSaZyTc6Zg/s1600-h/sms-character-countdown.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5308740486977204450" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWUhmoic8p0V5fx1Mtvphrhgo3q2ApiPkZtAevKzZtym54IRx9mTvFmj200sw_5tVyUV9uRUYJe8rcVbrrGW4A6rY9_f6JkW4myaK6qx3t5MXaxm7HUGwgOHlJHDtJ60WALFSaZyTc6Zg/s320/sms-character-countdown.png" style="cursor: pointer; width: 320px; height: 259px;" /></a> </div> When the librarian begins composing a message, a character countdown starting at 140 begins displaying in the top right corner of the window. You can also see from the normal routing information displayed in the top left corner that the patron is on a phone and contacted the pamq queue. If this wasn't a goofy test chat, you could have seen that they contacted your special reference queue, or your SMS queue, or whatever you've setup. [edited to add: The webchat client automatically detects phone numbers and applies the countdown display only then. It will not display with routine chats and IMs.] We're working on a new kind of SMS gateway, one that will let a patron text a phone number rather than using a short code like with the AIM hack. More news on that as it happens...

There are a few unique challenges associated with trying to integrate a texting (SMS) service into an IM/chat reference workflow. Two of th...

Meebo.com: new suitable jabber client

We don't usually update the blog when we change the <a href="http://code.google.com/p/libraryh3lp/wiki/SuitableJabberClients">documentation</a>, but this one is very exciting! It's now safe to monitor LibraryH3lp queues using the meebo.com website as the librarians' client. What happened? Did we pay them money? Negotiate with them in some way? Nope. All that has changed is that Meebo now more fully complies with <a href="http://www.xmpp.org/extensions/xep-0085.html">XEP-0085</a>, the Jabber standard that describes sending chat state notifications. In plain English, this means that Meebo's server will notify the LibraryH3lp server when librarians do things like close windows and sign out. The result is that patrons who begin a chat with Librarian A will not get lost in the ether if they go silent during a chat, and in the meantime, Librarian A signs off and Librarian B signs on. Now, Meebo.com won't have LibraryH3lp's special features like transfer, send file, and e-mail transcript integrated right into each chat window like our <a href="http://libraryh3lp.com/webchat">native librarians' webchat client</a> does. To do those extra things from Meebo, you'll have to follow the "chat management" link that starts each chat and sign into the LibraryH3lp server directly. You may also have other concerns with Meebo (ads, privacy), but it will work from a technical point of view. To sign in, simply use the Jabber login, with the lightbulb icon. The format for the login is username@libraryh3lp.com. Be sure to officially sign off, rather than just closing its browser window to end a shift, and you're good to go. It works with the Meebo Firefox plugin as well as the website. Hooray!

We don't usually update the blog when we change the documentation , but this one is very exciting! It's now safe to monitor Library...

Growing Pains

As many of you know, LibraryH3lp crashed last night. It was up again within minutes of our discovering it was down, but it's been so st...

New Reports Features

In the admin interface, you'll find the View Reports tab has been improved. You can pick one, some, or all queues and get a chart and a CSV file of activity for any date range. There are also some handy controls for all reports: <ol><li>Ignore system messages. System messages typically come from your gateways. They might say things like, "two unread messages" if the Gmail account for your Google Talk gateway has unread mail, or they might alert you that your AIM account was been signed in from another location. </li><li>Ignore not answered. These are primarily cases where your patrons return to say "thanks" or "bye" after the librarian has closed their own window. Of course, they may also represent chats that truly were not answered because the patron left before a librarian answered (hopefully there aren't a lot of these on your queues).</li><li>Minimum chat duration. Use this to set the minimum threshold for how long a chat must last in order for it to register in your report. It defaults to 10 seconds. This lets you weed out, for example, chats where your patron returned with a "thanks" message and your librarian quickly fired off a "you're welcome" in return.</li></ol>In the case of the first two options, you probably don't want to count those as chats in your reports. In the case of the third, it may not be possible set the perfect threshold, but being able to set a minimum duration is quite helpful. In less-busy services, you can weed through your transcripts in the Monitor Activity tab and delete records of chats you don't want to count. Then you can run your reports on everything that is left, but this may become less practical with busier services. Here is an example of a chart; we're using the Google Charts API, so you can create a permalink. This chart shows traffic by month and by protocol for most of UNC-Chapel Hill's queues for May 2008 through today: <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://chart.apis.google.com/chart?chs=600x400&chd=e:GRKbK8W-rdwkxuZqmBaf,DEGJGBE7KLLpNYGhGBFH,AIAQAMAMAUAkAcAMAYAI,AAAAAIAMAQAIAYAYAEAQ,AEAIAAAgAAAIAEAYAMAQ,AAAAAAAIAAAEAAAAAAAA&chco=000000,FF0000,00FF00,0000FF,00FFFF,FF00FF&chdl=web%7Caim%7Cyahoo%7Cgtalk%7Cmsn%7Cjabber&chxl=0:%7C0%7C20%7C40%7C60%7C80%7C100%7C120%7C140%7C160%7C180%7C200%7C220%7C240%7C260%7C280%7C300%7C320%7C340%7C360%7C380%7C400%7C420%7C440%7C460%7C480%7C500%7C520%7C540%7C560%7C580%7C600%7C620%7C640%7C660%7C680%7C700%7C720%7C740%7C760%7C780%7C800%7C820%7C840%7C860%7C880%7C900%7C920%7C940%7C960%7C980%7C1000%7C1:%7C5%2f08%7C6%2f08%7C7%2f08%7C8%2f08%7C9%2f08%7C10%2f08%7C11%2f08%7C12%2f08%7C1%2f09%7C2%2f09&chxt=y,x&cht=bvs"><img alt="" border="0" src="http://chart.apis.google.com/chart?chs=600x400&chd=e:GRKbK8W-rdwkxuZqmBaf,DEGJGBE7KLLpNYGhGBFH,AIAQAMAMAUAkAcAMAYAI,AAAAAIAMAQAIAYAYAEAQ,AEAIAAAgAAAIAEAYAMAQ,AAAAAAAIAAAEAAAAAAAA&chco=000000,FF0000,00FF00,0000FF,00FFFF,FF00FF&chdl=web%7Caim%7Cyahoo%7Cgtalk%7Cmsn%7Cjabber&chxl=0:%7C0%7C20%7C40%7C60%7C80%7C100%7C120%7C140%7C160%7C180%7C200%7C220%7C240%7C260%7C280%7C300%7C320%7C340%7C360%7C380%7C400%7C420%7C440%7C460%7C480%7C500%7C520%7C540%7C560%7C580%7C600%7C620%7C640%7C660%7C680%7C700%7C720%7C740%7C760%7C780%7C800%7C820%7C840%7C860%7C880%7C900%7C920%7C940%7C960%7C980%7C1000%7C1:%7C5%2f08%7C6%2f08%7C7%2f08%7C8%2f08%7C9%2f08%7C10%2f08%7C11%2f08%7C12%2f08%7C1%2f09%7C2%2f09&chxt=y,x&cht=bvs" style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 600px; height: 400px;" /></a> I can also download a CSV to bring the numbers into Excel; in the Reports interface, there is also a visualization tool kind of like a tag cloud, but without the tags: <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxlhQKBMHm9UD1-isEPS0up7AID9GS-WPS-d7rJDn4RzZFfbMq0bdG5s3CzvPSGTPpL3h1aeHYJFZ8e15DqaWrDEmwwhI_zmI2F9ts3qhj7oQRsaPw-fX_3lPEOXKzCxfMgKPqKTljJnQ/s1600-h/csv.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5303142412222450498" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxlhQKBMHm9UD1-isEPS0up7AID9GS-WPS-d7rJDn4RzZFfbMq0bdG5s3CzvPSGTPpL3h1aeHYJFZ8e15DqaWrDEmwwhI_zmI2F9ts3qhj7oQRsaPw-fX_3lPEOXKzCxfMgKPqKTljJnQ/s320/csv.png" style="cursor: pointer; width: 320px; height: 178px;" /></a> Remember: Besides this View Reports tab, you can also use the Monitor Activity tab to review transcripts, download transcripts in bulk, download a CSV file of all activity, delete system messages, delete transcripts, delete entire call histories. Use the Calendar Page link to perform these actions over select queues and date ranges. Note: the information in Reports will normally be up to 24 hours old because of database caching. The information in Monitor Activity is accurate up-to-the-second. Have fun!

In the admin interface, you'll find the View Reports tab has been improved. You can pick one, some, or all queues and get a chart and ...

Hardening the Gateways

This weekend, we installed a big enhancement to the gateway system. All of the protocols besides Google Talk have been on libpurple. Before today, we ran one instance of libpurple for all of the non-gtalk protocols (AIM, Yahoo!, MSN, ICQ), and that was fine until fairly recently. With hundreds of gateways active on LibraryH3lp nowadays, libpurple performance was taking a hit. So, Eric had broken the libpurple protocols apart so that now, each protocol has its very own instance of libpurple. This should mean a number of good things: <ol><li>Performance should improve now that no single libpurple instance is running so many gateways.</li><li>When a protocol change at the source (like MSN) means that a gateway needs programming work, we can just go ahead and work on it right away without worrying about disrupting the other gateways.</li><li>When a gateway is having some problem, we can restart it independently from the others. Restarts aren't a big deal, but they do cause accounts to briefly flicker offline and online again.</li></ol>Our libpurple gateway system has been open-sourced for a good while now, and this latest release has been updated at <a href="http://github.com/esessoms/purplegw/">Eric's github</a>. Happy Valentine's Day!

This weekend, we installed a big enhancement to the gateway system. All of the protocols besides Google Talk have been on libpurple. Befor...

... but what does it do?!

A couple of colleagues commented to me that during a recent conference, there were some questions about LibraryH3lp's features. It'...

Quick PSA: AIM FishBots

If you offer an AIM service, you should definitely read Nixie Pixel's article, " The AIM FishBot Phenomenon ." This explains ...

We're One Year Old Today!

Today marks LibraryH3lp's first birthday, as measured from the <a href="http://libraryh3lp.blogspot.com/2008/01/call-for-testers.html">start of this blog</a>, which announced our intentions with the system and asked for testers. It's been a fantastic, if busy year, and a number of exciting things have come to pass. Besides adding lots of features mentioned elsewhere in the blog, there are a few other things worth mentioning. <ul><li>Self-sufficiency. When we started, we knew we didn't want to have advertisements or data mining in order to generate revenue to pay for hosting; there was no grant source, venture capital, or investor other than Eric's small business. That left us with the idea of a <a href="http://code.google.com/p/libraryh3lp/wiki/Free_or_Fee_Full_Disclosure">nominal subscription fee</a>, since we could not afford to fund LibraryH3lp out of pocket indefinitely. A number of our busiest libraries have already stepped up and contributed with their subscription (thank you!). At this point, the system's current hosting fees are covered. Now, programming time is still mostly donated, with a very exciting exception in the form of...</li></ul><ul><li>Support from the state of North Carolina towards development of features needed by larger collaborative services. That's right, NC is funding some actual feature development (i.e., programming time), which is very much appreciated. So far, the main thing to show for this is the <a href="https://libraryh3lp.com/webchat">librarians' webchat client</a>. More reports, tag-for-followup, profile pages, and access-control lists are among funded features still to come. North Carolina, our home state, has always been good to us. After all, it was the freedom to experiment with, and the <a href="http://journal.code4lib.org/articles/107">technical challenges involved in</a>, chat and IM services at Duke University, North Carolina State University, and UNC-Chapel Hill that led to the development of LibraryH3lp in the first place. </li></ul><ul><li>It's just working. Knock on wood, the system has been pleasantly stable and generally operates at very low load. We've had less than five minutes of downtime in the last three months. LibraryH3lp was engineered from the ground up for scalability and stability, and this has paid off.</li></ul><ul><li>Our first corporate partnership. <a href="http://www.google.com/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fwww.altarama.com%2Frefchatter.htm&ei=bhx1SeG6LKKBtwf2uYzlCA&usg=AFQjCNEocShRlZhrcL1tAPLi-3zwCF7qMA&sig2=pqpbdqqo06yECEVudDLsmQ">Altarama's RefChatter</a> product remains available for those who require professional support, setup, and training. Options are good.</li></ul>But perhaps the most exciting thing for us has been witnessing the rate of adoption and the subsequent high use the system is receiving. At the peak of the Fall academic semester last October and November, there were about 600 chats and IMs on queues and probably about the same number in direct chats each day. We love to see that the system is getting put to good use. One small request: if you're using LibraryH3lp, please consider listing your library in the <a href="http://www.libsuccess.org/index.php?title=Online_Reference#Libraries_Using_libraryh3lp_for_Embedded_Chat">Library Success Wiki</a>. We occasionally are asked for a list of users, and because of our views on privacy, we don't share this information, but we love being able to point folks who ask to a user-generated list. Thank you for your support, and we look forward to this year!

Today marks LibraryH3lp's first birthday, as measured from the start of this blog , which announced our intentions with the system and a...

Kang Bro Wiratma