libraryh3lp logo

LibraryH3lp is software used by libraries, educators, and non-profits for better customer service.

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:
  • 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?
Thanks for your help!

5 comments:

Unknown said...

u should just try to fix the favicon problem
and then implement it
(if ie can do it you should be able to tweak the way firefox handle it)

Unknown said...

found something for firefox
.tabbrowser-tab[busy] {
list-style-image: url("chrome://communicator/skin/icons/loading.gif");
}
ud need to replace the default one with the website one

Pam Sessoms said...

Just in case anyone is reading comments and hanging back from putting in their two cents, we've confirmed that the suggestion above (unfortunately) will not stop the appearance of constant page load in Firefox. We'd still love your thoughts on when or if rrtp is desirable.

dansich said...

rrtp is good as is (for embeds only), but it would be nice to have it for pages with pop-up links as well. the 'page is loading' animation is a bit distracting, but worth the result.

Pam Sessoms said...

Dan, thanks for your feedback!

We've learned from some other folks that the rrtp is so distracting that they don't want it for fear the patrons might try to reload the page during a chat.

So the current plan is that we'll be disabling rrtp by default in both instances (pop-up and embedded) in the short-term.

However, in the long term (as soon as next weekend or as long as a month), we're going to bring it back as an option that people can opt into if they wish. That is, it will be turned off by default, but it will be a very easy switch to turn on independently for any widget.