Hab.la revisited: site-wide implementation

Posted by admin on April 21st, 2008 filed in Hab.la, IM, chat, correction, widgets

There have been some recent enhancements made to Hab.la functionality that mean Hab.la may be a good choice for site-wide implementation after all. I had a long overdue chat with busy Hab.la-programmer Ben Congleton this morning, and have some good news for those of you who were disappointed to read this post on Hab.la.

But first, a correction: Hab.la uses Javascript, not Flash. As such, it will (unlike MeeboMe) display on machines that don’t support Adobe Flash Player, and is kinder to screen-reading software than the Flash-based MeeboMe widget. (Apologies for the misinformation presented in my presentations at OLA 2008 and CiL 2008.)

And now for the good news: Hab.la has created a work-around for the cap of 5 simultaneously displaying widgets. (If memory serves, this cap was my only reason for not being able to recommend the service for OPAC-wide and/or site-wide implementation.

By including the line:

config.vars["start_passive"] = 1;

…you can have the ‘passive’ Hab.la widget appear on any number of pages simultaneously. (Take a look at the code for my page to see how the start_passive line can fit in.) (By the way, I don’t advocate implmenting both Hab.la and LibraryH3lp on the same page/site — they’re just here for testing purposes.)

When the patron clicks “Chat with…” the chat box will not only ‘expand’ (as it does with the normal/active Hab.la widget) but will also become active. For librarian accounts (I may be the first to get one) the cap on simultaneously active Hab.la widgets has been raised to 30. (For regular users the cap is still 5, but may be increased slightly.)

When it comes to talking about OPAC-wide or site-wide implementation, having the widget appear collapsed — while it may not be as much of a web presence as an open chat box — may be a best practice anyways, as it takes up less real estate.

To clarify, the 31st patron on your page or site will see the widget displayed… but the widget will be collapse and in passive mode. When the 31st patron clicks on “Chat with…” s/he will see messages as determined by the settings:

config.vars["busy_text"] = “Busy”;
config.vars["busy_message"] = “Who max’d teh chats out?”;

…where busy_text appears in the ‘bar’ and busy_message appears where the patron would otherwise be able to input their chat message. (You can use whatever text you like for these.)

30 simultaneously chatting library patrons may never happen in my world, but we might get 30 simultaneously opened Hab.la widgets due to curious clickers. To deal with this possibility, Hab.la programmers have put a time-out in place: any patron sitting on the page for 45 minutes and/or having left the page for 2 minutes will get disconnected from Hab.la. We could probably lower the first number substantially. How long do patrons wait before returning to a chat? Should we ‘wait’ around while they eat lunch?

Other fine points:

Patrons won’t appear in your buddy list until they activate the widget. In my opinion this is not big deal, since there are much better ways of gathering web usage stats than watching the flies on your buddy wall. Note that once a patron starts chatting, s/he will appear in your buddy list. The patron will vanish from your buddy list when s/he leaves your page.

In the event of a librarian logging off/on, widgets will change their status only with a page reload. Nothing is different here from the ‘regular’ Hab.la. Contrast this with the RRTP (Really Real-Time Presence) of LibraryH3lp widgets. How important is this feature to patrons? How often are you logging in/out of your chat account?

Additional documentation has been added to the Hab.la wiki.

Hab.la is also looking into introducing some new features (still in alpha version) of interest specifically to libraries: multiple operators and routing methods.

Now, unlike Meebo, Hab.la has no external sources of funding and so the programmers are hoping to identify enhanced features for which libraries would be willing to pay. I know that the thought of having to pay for virtual reference software can be a sore point for at least a few libraries out there. That said, programmers work hard and need to eat their curries too.

Can you think of any features that you would be willing to pay for in an widget-driven IM service?

Off the top of my head, I’m thinking of transcripts, although there are reasons neither of the libraries I’ve worked for are keeping transcripts. I’m not aware of Meebo offering chat transcripts for their MeeboMe widgets, but I could be mistaken.

Are there any other bells and whistles you’d like to see in a chat widget?

If you’re interested in working with Hab.la, please get in touch via their website. They’re eager to work with libraries.

Finally, I’ll reiterate a point I’ve made in my last two conference presentations: There are a lot of solutions out there, none of them one-size-fits-all. As in all things, a lot is going to depend upon your local systems, settings, policies, practices and preferences.