Since joining forces with Ben about 6 months ago, we have had a blast creating and testing out new features (both internal and public). Along the way, we have iteratively improved the flexibility of our widget styling, core Javascript, and backend services to make customization easier.

We feel that it’s time to start exposing some this flexibility outside of the founding team here at Olark. Why? Well, it turns out that we are hitting a pretty broad range of customers: ecommerce sites, small businesses, realtors, freelancers, lawyers, and more. You can imagine that each of these customers has specific needs for their business.

The most-requested features definitely get our full attention, but obviously we can’t incorporate every idea that comes our way. So now we invite you, the designers and developers of the world, to start working with us. If you’re setting up a website with Olark, you can customize the look and behavior to fit the specific needs for your business.

Our first step is offering full CSS styling, for designing custom themes. Designers can get access to this immediately from our plans page. We are still testing out pricing models for this, and right now we ask that you keep our branding intact. Please give us your feedback!

Our next step is a new Javascript API, for developing custom behaviors. With the current version of the API, you can do basic plugins like the example below. This example changes the visitor screen name to their geolocation. Instead of seeing “webuser1234” in your buddy list, you will see “Mountain View, CA, USA” or “London, UK”.

<script type="text/javascript" src="http://www.google.com/jsapi?key=YOURGOOGLEJSAPI_KEY"></script>
<script type="text/javascript">

var config = wc_config();

if (google && google.loader && google.loader.ClientLocation) {
    config.vars.force_nickname = ""+
        google.loader.ClientLocation.address.city+", "+
        google.loader.ClientLocation.address.region+", "+
        google.loader.ClientLocation.address.country;
}

wc_init("YOUR_HABLA_SITE_ID", config);

</script>

Over the next month, we will be releasing an upgraded Javascript API to allow easy triggers for important events (e.g. shopping cart failures) and simple hooks into our message system, with jQuery at the core. If you are a developer and have some great ideas of what you would like to see, please get in touch with me on my Olark at mjpizz.com or on Twitter.

-Matt @mjpizz

We pushed a minor release of the javascript today. The primary improvement, is better handling for links clicked on in the hab.la window, and URL’s sent to visitors on the site using the push! URL command.

We also have been listening to your feedback, and removed the ‘feedback’ link from the Hab.la window.

So most fancy Javascript toolkits implement some kind of DomReady(). Up until today, hab.la was only using document.onload to determine if the DOM was ready to go.

However, there are better ways of doing this.

/* Borrowed from: http://www.domassistant.com/ */
/* Mozilla/Opera 9 */
    if (document.addEventListener) {
        document.addEventListener(“DOMContentLoaded“, DOMHasLoaded, false);
    }
    /* Safari, iCab, Konqueror */
    if (/KHTML|WebKit|iCab/i.test(navigator.userAgent)) {
        DOMLoadTimer = setInterval(function () {
            if (/loaded|complete/i.test(document.readyState)) {
                DOMHasLoaded();
                clearInterval(DOMLoadTimer);
            }
        }, 10);
    }
    /* Other web browsers */
    window.onload = DOMHasLoaded;

IE6, and older browsers still lack a nice way of detecting whether the dom is ready, so you are stuck with document.onload, but other more modern browsers have variables and events you can use to detect whether the dom is ready. These are the same methods generally used by the large frameworks, condensed into just a few lines of code.

Recent versions of Firefox will fire the "DOMContentLoaded" event when the dom is ready.

Webkit will set document.readyState to “loaded” or “complete”, and so the savvy javascript programmer can poll these variables using javascript.

Some of our users are in environments where they can’t embed the hab.la javascript directly onto their websites. As a workaround we developed a method of showing an image that displays hab.la status on their websites.

A few days ago, I noticed that the status display was a little slow for my liking. In fact, it was running as a normal CGI ( a big no no), but since not to many people were using it, it’s performance wasn’t that big of a deal.

Today, I increased performance by 1800%, speeding up the status image response time from ~0.474 seconds to ~0.026 seconds.

ben@lyle:/var/www/online# time curl "http://dyn.hab.la/online/image2.cgi/4324-24618-10-8812/image.png"

real    0m0.474s
user    0m0.016s
sys     0m0.004s

Versus:

ben@lyle:/var/www/online# time curl "http://hab.la/status/4324-24618-10-8812/image.png"

real    0m0.026s
user    0m0.012s
sys     0m0.004s

What sped it up so much? First, I replaced the CGI script, with a very lightweight webserver. This made it so that python didn’t have to instantiate from scratch every time image.cgi was loaded. Second, I replaced the old calls to our RPC server, with newer calls to our memcacheD servers. There are still too many MySQL calls in this process, but optimizing those into pure memcache can wait for a while.

To learn more about using Hab.la without Javascript, take a look at My blog post or our tutorial for websites without Javascript.

I’d really like some feedback on the latest IE6 feature push. The previous Javascript based method of placing Hab.la in a window seemed a bit jumpy, and not really that responsive. I rewrote the JavaScript that causes Hab.la to stay in the corner as you scroll your web-page. Now Hab.la will follow you around in a much smoother fashion. Let me know what you guys think of this.

IE6 has some limitations, but we try our best to mitigate them :-).

A little bit more detail on the problem: Essentially Hab.la can’t float in the corner in IE6 because IE6 does not support FIXED positioning. I.e. unlike IE7, Firefox, Opera, and Safari IE doesn’t support the position: fixed CSS tag. There are many methods of mitigating this problem, including many CSS Hacks. We wanted to stay away from CSS Hacks, which require a separate CSS file because we couldn’t depend on the CSS styles rendering for all the dynamic DOM content in Hab.la.

If you a search on Google you’ll notice this is a pretty common problem. In any case, the old method was to update the position of the Hab.la div whenever you scrolled, or resized the window. This created really choppy transitions when users were doing a lot of scrolling, but more closely mocked up fixed:position.

In the new method, which I adapted from http://www.codingforums.com/showthread.php?p=637753 Instead of monitoring events such as window.onscroll or window.resize. We just monitor the window every 500ms to see if we need to change the location of the Hab.la DIV. When a change is necessary, instead of immediately moving the div to the correct location, we smoothly move the div the desired location exponentially approaching the desired X,Y coordinates. [The above is pretty much what I found in coding forums, but the guy writing that post definitely didn’t write his code so it could be read by others – and has some extra steps that aren’t really necessary.]

In short, IE6 users, please let me know if you think the smooth fixed positioning via JavaScript is a useful improvement.

I just finished implementing a feature to make it easy to customize all the colors used in your Hab.la window to match your site’s look and feel. AND you can do it without writing a line of JavaScript! (Let’s see another FREE livehelp solution beat that! ;-) )

Anyone with the Hab.la code on their website can log into the their My Hab.la page, and than customize the colors of their Hab.la window using the color customizer. As a user all you have to do is set the colors using the handy ‘color selector’ and press ‘save’. That’s it!

And if you want a new color scheme tomorrow, just come back to the Hab.la website, and change it. No need to touch the source code of your web-page at all!

In other less happy news, I realized that there was a race condition pushed out in last-night’s Hab.la update. I fixed the race condition in the recent push. Essentially it was causing Hab.la to display the “invalid site ID” error, when everything was actually kosher.

A long time ago I wrote the first version of the JavaScript color customizer. It is probably the only JavaScript based tool for customizing a livehelp, livesales, or chat widget application. Of course it’s never been as user friendly as it should have been.

I just spent some time hacking around on a new color customizer to make it easier for Hab.la users to customize the colors of the chat widget. Now, every color can be customized. The new Color Customizer.

The current version of the customizer still requires users to paste JavaScript code onto their web-pages. However, in the near future we will integrate the Color Customizer into the new and improved Hab.la Customizer where you can customize most of the text fields in Hab.la without having to edit any JavaScript.

I pushed out the latest version of the Hab.la JavaScript tonight. (I actually have been slowing rolling it out over the past few hours, but it is completely deployed now)

Before we do any deploy we test the JavaScript with IE6, IE7, Firefox, Safari, and Opera. It’s funny how you need to make simple tweaks for each browser and so the Javascript will compress correctly. Funny in that so much time is essentially wasted because Microsoft didn’t listen to W3C standards.

The new JavaScript should be completely backwards compatible with the old setup. Please let us know if you did a lot of customization on Hab.la, and your customizations no longer work.

The most interesting aspect of the new JavaScript is it’s support for dynamically loading themes and plugins, and the ability for Hab.la users to customize their Hab.la windows without having to write JavaScript. (We will be rolling out a control panel for managing these features soon).

In any case the transition should be relatively transparent for most users. We will be adding documentation on the new features this week.

We discovered a race condition in the JavaScript that caused otherwise ‘nice’ clients to start making requests to Hab.la roughly 3 times a second. We can handle a few run-away processes, but on Friday we encountered enough race-conditioned-javascript-requests that it adversely affected the RPC server that connects the Jabber Backend with the Javascript client.

Over the weekend we made a few tweaks to the JavaScript that will probably prevent these problems from happening again. However, this didn’t stop people who were using the older JavaScript from hitting our servers.

Luckily it is relatively easy to detect users who have JavaScript that is running away. Each time our javascript makes a call to the RPC server, the last argument passed is the request # from that page. I.e. if your client has polled the server 10 times, the last argument of the 11th poll will be ‘11’. Client that are going crazy will pass numbers in the 1000s, and sometimes even in the 100,000s as what happened on Friday. We have a few tricks in the RPC server to deal with runaway clients, including forcing them to reload the page once they hit 1000 requests, but sometimes these requests fail.

To mitigate problems caused by people running older versions of the JavaScript client, I created a lighthttpd rule to block clients who have made over 2000 requests to our server. (Our smart polling techniques and other fail safes should ensure this will never happen during a legitimate chat)

##
## Block users who's javascript has gone crazy
#
# i.e. if they've hit above
$HTTP["querystring"] =~ "jscript[^1]\d\d\d$" {
       url.access-deny = ( "" )
}

$HTTP["querystring"] =~ "jscript\d\d\d\d\d+$" {
       url.access-deny = ( "" )
}

This rule denies access to users with JavaScript counts over 2000, ensuring that the RPC server does not become bogged down, during race conditions in the JavaScript. (In short, now that we’ve fixed the JavaScript this rule is probably useless, but is a nice fail-safe)

What I would really like to do is limit the number of connections per IP per 60 second interval, but I am fairly confident we will have to write our own lighttpd plugin based on mod_evasive. It actually looks like it shouldn’t be too hard to do this.. so we’ll see how things go.

Ever start chatting with a visitor on your site only to realize that you had no idea what they were saying? It happens to us at Hab.la all the time.

Luckily for you, and us Google released a translation API today, which let’s site authors make AJAX calls to translate text in real-time.

I added a plugin to hab.la to do just this. The site operator can specify a language they would like to receive chat’s in, and Hab.la will work with Google Translate to make it’s best judgment about translating the messages.

Google’s funky JavaScript loader makes this plugin a little bit complicated to install, but the extra effort is definitely worth it (if you need your chats translated).

<script type="text/javascript" src="http://www.google.com/jsapi">
<script type="text/javascript">
google.load("language", "1");
</script>


<script type="text/javascript" src="http://static.hab.la/js/wc.js">
<script type="text/javascript">
config = wc_config();

// Choose the google abreviation for your language:
//i.e. en, it, ft, de

config.vars["language"] = "en";

// enable the plugin
config.vars["enableLanguageTranslation"] = 1; 

wc_init("1776-526375-10-3058",config );
</script>

The complete list of languages, and more details about the plugin can be found at : http://static.hab.la/examples/translation.html (It is still very much a work in progress so as always we appreciate your feedback!)

That’s it!

Remember you can already customize all the text fields and colors in hab.la, and even skin it useing custom CSS. Read more on the wiki.

More updates on their way!