We don't hire developers. We hire hackers. And here's why.

When building experiments through any testing platform, our developers have to think differently to most front end developers, and sometimes, they need to get creative. Like us, there are other companies which don’t have access to the clients’ source code, but have to ensure that their code snippets aren’t going to break anything. Products like Optimizely, Qubit and Qualaroo work in this way, for example. Our developers have to create a robust and modular code that can be applied to any website and run smoothly without causing any issues.

When it comes to us at Conversion.com, we effectively create our experiments on top of our clients’ websites. Through selectors in jQuery and CSS, we apply the desired new look (and sometimes functionality) for our tests. Of course, things can often be more complicated than that – we might have to rewrite an existing Ajax call (or hook our snippet on an existing Ajax call). Or we might have to manipulate what a form submits and how it invalidates – all without having access to any file in our clients’ server.

You could say we are in a way, a new kind of developer. There are Back End developers and Front End developers and then there is us, somewhere in between, placing a layer on top of the existing website in order to make our experiments work the way they are intended.

Here are some tips that we have found to be the most useful when developing A/B tests for our clients at Conversion.com.

1.1 Injecting CSS

Starting with CSS, we inject our document, minified, at the head of the document using Javascript. At Conversion.com, we have a special plugin for that, but you could always link to an external file you have with the following code:

$('head').append('<link rel="stylesheet" href="style.css" 
type="text/css" />');

1.2 Wrapper ID

You might not want your CSS to overwrite any existing CSS that isn’t impacted by your experiment. Having the same names for classes can sometimes happen, so it’s advised to wrap your content with a unique ID and simply point your CSS towards that ID and its children. For example, if you wrap your content with:

<div id=”conversion01”><div class=”content”></div></div>

then simply calling:

#conversion01 .content

would ensure that you don’t change something that you don’t want to change.

1.3. Sometimes you really do need to overwrite CSS

Even though we neatly wrapped our content with our unique ID, you might actually need to alter existing elements across the website. This often means that there will be a conflict of CSS rules between what you are trying to do and what is already there. You can either overwrite those rules by being more specific than the original CSS (e.g. body > .container > .paragraph instead of just .paragraph) or use

1.4 important!

I know! Using !important is reprehensible in a normal project. Unfortunately, we might need it a lot. !important is a quick way to make the changes we need so we can get the test live sooner. We can write better code once the test has proven successful and it’s worth the extra effort.

1.5 Not everything is always tidy

Unfortunately, sometimes the HTML structure of some websites is not really tidy. There have been cases where some websites had tables and nested tables, with only a class given at the parent level.  Certain CSS changes had to be done two or three children below. In times like these, your only option would be to use a vague nth-child().

On the other hand, if you do so, you should be careful in case the client changes something on their website (e.g. adds a new column in said table), since the previously selected element might no longer be represented by the number you chose in nth-child().

Most of the time, new content is needed for our experiments. In order to inject this new content we use the following jQuery functions:

append(), prepend(), after(), before(). 

By locating where our content should be, we use one of the functions from above appropriately. These functions also help to wrap our new content with the styles of the existing website. That’s really important when a client’s website uses a framework (e.g. Bootstrap CSS) and all we have to do is place our content within the already defined Bootstrap elements.

(e.g. <div class=”.col-md-1”></div>).

There are also scenarios where an external script is needed in order to help with the development of a project. One example would be using fancybox.js in order to create a lightbox. At the top of the document, we include the CSS of fancybox and point to the images accordingly, and once we need to use it, we call

$.getScript('js/jquery.fancybox.pack.js', function() {
    $(".fancybox").fancybox();
});

There are cases in which we need to alter an existing form or create a new one that would still submit some of the old form’s information. Sometimes hiding certain fields is enough, but there are also more complex scenarios than that.

The way we handle this is by copying the information that is typed into the new fields to the hidden form, usually on keyup. We use keyup because we usually have a dynamic field validation as well, so having everything within one function is tidier. Our code would look something like this:

$(‘#newinput’).keyup(function() {
    $(‘#oldinput’).val($(‘#newinput’).val());
});

and if there is a new submit button you .submit() the form when the new button is clicked.

Some websites have elements that might be loaded through Ajax due to a framework or plugin that the client is using. If we need to change that element then we might need to wait for it to exist first, and then do the necessary alterations.

var checkElement = setInterval(function() {
    if($(‘.element’).length){
        //do stuff
        clearInterval(checkElement);
    }
}, 50);

Finally, if you have a more complicated problem that needs a more advanced solution, you could always hook up the existing Ajax call and create your changes accordingly.

As I said before, these are the 4 main tips that we have typically found to be most useful when developing A/B and multivariate tests for our clients here at Conversion.com. There are many other techniques out there that you may find useful when developing under this new paradigm, which is effectively a layer in front of traditional front end development. If you have any of your own tips to share, or any thoughts on any of ours, we would love to hear from you – so be sure to leave your comments in the box below.

Thanks for reading!