Webchat client enhancements

<p>We just rolled out a new version of the <a href="http://libraryh3lp.com/webchat/">librarians' webchat client</a>. A rundown of the changes:<br /><ul><li><span style="font-weight: bold;">Improved ability to stay connected under various network conditions</span>. 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><span style="font-weight: bold;">Improved new message alerting</span>. 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.<br /></li></ul><ul><li><span style="font-weight: bold;">Improved buddy list</span>. 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 href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbdEABVBF4pcLAAo1eER48Akz8BqpMJWwvtZkY4FrTROnUfDpngk3JlPK4f0JsN41uN3hcwsuC3MGlY9xa9wRd3VIodsxhTPND3i2d0uaIqEwHHaLpAy8_SoeNOcId9-kYCfdT3XXP6dQ/s1600-h/webchat-blist.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><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><br /></div><br /><br />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.<br /><br />Those are the basics, but we'd like to talk a bit more about two things.<br /><br />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.<br /><br />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 <span style="font-weight: bold;">not </span>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.</p>

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

<p>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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />Enjoy!</p>

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

Widget tweaks

<p>As you might have noticed, we've recently pushed out a new version of the widget. Notable changes:<br /><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).<br /></li></ol>To run these down in more detail...<br /><br />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.<br /><br />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>.<br /><br />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.<br /><br />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.<br /><br />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:<br /><br /><span style="font-family:courier new;">#msg {</span><br /><span style="font-family:courier new;"> font-size: 12px;</span><br /><span style="font-family:courier new;">}</span><br /><br />As long as we're talking about CSS tweaks, here is boilerplate CSS for changing font style attributes overall:<br /><pre><span style="font-family:courier new;">#recv, #msg {</span><br /><span style="font-family:courier new;"> font-family: tahoma, verdana;</span><br /><span style="font-family:courier new;"> font-size: 12px;</span><br /><span style="font-family:courier new;">}</span><br /><span style="font-family:courier new;">#header h1 {</span><br /><span style="font-family:courier new;"> font-size: 15 px;</span><br /><span style="font-family:courier new;">font-family: tahoma, verdana;</span><br /><span style="font-family:courier new;">}</span><br /></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.<br /><br />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.)<br /><br />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.<br /><br />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.</p>

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

<p>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.<br /><br />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.<br /><br />You see, what is going on right now is that there are <span style="font-style: italic;">two</span> 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>.<br /><br />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.<br /><br />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.</p>

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

<p>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.<br /><br />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.<br /><br />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.<br /><br />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.</p>

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

<p>As mentioned in <a href="http://libraryh3lp.blogspot.com/2009/04/hierarchy-tree-view-and-permissions.html">this post</a> from last month, we've been working on read-only permissions for your users who aren't admins.<br /><br />Often, in the course of running a service, your librarians might need to locate an earlier transcript. Or, maybe you want to give other people the ability to run reports and read transcripts for quality control and training purposes <span style="font-weight: bold;">without </span>also giving them the ability to delete things or to mess around with your queues and user assignments.<br /><br />Your users now have read-only access to transcripts (Monitor Activity tab, Calendar page) and can run reports on ALL queues to which they are assigned. They can login at the regular <a href="http://libraryh3lp.com/">admin page</a> to do this work.<br /><br />Enjoy!</p>

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

<p>We just completed our Facebook Application, with help from Cliff Landis from Valdosta State University (thanks, Cliff!).<br /><br />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.<br /><br />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.<br /><br />Detailed documentation (larger view <a href="http://docs.google.com/Presentation?id=ddgrrvb8_135qqb4nffj">here</a>), with abundant screen shots:<br /><br /><iframe src="http://docs.google.com/EmbedSlideshow?docid=ddgrrvb8_135qqb4nffj" width="410" frameborder="0" height="342"></iframe><br /><br />Brief instructions, for those that don't want to watch the detailed version above:<br /><ol><li>Visit the <a href="http://www.facebook.com/apps/application.php?id=49894436853">app page</a>.<br /></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<br />corner. Pick Edit and then Allow.</li><li>Provide queue URL for your widget (it can be fully customized) and<br />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 <span style="font-weight: bold;">really</span> 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.<br /><br />With either approach, chat is one click away. Summary:<br /><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.<br /></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.<br /></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.<br /><br />Enjoy!</p>

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