If you’d like to know why they are doing this and how it will affect you as a developer, I encourage you to take a look at Opera Mobile Emulator build with experimental WebKit prefix support.

When Opera first made this announcement, I wrote Vendor Prefixing: Standing Up for Developers, where I explained that it wasn’t just developers who should be taking the blame for vendor prefixes not being implemented properly. I also mentioned that I’ve had a lot of difficulties with my personal project Sequence.js, due to an Opera bug.

I’ve been awaiting Opera’s post regarding exactly which Webkit prefixed properties they would render and as I anticipated, my personal project no longer works due to these changes. What’s more, they may cause issues for other websites too.

In this post, I will address concerns I have regarding this move and provide code examples that I believe could prove to cause trouble for Opera in the long run.

Issue 1 – jQuery Doesn’t Bind transitionEnd Events

Sequence.js, is a CSS3 transition based slider. It relies on transitionEnd events to be able to time the changing of slides within a slideshow.

In Opera Mobile Emulator Experimental, if you’re using jQuery to bind events to transitionEnd, those events, whether prefixed or non-prefixed, will no longer work:

$(document).bind("webkitTransitionEnd oTransitionEnd", function(){
    alert("transition ended");
});

See a demo here: JSFiddle: transitionEnd Issue

I also tested binding these events in standalone JavaScript which does work, so clearly this is an issue with jQuery. I am unfamiliar with the jQuery source, so hopefully others can expand on why this is happening (or not happening as the case may be). Whilst not technically a fault with the Opera browser, existing applications that rely on these jQuery events may no longer work.

Update: You can find the JS binding test here.

Update 12th May 2012: Having looked into this a little further, it appears the Experimental Opera Mobile Emulator is converting transition events to lowercase. So, oTransitionEnd becomes otransitionend. A workaround is to bind the lowercase version in jQuery, demonstrated here.

Issue 2 – Modernizr Returns the Webkit Prefixed Property in Opera

Modernizr is used to query the features of a browser, allowing a developer to write fallbacks in the case of a browser not supporting a particular feature.

alert(Modernizr.prefixed('transition'));​

See a demo here: JSFiddle: Modernizr Prefixed Issue

The above code in a Webkit browser, returns “WebkitTransition”. Now that the experimental Opera supports Webkit transitions, this query returns “WebkitTransition” too. Is this a problem? Yes.

As Opera mention in their post, when using prefixed properties in CSS they’ve chosen to respect the cascade, allowing a developer to place the property they want Opera to rely on below others in the rule set. If you want the Opera prefix to take precedence, place it after the Webkit prefix and vice versa. With Modernizr.prefixed(), you don’t have that choice. You just get “WebkitTransition”. You may want to treat Opera differently to a Webkit browser based on this result, but you no longer get the choice. Issue 3 supports this.

Again, this isn’t directly an issue with Opera but it does effect existing tools and may cause more issues for developers…even the responsible ones.

Issue 3 – Opera Doesn’t Return the Transition Duration Via JavaScript

This issue doesn’t just exist in the experimental Opera Mobile but it’s previous versions and the upcoming Opera 12, and is only made worse in the experimental version.

transDuration = $("#menu").css("-o-transition-duration");

See a demo here: JSFiddle: Transition Duration Returns an Empty Value

Opera Bug Report

When getting the transition duration of an element via jQuery or JavaScript, an empty value is returned.

This isn’t a result of Opera rendering Webkit properties but it does mean that the issue can no longer be avoided via querying the browsers features and serving a workaround, as mentioned in issue 2.

Promoting Laziness and Punishing the Responsible

I call myself a responsible developer. When developing Sequence.js, I consider all browsers and although it uses cutting edge technology, I make sure it works in older browsers too. When I came across issue 3 in Opera, I spent two days working out what the issue was and writing a workaround for it because I wanted to support Opera. I am certainly going to have to spend more time working on the project to get it working in future versions of Opera too, should this experimental approach become reality.

I’d like to point out that I have nothing against Opera but do I agree with this move? It’s difficult to say. I understand that they want to fix the issues created by lazy developers but at the same time, it seems that laziness is being further promoted.

Tweets such as:

"I don't include the -o- prefix because I don't test in Opera because it accounts for 0.3% of our visitors. Not because I'm lazy or inept."

And:

"I totally see why Opera is doing this. I'm bad at using the -o prefix, if they have parity with webkit then go for it."

Show that some developers are, to be frank, stupid, and in the case of the latter, encouraged to be stupid. If you can type -webkit-, then you can type -o-. How can you be “bad” at that? Does taking a couple of seconds to write an extra line (or run your whole stylesheet through Prefixr) equate to the trouble your visitors may face because you didn’t include an extra prefix? Even if you’re not going to test in Opera, by not including the -o- prefix, your site will be more broken that what it is if you do include it but not test.

With the issues I’ve mentioned above, it seems like it’s not just laziness that is being encouraged but the responsible are being punished at the same time.

This isn’t about developers though. It’s supposed to be about the users. Bridging the gap so users don’t have to suffer. This I completely agree with, although the way in which Opera have approached it, I’m not so sure about.

They explain that they took the top 10,000 sites and analysed what -webkit- prefixed properties were used without fallback, then acted based on those findings. I think this should be reconsidered. Does Opera (or any browser for that matter) really need to support transitions? Do they benefit the user or subtract from an experience should they not be implemented?

Let’s not contradict the purpose of making this difficult move. This shouldn’t be about keeping up with the competition. I’d like to see Opera provide cases where a site is broken because an -o- prefix or the official property has been omitted, justifying the need to support the -webkit- one.

Opera, you’re being closely watched by other browsers that may want to make this move too, let’s get it right from the beginning.

Sequence doesn’t work out of the box. That sounds bad right? Usually when you install a slider plugin, it looks and functions pretty much the same across however many sites it’s installed on. Not Sequence!

Not a single installation of Sequence ever has to be the same. Using only CSS3, you can style not just the looks of your website’s slider but it’s transitions too. Take a look at some of the demos:

You can achieve an infinite amount of styles, transitions and effects using the latest web technologies. Rotate, fade, skew, 3D transform, parallax effects, you name it. Finally…you have creative freedom but still all the functionality you expect from a slider plugin.

Sequence also supports touch devices and responsive designs. It’s not just about the cool stuff though. Sequence also works in browsers that don’t support CSS3 using graceful fallbacks that can also be customised.

Sequence is an open source project, so if you have feedback or would like to collaborate, follow the project on GitHub.

I’ll be posting a tutorial very soon to demonstrate how you can use Sequence to make your own slider theme.

Their argument in my opinion is justifiable; too many developers are only targeting WebKit browsers, often leaving anything other than WebKit either with a lesser experience, or worse, completely neglected and broken. By parsing -webkit CSS properties, non WebKit browsers will be able to bridge the gaps left behind by developers that haven’t done their job as well as they should/could.

In the articles I have read regarding this, the blame seems to be resting entirely on the shoulders of developers which I think is unfair. Shouldn’t we question why developers haven’t taken the time to develop cross browser features?

In response to Bruce Lawson’s article, Mat “Wilto” Marquis tweets:

Don’t say I didn’t warn you, makers of “iPhone websites” the world over.

Whilst I don’t deny there is a side-blinders culture of developing for WebKit only, there are legitimate and realistic reasons for not considering other browser prefixes, of which, in some cases, the browser vendors themselves should take their fair share of blame.

For as long as I have been educated in the matter of cross browser compatibility, I have made every effort to make whatever I am devloping work in all browsers. I say this with a tear of frustration in my eye and a bead of sweat on my frow: cross browser compatibility is difficult!

Co-chairman of the W3X CSS Working Group, Daniel Glazman, writes in a call for action:

I am asking all the Web Authors community to stop designing web sites for WebKit only, in particular when adding support for other browsers is only a matter of adding a few extra prefixed CSS properties.

Unfortunately, in many instances, Daniel Glazman’s statement just isn’t true. In a personal project I am currently working on, I spent two days developing a workaround for Opera because I wasn’t able to get the value of any of its vendor prefixed properties via JavaScript. If it were a client project, my schedule would have been knocked off by two days and I’d be left with the decision of charging the client extra or taking the hit myself for a bug that was unforseen. I spent these extra two days developing a workaround because I believe in cross browser compatibility. Would all clients be so concerned about cross browser compatibility in a browser that doesn’t have the biggest market share?

I’m not just pointing a finger at Opera here and I don’t agree with ignoring a browser because it’s market share is smaller (but unfortunately clients often do), it’s merely a recent experience I had that demonstrates the difficulties developers have to face when dealing with multiple browsers.

Are browser vendors truly aware of their responsibility too? One bug in a browser turns into x number of bugs across x number of websites.

As developers we are being asked to develop cross browser compatible websites with technology that is not cross browser itself. In my experience, WebKit has the most accurate implementation of the specifications I use to build for the web. It is to be expected that a specification still in draft is not perfectly implemented across all browsers but it too should be expected that developers (and in particular their clients) cannot spend extra time and money developing different implementations of the same outcome.

I am not just passing the blame back to browser vendors. It is true that a lot of developers are ignorant towards browsers beyond WebKit powered ones but there are a lot of developers trying to do the right thing too, no matter how hard their job can be.

As far as a solution is concerned, I think Daniel Glazman is on the right track:

The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set. That would drastically reduce the problems on the Web.

This coupled with the automatic update of all browsers makes sense to me.

Getting Started

To recreate the search suggest feature, we’re going to use jQuery and a small amount of PHP to query the server for search terms. To allow these two scripts to communicate, we’ll make use of AJAX — passing a string containing the search term from jQuery to PHP. The PHP will then return a string containing the results. We’ll make use of JSON (JavaScript Object Notation) so our search terms/results are well formatted and easily encoded/decoded between these two technologies.

Note that for the sake of simplicity, we’re going to use a PHP file with some search terms in it that we’ll pretend are actual results. In the real world, you’d query a database.

The HTML

Let’s begin by creating the interface itself. Quite simply, to launch the search feature, we just need a search button, like so:

<div id="search">
    Search
    <img src="images/bt-search.jpg" alt="Search" />
</div>

We’ve given the div an ID of “search” which will allow us to add a click event to it in the jQuery later on.

When the user clicks the search button, we’ll open an overlay that sits on top of the rest of the page.

<div id="search-overlay">
    <h2>Begin typing to search</h2>
    <div id="close">X</div>
    <form>
        <input id="hidden-search" type="text" autocomplete="off" />
        <input id="display-search" type="text" autocomplete="off" readonly="readonly" />
    </form>

    <div id="results">
        <h2 class="artists">Artists</h2>
        <ul id="artists"></ul>
    </div>
</div>

Again, we’ve given the containing div an ID to allow us to interact with it via jQuery. We’ve also added another div with the ID of “close”, which, you guessed it, will close the overlay when clicked.

The search overlay also contains a form with not one, but two input boxes. Why? As WeAreHunted.com is a very visual site, they’ve gone to a lot of effort to make the site appear exactly as they want, meaning a small amount of trickery using two search input boxes to remove the blinking cursor from the input box. We’ll go into greater detail on this in the The CSS.

We also have a “results” div within the overlay that contains a list of the terms that match the users search query.

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script type="text/javascript" src="scripts/ajax-search-suggest.js"></script>
<link rel="stylesheet" type="text/css" media="screen" href="css/styles.css" />

Finally for the HTML, we need to reference the jQuery library (hosted via Google), and the jQuery and CSS files we’ll be creating shortly.

The CSS

To begin, we’ll style the search button (the div with an ID of “search”):

#search{
    background: #d3d3d3;
    cursor: pointer;
    font-size: 24px;
    font-weight: bold;
    text-transform: uppercase;
    padding: 20px 2%;
    width: 96%;
}

Obviously, you can style your search button however you want — none of the above CSS is required for the script to work correctly.

The overlay that will appear when we click the search button is styled like so:

#search-overlay{
    background: black;
    background: rgba(0,0,0,0.85);
    color: white;
    display: none;
    font-size: 24px;
    height: 100%;
    padding: 20px;
    position: fixed;
    width: 100%;
}

Let’s take a look at this a little closer. We’ve given the overlay a background colour of black but also specified an RGBA background too. So, in newer browsers the background will appear black (RGB: 0, 0, 0) but also have an alpha opacity of 0.85 and the page behind the overlay still shows through slightly. Older browsers will simply show a solid black background.

The overlay has a position of “fixed” which means it will also appear within the viewport and the height/width of 100% makes sure it covers the whole viewport. Also note that we’ve set the overlay not to show using “display: none”. We’ll change this in the jQuery when a user hits the search button so it becomes visibile.

Now, let’s take a look at those two input boxes and understand why we need two of them:

<input id="hidden-search" type="text" autocomplete="off" />
<input id="display-search" type="text" autocomplete="off" readonly="readonly" />

If you click on an input box in a browser, you’ll notice a blinking text cursor. This is something WeAreHunted.com appear not to have wanted. Unfortunately, there’s not a CSS property we can simply apply to make it go away, so instead, we need to use two input boxes. One input box will be hidden off screen (“hidden-search”) which is where the user will type, and the second input box (“display-search”) will mirror the contents of the first box. However, the second box is set to “readonly” in the HTML, meaning the blinking cursor is removed. Each input box also turns off “autocomplete” to prevent previous search queries from appearing in a list below.

Let’s hide the “hidden-search” input box in the CSS:

#hidden-search{
    left: -10000px;
    position: absolute;
}

Here we set the input boxes position to absolute and -10000px. This will place the box way over to the left, a long way from the viewport, where the user can’t see it.

#display-search{
    background: none;
    border: none;
    color: white;
    font-size: 60px;
    margin: 25px 0 0 0;
    width: 960px;
}

Now we can style the mirrored search input box. Nothing special is required here other than simple styling.

Our demo also contains a close button which is styled like so:

#close{
    cursor: pointer;
    position: fixed;
    right: 20px;
    top: 20px;
}

The only other notable styles are for the results list:

#results{
    display: none;
    width: 300px;
}

As we did with the overlay, we’ll hide the results list until we need it, using “display: none”.

The jQuery

Now we have our interface set up, let’s start adding the functionality using jQuery.

Showing/Hiding the Overlay

$(document).ready(function(){ 
    //...
}

We will wrap the code in jQuery’s document ready function. This will initiate as soon as the HTML and CSS has rendered (and the page is ready).

Once the document is ready, we’ll select some of the elements that will be used more than once; the two input boxes, the search overlay and the list of artists:

var $hiddenSearch = $("#hidden-search"),
    $displaySearch = $("#display-search"),
    $searchOverlay = $("#search-overlay"),
    $artistsList = $("#artists");

Note that we’re saving these selectors to variables to improve performance (it’s good practice to save a selector you will use more than once).

Now we add our first click event to the search button:

$("#search").click(function(){
    $searchOverlay.show();
    $hiddenSearch.focus();
});

When the “search” button is clicked, the “search-overlay” is shown (the CSS is changed from “display: none” to “display: block”) and we give the input box with ID of “hidden-search” focus. “Giving focus” is what happens when a user clicks on an input box — that box now has focus and the user can begin typing in it. Here we’re controlling the focus ourselves so as soon as the search button is clicked, the user can begin typing. Remember that the “hidden-search” input box is hidden off-screen so it’s very important we apply the focus because the user isn’t able to click the box themselves.

$("#search-overlay").click(function(event){
    $hiddenSearch.focus();
    if(event.target.id == "search-overlay" || event.target.id == "close"){
        $hiddenSearch.blur();
        $(this).animate({"opacity": 0}, 500, function(){
            $(this).hide().css("opacity", 1); 
        });
    }
});

We want the “search-overlay” to close when clicked, but not in all cases. When applying click events in jQuery or JavaScript, the element it’s applied to also listens to click events on its child elements. In this case, the “search-overlay” will have quite a few children; the close button, the input boxes and the list of results. The close button should obviously close the “search-overlay” when clicked, but we don’t want the input boxes or results list to close the search overlay.

A child notifying it’s parent of an event is called “bubbling” or “propagation”. As we want to be selective about which elements “bubble” we can pass the event parameters into the function and query those parameters, like so:

$("#search-overlay").click(function(event){
    //...
    if(event.target.id == "search-overlay" || event.target.id == "close"){
        //...
    }
}

By passing the event, we can query exactly which element or child element is being clicked. Here we’ve set up an if statement to determine whether the element being click is either the “search-overlay” or “close” button.

Now we can put all of our code to be executed when these two elements are clicked, into that if statement:

$hiddenSearch.blur();
$(this).animate({"opacity": 0}, 500, function(){
    $(this).hide().css("opacity", 1); 
});

So, if the “search-overlay” or “close” button are clicked, we remove the focus from the “hidden-search” input by using .blur(). We then fade out the “search-overlay” and hide it.

Note that before we used the if statement to determine what element was being clicked, we added the focus to the “hidden-search” input again:

$hiddenSearch.focus();

This is to make sure that if the user was clicking on an element that didn’t hide the “search-overlay”, the “hidden-search” input would still have focus (overriding whatever element the browser tried to apply focus to when the user clicked on the page).

Key Events

For our demo, we will use the “keydown” event, meaning whenever a user pushes down on a keyboard key, we can trigger our AJAX call to the PHP script, as well as dealing with the two input boxes we’ve created.

$hiddenSearch.keydown(function(e){
    //...
}

Note for this keydown event — like the click event on the “search-overlay” — we’re passing the event into the function (this time I’ve called it “e” just for speeding up writing the following code, and in real world code, I’d call it “e” consistently — although that’s personal preference, the choice is yours).

currentQuery = $displaySearch.val();

As soon as the user hits a key on their keyboard, we’re going to grab the query they’ve typed into the “display-search” input box and save it as a variable called “currentQuery”.

Now to make use of that event we passed into the function…

if(e.keyCode == 8){
    //...
}

Here we get the keyCode from the event (“e”). Each key has a value, in the case of the above code, 8 is the backspace key. See this reference sheet for a list of key codes. So, this if statement is checking to see if the user has hit the backspace key (and is trying to delete whatever is contained in the input box).

Let’s skip what code is triggered when the backspace key is pressed for the moment and take a look at what happens when the user hits the alphanumberic keys (A – Z, 0 – 9):

if(e.keyCode == 8){
    //...when the user hits the backspace key (we'll write this functionality shortly)  
}else if(e.keyCode == 32 || (e.keyCode >= 65 && e.keyCode <= 90) || (e.keyCode >= 48 && e.keyCode <= 57)){
    latestQuery = currentQuery + String.fromCharCode(e.keyCode);
    displaySearch.val(latestQuery);
    updateResults(latestQuery);
}

Key codes 32, 65 – 90 and 48 – 57 are the space bar, alphabetic keys A – Z, and numeric keys 0 – 9. Whenever the user hits one of these keys, we add the value of that key to the end of whatever the user has already added to the search input box, like this:

latestQuery = currentQuery + String.fromCharCode(e.keyCode);

If the user has so far typed “AC”, when they hit the next key (“D” for example), the “currentQuery” is “AC” and the “String.fromCharCode(e.keyCode)” is “D”, making the latestQuery “ACD”.

“e.keyCode” will return the value of the key and by using “String.fromCharCode()”, we can turn that value in the actual key being pressed.

$displaySearch.val(latestQuery);

For each key the user hits, we construct their query “latestQuery” and add it into the “display-search” input box.

When using key events and determining what keys the user is hitting, you usually don’t have to construct the contents and add it into the input box yourself, but remember we’re having to hack the input boxes a little because we wanted to remove the blinking text cursor.

Finally for the alphanumeric key down event, we have this last line of code:

updateResults(latestQuery);

This is the final function in our keycode event that passes the “lastestQuery” to the PHP to try and find a match for the users query. Let’s return to the backspace key event before going into that:

if(e.keyCode == 8){
    latestQuery = currentQuery.substring(0, currentQuery.length - 1);
    $displaySearch.val(latestQuery);
    updateResults(latestQuery);
}

Now we know how the alaphanumeric keys work, this should look familiar. On the first line, we construct the “latestQuery” again but this time, when the user hits the backspace key, we remove the last character from the latest query. Once that’s done, we update the “display-search” input box again and trigger the “updateResults” function to return results for the user.

Returning Results using AJAX

Let’s take a look at the “updateResults” function now, which is triggered whenever the user alters the contents of the input box:

function updateResults(latestQuery){
    if(latestQuery.length > 0){
        //...
    }
}else{
    $artistsList.html("<li>No results</li>");
}

First and foremost, we make sure the user has actually entered a query by checking its length. If they haven’t, we update the artists list to show there weren’t any results. The “updateResults” function will only execute when the user has pressed a key so the only time the “latestQuery” length won’t be above 0 is when the user has completely deleted their query.

Now here’s where we use AJAX and start communicating with the PHP script:

if(latestQuery.length > 0){
    $.post("auto-suggest.php", {latestQuery: latestQuery}, function(data){
        //...do stuff with the returned results
    });
}

We’re posting to the PHP script “auto-suggest.php” (which we’ll look at the contents of shortly) the “latestQuery” variable which contains the users search query. We then trigger a function which passes the “data” or the result that is returned from the “auto-suggest.php” script. Within that function we will update and modify the results list based on that new result which we’ll write shortly, but for now, let’s follow the flow of the code and take a look at the PHP.

The PHP

The php file “auto-suggest.php” exists on the server. For the sake of this demo, we’re going to include a list of static results to query but in the real world, you’d connect to and query a database.

<?php
    include ("test-data.php");
    //...
?>

The test data looks like this:

$data = array(
    "ABBA" => "?search=ABBA",
    "ACDC" => "?search=ACDC",
    //...and so on
    );

Each result is made up of a term (“ABBA”) and a URL (“?search=ABBA”). By including the “test-data.php” file, we can now query the list of artists from our main PHP file “auto-suggest.php”.

include ("test-data.php");
if(isset($_POST['latestQuery'])){
    //...
}

So once our data is included, we can test to see if the “latestQuery” variable has been posted to the PHP script (and it will have been via AJAX).

$latestQuery = $_POST['latestQuery'];
$latestQueryLength = strlen($latestQuery);
$result = array();

To make things a little easier to read, we’ll turn that posted “latestQuery” into a PHP variable and count how many characters make up that query.

It’s possible — particularly in a real world application — that the user’s query will return more than one result so we’ve also set up an array by the name of “result”, that can hold multiple terms that match the user’s query.

foreach($data as $name => $url){
    if (substr(strtolower($name),0,$latestQueryLength) == strtolower($latestQuery)){
        $result[$name] = $url;
    }
}

Now, for each item in our list of test data, we’re going to break up the item into variables, one for the term (“ABBA”), the other for its URL (“?search=ABBA”). We’ll also use an if statement to determine if the users query is contained within that term. If there is a match, we store the term and its URL within the results array. The term is used as the key and the URL its value, like so:

ABBA : "?search=ABBA"

Once the loop that matches queries to terms is complete, we finally “echo” the result array after encoding it as JSON:

echo json_encode($result);

“Echoing” the result returns it back to the jQuery script. By encoding it as JSON, we turn the whole array into a string which is easily passed between the PHP and jQuery via AJAX. If this seems a little overwhelming, imagine the jQuery and PHP scripts being the start and end points of a journey, AJAX is the road between the two points and JSON is the vehicle — containined within is the message we need to deliver between the two.

Back to the jQuery

PHP has now done it’s job and returned either an empty string (no matching terms), or a string containing atleast one matching term.

if(data.length > 0){
    data = $.parseJSON(data);
    //...code to output results
}else{
    $artistsList.html("<li>No results</li>");
}

Here we determine if the PHP script returned a result or not by checking its length. When we “echoed” the results from the PHP script, we converted them to JSON.

If there isn’t a result, we add “No results” to the list of results. If there is atleast one result, we parse the JSON — turning it into a JavaScript object — and save that into a variable.

Let’s assume the user has so far typed “AC”. Querying the test data, PHP will return two results, which when parsed will look like this:

{ACDC : "?search=ACDC", Ace of Spades : "?search=AceOfSpades"}

We can now use this string to output and update the results list.

$("#artists li").remove(":contains('No results')");
$("#results").show();

Firstly, we do some housework. In case the results list is already showing “No results”, we’ll remove that from the list. In the CSS, we also hid the results list, so if that is yet to be displayed, we’ll change its CSS from “display: none”, to “display: block”.

previousTerms = new Array();                    

Now, an easy way to update the list of results would be to clear the list everytime a new result is returned and populate it again. This causes some undesirable flashing during the refreshing of the list though. Instead, what we’re going to do, is create an array of terms, called “previousTerms”. We will then compare the previous terms (the ones currently being displayed) with the new ones returned from the PHP script.

$("#artists li").each(function(){
    previousTerms.push($(this).text());
});

For each list item in the list of results, we will add the text from that item, to the “previousTerms” array.

Let’s continue with our example; the user has so far typed “AC” and the PHP script has returned results. We’ll also assume that the list of results has so far shown each result for the query “A”. So the results we are yet to display, look like this:

{ACDC : "?search=ACDC", Ace of Spades : "?search=AceOfSpades"}

And the “previousTerms” array looks like this:

["ABBA" , "ACDC, "Ace of Spades"]

As we’re not just going to clear the whole list of results and output the new ones, we need to compare the new terms with the previous terms.

keepTerms = new Array();

Let’s create a new array that will hold only the terms we want to keep.

for(term in data){
    url = data[term];
    if($.inArray(term, previousTerms) === -1){
        $artistsList.prepend('<li><a href="'+url+'" title="'+term+'">'+term+'</a></li>');
    }else{
        keepTerms.push(term);
    }               
}

Now we can begin breaking up that string of returned results. “term” itself is the key (the name of the artists) and “data[term]” is the value (the URL). For each key/value pair, we’re going to compare the term with the terms in the “previousTerms” array. If it isn’t in the array, we add the term to the list of results (wrapped in a little bit of HTML to create the link). If it is in the “previousTerms” array (and is already being displayed), we’ll add it to the “keepTerms” array.

We’re almost there! Before we write the final step –removing the terms from the results list that no longer match the latest returned results — we need to make sure the AJAX is keeping up with the users speed of typing.

One thing to note about sending lots of querires off to a server based script is that it takes time for that to happen. We’re sending a request every time the user hits a key, which means they’re most likely changing the query quicker than the AJAX can return results. To make sure the most current result is being displayed for the most recent query, we’ll use another if statement:

if(data == "" || (keepTerms.length == 0 && (previousTerms.length != 0 || $displaySearch.val() == ""))){
    $artistsList.html("<li>No results</li>");
}else{  
    //...code to execute removal of irrelavent results
}

In any of these instances, we want to show “no results”:

• the PHP script has returned no results, or
• the “keepTerms” array is empty, and:
  • the “previousTerms” array is not empty, or
  • the search input box is empty

If you remove this if statement from the code and quickly change the query, you’ll see that the returned results do not always reflect the most current query. This final if statement rectifies that issue.

So, providing none of the above are true and there are results to show, we can execute the last bit of code.

We have two final arrays to compare, the “previousTerms” (those being displayed currently), and “keepTerms” (only the ones that are now relevant).

Again, let’s take a look at our example. The user has queried “AC” so far, and previously we displayed results for the query “A”. “The previousTerms” array looks like this:

["Ace of Spades", "ACDC", "ABBA"]

And the “keepTerms” array like this:

["Ace of Spades", "ACDC"]

By comparing these two arrays, we can single out the terms that no longer match the returned terms and remove them:

for(term in previousTerms){
    if($.inArray(previousTerms[term], keepTerms) === -1){
        $("#artists li").filter(function(){
            return $(this).text() == previousTerms[term]
        }).remove();
    }
}

For each term in the “previousTerms” array, we determine if that term also exists in the “keepTerms” array, if it doesn’t, find it in the list of results and remove it.

Conclusion

As mentioned previously, this demo queries a simple array of test data — in the real world, you’d query a database and could use better matching algorithms provided by SQL.

If you plan on using this in a real world application, I’d also recommend taking performance considerations further. It may be a good idea to limit the number of results returned as well as constructing the list of results in a variable so they can be outputted as one instead of using jQuery to output each list item individually.

This code could be quickly adapted to consider those real world factors and hopefully it’s helped you to understand how simple it is to get jQuery and PHP to communicate with each other via AJAX.

Remember you can view the demo here, download the code here, fork AJAX Search Suggest (WeAreHunted.com style) on GitHub, or comment/ask a question below.

What I’ve Been Doing This Year

Starting and Maintaining a Business

Ian Lunn Design officially opened for business November 11th 2010 but I started planning and preparing in August 2010. I didn’t get my first job until December but thankfully, ever since then work has rolled in steadily.

I feel quite lucky to have got early clients that I can proudly say I am still doing work for today. In fact, looking back, I really haven’t had a huge number of clients but the ones I have had, I’ve formed a good relationship with and they’ve continued to come back to me with new projects.

All of my work this past year has been remote. I’ve worked with people in America, Australia and the UK which completely went against my business plan. My original plan was to start off with local clients, build a name for myself and then hopefully take on clients over the Internet. I wanted to take on clients over the Internet because I felt they would be more tech savvy and I could get my hands on more creative and complex projects. This is important to note if you’re starting out as a freelance web designer: don’t just take on any projects that come along, decide what work you feel you would like to do and aim to take on those type of projects. I’ll come to this later on when I talk about blogging.

Being able to take on Internet based clients has been great and is something that happened quicker than expected. I’ve already worked for some well known clients along side web professionals I have a lot of respect for.

Maintaining a business was something completely new to me. I’ve never worked for myself before although I’ve actually found the experience quite enjoyable. I like to learn (any subject) and there’s a lot to learn about running your own business. As mentioned in previous diary entries, Business Link were a big help to me and pointed me in the right direction. I have been using FreeAgent for accounting and admin, which is a truly amazing service. I consider where my business would be today if I hadn’t of used that.

Blogging

Blogging is something I started in August 2010 as soon as I knew I was going to become self employed. It has probably been the catalyst for this year’s successes but also my biggest regret.

I decided to start blogging based on the success and recommendation of Chris Spooner — who now blogs full-time.

I didn’t initially get much success from my blogging. Stats in Google Analytics were starting to increase but I wasn’t getting any comments and nobody was getting in touch regarding potential projects. I quickly realised that writing a post each week was way too much work (especially when creating a demo or graphical piece to go along with that post). For a while I managed to post every fornight.

I started chatting to a few people via Twitter that had read my “Going Freelance” series and as I watched Google Analytics, it became clear that my JavaScript tutorials were starting to be of interest to people.

I eventually decided to make a big change and solely concentrate on JavaScript tutorials for my blog. Why? Because they were getting the most interest out of all the posts. This led me to make quite a big decision about my career in general which I’ll come to shortly.

My post about creating a jQuery map interested somebody who found the post via Google and they eventually became the first client achieved from my blog.

I continued writing tutorials — which is also a great opportunity for you to improve your own knowledge, I may add — and eventually wrote my recreation of the Nike Better World parallax effect. This post was probably online for about 3 months before it started getting popular. I’ve since received a lot of work from that tutorial.

As mentioned earlier, when working for yourself, you have a lot of freedom and can choose what work you take on. Blogging is the perfect way to stand out and show people what you’re capable of doing. Write about the work you love, and people will approach you with project proposals of a similar nature. Not only that, but blogging is a chance for you to improve your own knowledge of a subject and writing about something you may think you know, always reveals something you didn’t!

So, blogging has got me some great projects and work that I’ve really enjoyed. Because I write tutorials though, it takes up a lot of time and when I started getting really busy, blogging was the first thing I had to drop.

Deciding not to blog is something I’ve really regretted and I will try my hardest next year to get back into it, especially as it’s so important for increasing exposure and getting new and interesting work.

Feelings Toward Freelance Life

Freelancing/self employment is harder than I thought it would be but more rewarding too. It’s naive to think that when you work for yourself, you can just wake up one morning and decide to play video games instead of work — but I did! Maybe I’m the type of person to worry a lot but whenever I’m not working during 9 – 5, I feel guilty. Perhaps that’s what got me through my first year though — I’ve cared about my business and the relationship with my clients so I’ve given everything I’ve got, that has meant a lot more of my time than just 9 – 5, and my personal life has changed quite a bit too.

When I started freelancing, I made the decision to stop playing video games so I wouldn’t be distracted by the “quick” game at lunch. It turned out I dropped a lot more than this hobby though. I found I had no time for growing veg in the spring and summer (something I like to do), and time spent with my girlfriend had to become a little more scheduled. I was generally not doing minor stuff because I thought it was time wasted — like sitting in an armchair, looking out the window, eating crisps — and I got a little too strict on myself. Towards the end of this first year though, I realised that personal life and wasting time eating crisps is important. To quote Bertrand Russell: “The time you enjoy wasting is not wasted time”.

About 4 months into self employment, I went for an interview for a permanent job. I was in two minds whether to go or not. I was yet to make money consistently in my self employment. I was offered the job but eventually turned it down based on the fact that I had taken the leap into self employment and I’d be disappointed if I didn’t see it through. Only a few weeks after turning the role down, I got a big client. I earnt a good amount of money but more importantly, the potential of self employment presented itself. I’m so glad I continued.

I still talk to companies and agencies regarding potential work simply because a job interview is a great opportunity to have people listen to you talk about yourself and how good you think you are! Don’t miss opportunities like this; you get to meet new people in a similar field, improve your interview skills and if you don’t want the job, you get to say no — which is a very powerful thing!

Saying no is scary, especially in the early days when you need to earn money, but don’t underestimate its power. Saying no doesn’t mean that a situation won’t have an outcome; it means you feel confident in your position, you know what you want and won’t take anything less. It helps you and the people you interact with to understand who you are and what you do — knowing and making clear your limits defines you as a person.

I also defined myself as a professional — finally! I studied Internet Technology at university and when my career started, I ended up in more of a designers position. I’ve always been an “all-rounder” that can design, develop and market a website. I feel I have a strong level in all three but to really be successful and set yourself apart, you need to truly excel in one. My blog helped me with this decision, it was clear that people were more interested in my JavaScript tutorials and I felt more comfortable and happier writing them. I asked around and people saw me as a front end developer more than anything else. I made the leap and I’m glad I did. I’ve been able to learn so much more by just concentrating on one profession.

Feelings Toward the Year

Pleased About

I woke up this morning super excited to start geeking out in the statistics of my business. I’ve finally completed a year and jumped at the chance to gather up lots of different stats.

Financially, for a first year, I am very pleased. I earnt more than I have ever done in employment and I also earnt more than what was on offer for the job I turned down so gladly I can say I did make the right decision there.

My blog — despite the fact I have neglected it — has achieved over 10,000 visitors a month for the last few months with an average read time of over two and a half minutes — the latter being more important to me as it shows my content is valuable to people.

So, as it was my first year, everything has gone from zero to a reasonable figure that can be built on next year and at some point before the end of the year, I plan to work out some targets I’d like to reach this time next year. It’s more fun when you have stats to compare and beat!

Possibly the biggest plus-point of self employment is the fact you get to choose what work you want to take on and what you learn. I have learnt so much this year! I’ve dedicated a big amount of my time to personal projects and really got to grips with new technologies such as HTML5 (including the APIs), CSS3 and jQuery. I could never have learnt so much in a full time position.

Regrets

As already mentioned, the fact I neglected my blog when I got too busy is my biggest regret. That might not sound so bad but my blog really increased my exposure and won me a lot of work. Looking at my stats, I also consider how impressive they might be if I was able to blog on a regular basis.

Second to this, would probably be procrastination. I guess it’s a natural thing for a person to procrastinate, so maybe it shouldn’t be regretted but I certainly did a lot of it when I didn’t have work to complete — more so than in full time employment.

The problem with working from home is the distractions. I removed video games, as mentioned previously, but the fact I was at home and didn’t really seperate home life from work life had an impact. When I say I procrastinated, I don’t mean I spent half the day watching TV, I was at my computer, but checking Facebook/Twitter and day dreaming became a big distraction and the most difficult thing was just getting started and motivated.

I haven’t quite yet worked out how to better get into a productive state of mind — I think jumping straight into whatever it is you want to do is probably the only way — but I did find that managing tasks around my mood helped. For example, if I started coding but found that I was spending more time tweeting and watching videos of cats on YouTube, I’d stop that task and move onto another that maybe didn’t require as much concentration. I might have done my accounting, sent emails etc and waited for the next day where hopefully, I’d be in the right state of mind to stare at code all day. Ironically, I find I code best in a hazy “I’m not here today” type of mood — but that’s for a different blog post!

Another minor gripe I have and feel bitter enough about to mention is Thomson Local. I’ll keep it short! Thomson Local are a business directory that I signed up with to get my business details in their printed book as well as online. I paid around £350 for the year. I didn’t get a single phone call regarding potential work but I did get a hell of a lot of calls from companies that Thomson Local had sold my details to. So, I paid £350 to Thomson Local so they could make more money out of selling my details. Their sales team are also liars and very unhelpful. Don’t go with them.

What I’ve Learnt

I love to learn, not just web related subjects but absolutely everything. I’ve already mentioned that I spent a lot of time learning HTML5, CSS3 and jQuery but I’ve also learnt a lot about myself, general life skills as well as dealing with clients.

Self employment throughs a hell of a lot of stuff your way, you’ll be the “web professional” you set out to be but also an accountant, a project manager, a client liasion manager, a receptionist (turning away a lot of sales calls), a marketeer, and a tea boy/girl.

I was again, naive in my approach to self employment. The amount of time spent just getting a project started is way more than I expected. Talking to a client, telling them about how you operate, writing contracts, sending quotes and invoices is a big job and it can get a little frustrating at times but it’s something you must do and do well because it’s the foundation for your business.

I think these types of jobs I will continue to learn and get better at for a long time to come.

Some quick tips regarding this:

• Do your accounts weekly and don’t forget. Doing them often means you’ll only need to spend an hour or two a week rather than waiting a few months and spending days struggling to remember what a particular transaction was.
• If you have a client that keeps sending you little jobs (the ones that make you feel like your losing money because of the formalities involved with starting new projects), let them know it’s cost effective for you both to build up those little jobs into a bigger project. If it’s not an urgent task, they’ll be happy to wait a few weeks and save some money.
• Your contract is an evolving document, change it often to meet evolving technologies as well as to match the specific tasks for a project. If a client raises a concern because something isn’t clear, change it in your overall template so it applies to all future contracts. Get your contract read over by the company you’ve chosen for professional indemnity insurance too.
• Invest in software packages that will help with these tasks. For accounting, I recommend FreeAgent and for project management, BaseCamp. I also use eSign to send out contracts that can be signed digitally.
• Send out questionnaires to your clients after a project is signed off to ask them for feedback. Set up a questionnaire on Google Docs and send it out via MailChimp, all for free!

Plans for Next Year

To Beat this Year in Every Way

I want to earn more, learn more, and better improve my exposure.

Release Personal Projects

This year I worked on a lot of personal projects. I guess the tutorials and demos on my blog could be classed as personal projects but aside from those, I didn’t actually finish any other personal projects despite starting quite a few.

Very early on, I started working on a novelty site with a friend that looked at your Twitter account and gave you a score based on how nerdy you were. This unfortunately, I don’t think will ever be released as I have too many other personal projects I want to complete before that.

Right now, I am working on a jQuery slideshow that uses CSS3 animations. I am very excited about this as it is a plugin that is very easy to use but can be customized greatly. I expect to see lots of creative uses for it. I aim to release this before 2012.

Another project I am working on is a very small jQuery plugin and browser extension. It is based on an idea I implemented for Mozilla’s Dev Derby (which I came 3rd for!). I hope it will spur browser vendors to eventually build its functionality straight into their browsers.

Finally, I’m working on a game utilising JavaScript and HTML5s Canvas API. I plan to break this down into stages of development and create a series of tutorials on my blog. Currently the game is in a very basic form, allowing for player movement and randomly generated falling objects that the player must catch.

To Take on More Great Clients with Interesting Projects

For my first year, I’ve already taken on some amazing clients and projects. Next year, I’d like to do the same and take on interactive projects that make use of HTML5, CSS3 and JavaScript.

Conclusion

Having written this post, I am very excited for next year. I made the right decision by “Going Freelance”. Not only did I exceed my expectations regarding the type of work and clients I’d take on but I’ve also had a lot of time to spend learning and working on my own projects.

I’ve dedicated a lot of time to my first year but it’s paid off and I’m now in a position to be able to step back, take a look at what I’ve achieved and improve upon it next year.