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

Hierarchy, Tree View, and Permissions

<p>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>.<br /><br />To rundown the changes:<br /><br /><span style="font-weight: bold;">Tree View</span>, 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.<br /><br /><span style="font-weight: bold;">Has Admin Rights</span> 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.<br /><br />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 <span style="font-style: italic;">big-admin</span><span style="font-weight: bold;"> </span>registered with LibraryH3lp. <span style="font-style: italic;">Big-admin</span> can create users to act as admins of their own individual libraries at the university: <span style="font-style: italic;">main-library-admin</span>, <span style="font-style: italic;">law-library-admin</span>, <span style="font-style: italic;">health-library-admin</span>, etc... <span style="font-style: italic;">Big-admin</span> can create and assign queues to those mini-admins using Tree View, or the lower-level admins can create their own queues independently.<br /><br />When <span style="font-style: italic;">law-library-admin</span> 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.<br /><br />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.<br /><br />All of this can cascade through as many levels as you wish. As has always been the case, <span style="font-weight: bold;">ALL</span> operators <span style="font-weight: bold;">anywhere </span>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).<br /><br /><span style="font-weight: bold;">Things still to come: </span><br /><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.<br /></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.<br /></li></ul></p>

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