The last big news item for this weekend's release is the new "Web 2.0"-style popups. These aren't real popups that live in new browser windows, but are instead fake popups that are integrated into the host web page (but can still be moved and resized, and otherwise treated by the user like real windows). Why? They're there for continuity, because these new popups can follow the patron throughout a chat session, even off of your site.
See the movie.
To get these new popups, you only have to make one small change to your existing setup. If you're displaying presence and invoking popups using the "Easy Way" (documented here), you just change the javascript include line that ends with:
libraryh3lp.com?presence
to read:
libraryh3lp.com?presence,popup
That's it. Really.
There are still some rough edges that we'll be ironing out over the next few weeks, but I think it's a really cool feature so I wanted to get it out there for you to start playing with.
For the code-mongers among you, I'll be putting together a new source download in the next week or so. I'm on the road this week visiting my telescope, but I'll try to take care of things as soon as I get back. I'll post when the download is available, so you don't have to keep checking the wiki.
Sunday, March 30, 2008
Really Real-Time Presence: We Need Your Feedback
Another feature released this weekend is what we're calling "really real-time presence" (rrtp). RRTP means that presence is determined in real-time rather than being checked for by polling every 30, 60, or however many seconds. Currently, rrtp is enabled for embedded widgets but not for buttons or links that create pop-up widgets.
Here is where you come in. We'd like your feedback on the desirability of rrtp. From where we sit, the good is obvious: real-time presence is useful since it means your patrons will never be presented with an incorrect presence status, even for just a few seconds. It is also significantly less load on the server to do rrtp than polling.
The less-than-good is that in many browsers, it results in a web page that always appears to be loading. For instance, if you're reading this post on the libraryh3lp blog, you can see it in action right now. If you're in Firefox, you'll see the little round cluster of dots in the upper-right corner spinning, and at the very bottom, Firefox is telling us, "Transferring data from libraryh3lp.com..." IE 6 does not have any indication that rrtp is happening, but it still works. Safari presents a half-filled URL bar to indicate the ongoing page-load.
If a user gets annoyed by the appearance of constant page-load, they can click "stop," and the browser will cease with rrtp. That user can still chat successfully (assuming the widget's presence does not switch to offline in the meantime) but they will not get updated presence information after they click "stop."
So, the current compromise is to have rrtp for embedded widgets but not for objects that spawn pop-ups. The thinking here is that embedded widgets are probably only on a few pages, where chat is central to the page itself. Pages with buttons or links that spawn pop-ups are more likely to be implemented across many pages on a website (embedded in a catalog, for instance), and chat may be only tangential, so it might not be worth the browser disruption in those cases. Pop-up chats themselves have rrtp.
Let us know what you think. Should rrtp happen:
Here is where you come in. We'd like your feedback on the desirability of rrtp. From where we sit, the good is obvious: real-time presence is useful since it means your patrons will never be presented with an incorrect presence status, even for just a few seconds. It is also significantly less load on the server to do rrtp than polling.
The less-than-good is that in many browsers, it results in a web page that always appears to be loading. For instance, if you're reading this post on the libraryh3lp blog, you can see it in action right now. If you're in Firefox, you'll see the little round cluster of dots in the upper-right corner spinning, and at the very bottom, Firefox is telling us, "Transferring data from libraryh3lp.com..." IE 6 does not have any indication that rrtp is happening, but it still works. Safari presents a half-filled URL bar to indicate the ongoing page-load.
If a user gets annoyed by the appearance of constant page-load, they can click "stop," and the browser will cease with rrtp. That user can still chat successfully (assuming the widget's presence does not switch to offline in the meantime) but they will not get updated presence information after they click "stop."
So, the current compromise is to have rrtp for embedded widgets but not for objects that spawn pop-ups. The thinking here is that embedded widgets are probably only on a few pages, where chat is central to the page itself. Pages with buttons or links that spawn pop-ups are more likely to be implemented across many pages on a website (embedded in a catalog, for instance), and chat may be only tangential, so it might not be worth the browser disruption in those cases. Pop-up chats themselves have rrtp.
Let us know what you think. Should rrtp happen:
- all the time, for both pages with embedded widgets and pages with links to pop-up widgets?
- like it is now, only for pages with embedded widgets, but not for pages with links to pop-ups?
- never, the browser display stuff is a show-stopper?
- other?
SSL for Admin Interface
On Saturday, we installed an SSL certificate on libraryh3lp.com's admin interface. This means that all of the stuff you do when you're working with the admin piece, like creating passwords and entering credentials for the IM gateways, will be encrypted now. You don't need to do anything special like visiting https://libraryh3lp.com/. If you visit http://libraryh3lp.com/, you'll get redirected to the secure, encrypted version automatically.
Now, web chats are not automatically encrypted. However, if you're using the web chat on a website that is already secure, and you don't want web browsers complaining about mixed content, you can specify https in the path to your chat URL:
Now, web chats are not automatically encrypted. However, if you're using the web chat on a website that is already secure, and you don't want web browsers complaining about mixed content, you can specify https in the path to your chat URL:
https://libraryh3lp.com/chat/queuename@chat.libraryh3lp.com
Let us know of questions!
Friday, March 28, 2008
Planned Downtime This Weekend
We'll be doing a fair bit of in-depth stuff to the server during the mornings (EST) this Saturday and possibly Sunday as well. While we'll keep the downtime to a minimum, just be aware that the service might be up and down while we tinker. Have a great weekend, everyone!
Sunday, March 16, 2008
Of Subject Experts and Generalists:Two-Tiered Service Models
A few recent discussions with my colleagues and some interactions with patrons have me thinking a lot lately about the roles of the subject expert and the generalist in library chat services. Many of us librarians are experts in a few areas and generalists in many. Sometimes, questions really need a subject expert and really, no one else will be able to help. Other times, sure, a subject expert might give the quickest and deepest response, but the patron will probably also get very good help from one of a few librarians available. Yet other times, simply connecting to the generalists will be absolutely fine, perhaps with a case for later referral to a subject expert.
A lot of academic libraries are developing really nice, detailed subject guides and course pages currently. These typically have contact information for a subject expert at least and often will also contain contact information for a reference department or some other general help line for when that subject specialist is not immediately available.
This brings us to libraryh3lp's Presence API. With embedded chat widgets, it's very common practice to just show the widget and let the built-in presence indicator show the user whether the librarian is online or offline. Now, in the case where a subject expert is preferred, but a generalist will probably be able to help as well, we can create a new case: If the subject expert is online, show their widget, but if the subject expert is offline, show this other widget for the general reference desk.
Blogger is rather limiting in display of code chunks, but there are a couple of code examples on the wiki.
Going a bit further, and thinking of libraryh3lp queues, it would be possible to have queues for various areas of subject expertise, with or without rollover to a more generalist service when the experts are not available. Let's say I create a queue for help with business research, and I add two librarians to that queue. If at least one of those librarians is online, they'll get the questions from that queue. If neither of them is online, those questions can go to the general reference desk, where someone might still be able to help. If an area is extremely specialized, perhaps rolling over to the generalist service is not appropriate, and something else happens when the experts' queue is offline (e-mail form, chat widget does not display, etc).
This might be a good time to mention that one of the next features Eric is working on writing is chat transfer. The ability to transfer a chat---or IM---to another libraryh3lp queue will be very nice for appropriate referral of questions. ETA on that feature: 2-4 weeks.
A lot of academic libraries are developing really nice, detailed subject guides and course pages currently. These typically have contact information for a subject expert at least and often will also contain contact information for a reference department or some other general help line for when that subject specialist is not immediately available.
This brings us to libraryh3lp's Presence API. With embedded chat widgets, it's very common practice to just show the widget and let the built-in presence indicator show the user whether the librarian is online or offline. Now, in the case where a subject expert is preferred, but a generalist will probably be able to help as well, we can create a new case: If the subject expert is online, show their widget, but if the subject expert is offline, show this other widget for the general reference desk.
Blogger is rather limiting in display of code chunks, but there are a couple of code examples on the wiki.
Going a bit further, and thinking of libraryh3lp queues, it would be possible to have queues for various areas of subject expertise, with or without rollover to a more generalist service when the experts are not available. Let's say I create a queue for help with business research, and I add two librarians to that queue. If at least one of those librarians is online, they'll get the questions from that queue. If neither of them is online, those questions can go to the general reference desk, where someone might still be able to help. If an area is extremely specialized, perhaps rolling over to the generalist service is not appropriate, and something else happens when the experts' queue is offline (e-mail form, chat widget does not display, etc).
This might be a good time to mention that one of the next features Eric is working on writing is chat transfer. The ability to transfer a chat---or IM---to another libraryh3lp queue will be very nice for appropriate referral of questions. ETA on that feature: 2-4 weeks.
More Gateway Goodness
This morning we put into production gateways to MSN and Yahoo chat protocols, to round out the Big 3. And of course all chats---both web chats and IM, regardless of origin---go into the routing system, meaning you can have unlimited patrons talking to unlimited librarians via one simple public point-of-contact.
Sunday, March 9, 2008
AIM Gateway Released for Testing
This weekend, we released the AIM Gateway for public testing (Yahoo! and MSN gateways should follow soon). What does this mean in practice? The IM gateways work with libraryh3lp queues to centralize a library's web chat and IM services. This means that librarian operators can receive patron web chats and AIM IMs through their own libraryh3lp Jabber account. Everything is centrally funneled through the libraryh3lp server.
Once an AIM account is in place as a gateway, the AIM should not be signed into directly when any associated libraryh3lp operator is signed in. If an associated librarian operator is signed in with their regular libraryh3lp jabber account, that will cause the AIM account to be online, and a direct login to the AIM account will cause a message that the account is signed in from multiple locations.
With an AIM gateway in place, patrons will contact the library's familiar public AIM account using their regular AIM client, and the librarian will receive the IM through their Jabber client using their libraryh3lp account. Note that the librarian operator does NOT need to do anything special in order to receive the library's AIM messages. Further, if a patron already has a library's public AIM identity in their buddy list, that will continue to display as normal, and it will go on and offline when librarian operators with rights to the relevant queue sign in and out of their libraryh3lp accounts.
Since all of the chat and IM traffic for a queue is centrally managed, librarian operators can come and go in shifts without disrupting each others' work. When there are zero operators for any given queue signed in, that queue and AIM identity will switch to offline status. They will go back to online status when at least one operator signs in again.
Let's look at an example. Memorial Library has an admin account called memorial-admin. Memorial-admin created a libraryh3lp queue called memorial-library and they would like to include an AIM account called m3morial. They have two librarian operator accounts that monitor their chat and IM services: Sally (sally-memorial-lib) and Ed (ed-memorial-lib). Their queue's web chat widget is at the following URL, and they can embed this in other web pages, make pop-ups, etc:
http://libraryh3lp.com/chat/memorial-library@chat.libraryh3lp.com
With the AIM gateway, they can now integrate their AIM account with this queue. In the libraryh3lp.com admin web interface, after creating their queue, they will select "my gateways," and list the AIM account name (m3morial) and password.
Now, when either of the librarian operators signs into their libraryh3lp operator account in their Jabber client, the library's AIM account m3morial will come online as will their web chat widget.
If two librarian operators are signed in at the same time, they will both get patron IMs (and web chats), but only the first to type will become connected with the patron.
We've made a few screencasts (Flash required) to help illustrate many parts of libraryh3lp:
Once an AIM account is in place as a gateway, the AIM should not be signed into directly when any associated libraryh3lp operator is signed in. If an associated librarian operator is signed in with their regular libraryh3lp jabber account, that will cause the AIM account to be online, and a direct login to the AIM account will cause a message that the account is signed in from multiple locations.
With an AIM gateway in place, patrons will contact the library's familiar public AIM account using their regular AIM client, and the librarian will receive the IM through their Jabber client using their libraryh3lp account. Note that the librarian operator does NOT need to do anything special in order to receive the library's AIM messages. Further, if a patron already has a library's public AIM identity in their buddy list, that will continue to display as normal, and it will go on and offline when librarian operators with rights to the relevant queue sign in and out of their libraryh3lp accounts.
Since all of the chat and IM traffic for a queue is centrally managed, librarian operators can come and go in shifts without disrupting each others' work. When there are zero operators for any given queue signed in, that queue and AIM identity will switch to offline status. They will go back to online status when at least one operator signs in again.
Let's look at an example. Memorial Library has an admin account called memorial-admin. Memorial-admin created a libraryh3lp queue called memorial-library and they would like to include an AIM account called m3morial. They have two librarian operator accounts that monitor their chat and IM services: Sally (sally-memorial-lib) and Ed (ed-memorial-lib). Their queue's web chat widget is at the following URL, and they can embed this in other web pages, make pop-ups, etc:
http://libraryh3lp.com/chat/memorial-library@chat.libraryh3lp.com
With the AIM gateway, they can now integrate their AIM account with this queue. In the libraryh3lp.com admin web interface, after creating their queue, they will select "my gateways," and list the AIM account name (m3morial) and password.
Now, when either of the librarian operators signs into their libraryh3lp operator account in their Jabber client, the library's AIM account m3morial will come online as will their web chat widget.
If two librarian operators are signed in at the same time, they will both get patron IMs (and web chats), but only the first to type will become connected with the patron.
We've made a few screencasts (Flash required) to help illustrate many parts of libraryh3lp:
- Example site setup. Shows admin account registration, user (librarian operator account) creation, queue creation, and AIM gateway creation. (1:42; 1.7 MB)
- Example widget creation and librarian client setup. Basic chat widget implementation in simple HTML page. Widget is offline until librarian operator signs in to monitor it in Pidgin client. (1:55; 1.8 MB)
- AIM conversation example. Reviews AIM gateway in admin interface. Shows AIM patron in Pidgin having conversation with librarian operator in Psi. Note that patron does not need Pidgin; it was just convenient for testing. (2:31; 3.4 MB)
- Presence changes. Illustrates widget and AIM buddy online/offline presence changes while librarian operator signs in and out of Psi client. (0:45; 745 kB)
- Multiple operators. Illustrates a patron arriving through a chat widget asking a question when two librarian operators are online for that queue. One librarian is in Pidgin while the other is in Psi. Also illustrates librarian's view of chat when patron disconnects. (2:11; 2.97 MB)
Wednesday, March 5, 2008
How to Fix Things
A few folks are starting to play with the queues, which is really exciting! We are very much aware that currently, the web admin interface is lacking. For instance, you can't currently delete your own queues, which is a big problem. It should also have more help built-in, to assist you in getting things setup correctly. The entire admin interface will improve in the future.
In the meantime, if you've tried to get something set up, and it's just not right, please let Eric know. He can get into the database manually and move things around or even delete queues so you can start again. You can IM Eric at eric@libraryh3lp.com.
Also, coming soon, we hope to have a brief screencast showing a basic setup, from initial admin account creation, to user and queue creation, to monitoring a queue in a Jabber client and receiving a chat. We hope that seeing the process unfold will help explain how it hangs together.
In the meantime, if you've tried to get something set up, and it's just not right, please let Eric know. He can get into the database manually and move things around or even delete queues so you can start again. You can IM Eric at eric@libraryh3lp.com.
Also, coming soon, we hope to have a brief screencast showing a basic setup, from initial admin account creation, to user and queue creation, to monitoring a queue in a Jabber client and receiving a chat. We hope that seeing the process unfold will help explain how it hangs together.
Sunday, March 2, 2008
Talk on UNC-Chapel Hill Campus This Wednesday
Just in case anyone is interested and local, we wanted to let you know that we'll be giving a talk about libraryh3lp, with a special emphasis on open source, in Chapel Hill this Wednesday. This is the first in a series about open source software in libraries, and it's sponsored by the Carolina Open Source Initiative (COSI) and the Information and Library Science Student Association (ILSSA).
Date/Time: Wednesday, March 5, 5-5:55 p.m.
Location: 208 Manning Hall, UNC-Chapel Hill campus.
More info is on Facebook, but you might have to be a member to view it. Parking is never much fun at UNC, so if you'd like to attend but just aren't sure how to handle that, e-mail me and I'll do my best to help. :)
Date/Time: Wednesday, March 5, 5-5:55 p.m.
Location: 208 Manning Hall, UNC-Chapel Hill campus.
More info is on Facebook, but you might have to be a member to view it. Parking is never much fun at UNC, so if you'd like to attend but just aren't sure how to handle that, e-mail me and I'll do my best to help. :)
Subscribe to:
Posts (Atom)
.png)
