Using Aardvark is a highly interactive experience — it’s about actively engaging in conversations with other people, not about passive consumption of content.  Using our IM, email, Twitter and iPhone interfaces, it’s easy to jump right in and start having conversations.

When we designed the new Aardvark website (launched 2 weeks ago!) we wanted to create an interface that was similarly engaging by being very interactive and highly responsive.  This post is about some of the technology we built to power the new web interface.  (This is more technical than most posts on the Aardvark blog, so apologies to all of the non-nerd readers out there…)

JSONH

Vark.com is a Ruby on Rails application that makes heavy use of client-side JavaScript (JS).  We wanted our Rails app to behave like a web service that only serves data and the JS to behave like a client that consumes data — instead of generating JavaScript server-side.

JSON is the obvious format to use when passing data between Rails and JS, but in Rails, the :json format is conventionally used to serve ActiveResource compatible output.   So we decided to use a new format and named it :jsonh (after “json+html”).

The :jsonh format is a regular JSON object with a consistent interface that exposes 3 fields: ’status’ (with the HTTP status code), ‘flash’ (with Rails flash messages) and ‘html’ (optional - with html needed for update on the client side).

For example, a typical response on a validation error could be:

{

 status : "422 Unprocessable Entity",

 flash : { errors:["Login/Password are invalid"] },

 html : "<form>....</form>",

}

varkify!

In the client-side JS we make use of the jQuery library.  But even with jQuery, implementing AJAX functionality tends to be repetitive — so we built functionality in between Ruby on Rails and jQuery to help us automate some of the AJAX patterns we use.  We call this set of functionality “VARKificiation”.

Here’s the core pattern we automate using VARKificiation: We have a form or a link and when a user clicks it, instead of reloading the page, we want the client-side JS to submit an AJAX request. Then based on the result of that request JS can decide to update some of the DOM, display a message, clear a form, etc…

Using VARKification, we can simply “varkify” a form.  varkify() will bind the “submit” or “click” event (depending if we apply it to a link or a form) — then when that “submit” or “click” event is triggered it will figure out the url, method and parameters to submit to the Rails app by looking at the DOM.  Once the request is complete it will run the callback passed.  The response is passed as a parameter:

$('form#new_session').varkify(function(json) {

  // when the request is complete

  ...

});

Putting it all together

So now, using :jsonh and VARKification, we can write this code:

$('form#new_session').varkify(function(json) {

 // when the request is complete

 if (json.success) {

   // if we received a 2xx status code, redirect

   window.location.href = json.location;

 } else {

   // if there was a validation error, reload the form

   $(this).html(json.html);

 };

});

varkify() will display the flash errors automatically and the callback lets us update the page according to the status code and html from the :jsonh response.

Since we isolate our JavaScript from our HTML code, when we update a piece of DOM that new code has no behaviors associated with it and we need to rebind them.  All we need to do is call the following helper in our view:

<% add_behaviors 'VARK.behaviors.signin_form()' %>

This will add one more element to our jsonh response, so behaviors can be loaded by varkify() with some eval() magic:

{

  status : "422 Unprocessable Entity",

  flash : { errors:["Login/Password are invalid"] },

  html : "<form>....</form>",

  behaviors: 'VARK.apply_behaviors(["VARK.behaviors.signin_form()"])'

}

Other patterns

In creating vark.com we codified many more patterns, and took advantage of the best that Rails and jQuery had to offer.  For instance, within the VARKify framework we can do things like prevent double-submits on forms, standardize the appearance of spinners in the UI, and lots more.

And now for the plug … If you’re interested in front-end engineering — or, for that matter, systems engineering, cloud computing, machine learning, or search algorithms — you should consider working with us to solve interesting problems.