Introducing Cordia
From time to time I have the opportunity to look over the latest developments on a friends website and pass comment. The comments usually take the form of “Add more whitespace” and “Remove more clutter”.
One of the major cause of clutter are the settings, which have slowly built up over many user feature requests until they, at one point, got to the stage where people were requesting options that were already there simply because they couldn’t see them in the list.
This causes a problem – you can’t simply remove options that someone has requested, they might actually be using them. At the same time, however, I strongly suspect that very few people are using some of the options. The difficulty is, there is no way of telling.
No way of telling, that is, without data. If they were able to tell which options and which values people used they could aggressively remove unused options without too much fear of upsetting people.
All this is by way of introducing a tool I’ve written, called Cordia. Cordia is a jQuery plugin that allows you to easily monitor javascript events which are then submitted to a website to be stored and processed as appropriate.
Here is an example of how you might use Cordia to monitor which values from a select control in a page’s options panel are selected.
$.Cordia.defaults.posturl = "http://www.example.com/cordia";
$.Cordia.defaults.useuserid = true;
$('#settings select').monitor('settings', 'change');
The first line sets the url that Cordia will submit the log data to. It uses standard HTML post so that you can easily write your own backend to store and process the data.
The second line enables logging of user ids, which is disabled by default. Cordia has the concept of users and sessions, both of which are identified by a GUID. The user’s id is stored as a cookie and provides a way of associating logs with users across multiple visits to the site. The session id is generated each time the page is loaded and provides a way of associating logs with a particular visit. It is recommended that you use user ids sparingly and only when needed.
The last line sets up the hooks to log the event. First you use the standard jQuery selector syntax to select the elements from the page. As you can see from the example, you can add the hook to multiple elements. Next you attach the hook using the function “monitor”. The first parameter is the category, which can be used to organise the events. The second parameter is the name of the event to monitor. This is the standard jQuery name for the event, which is usually the same as the HTML event name but without the prefix “on”.
Now whenever the select’s onchange event is fired a log message will be composed, including the user and session id, and posted to http://www.example.com/cordia.
For several of the HTML events extra data, such as the value of the change event or the position of the mouse events, are also sent. You can even attach your own data like so:
$('#updatebutton').monitor('settings', 'click', {
getExtraData: function(e) {
return {
'extrasettingsvisibility': $('#extrasettings').css('visibility'),
};
}
});
You can find out so much information just by logging the basic events. You can see what settings people are using in a web app, you can see how fast people are filling in a form by logging focus and blur times, you can see if people use tab to navigate by logging key events or blur and click combinations, you can see if people have discovered and are using your help tooltips by using focus and blur times, the list goes on.
I hope some of you find Cordia useful. You can go download it at http://code.google.com/p/cordia/. I have plans on how to extend it when I get time, such as making it easy to buffer multiple log messages before submitting them, making things like monitoring mouse movement more viable.