The most valuable piece of code I ever wrote

    Thinking about a planned interactive feature for the OxfordWords Blog recently I was reminded of a little piece of Javascript which is probably the most valuable piece of code I ever wrote. Valuable in terms of revenue generated for the customer that is rather than value to me, for it took a very short time to write.
    It was a mid afternoon in 2007 or 2008 when one of my customers at the time rang up with an idea for a little feature for his web site. His company is a rather large second-hand vehicle specialist and he's one of those customers for whom I have a lot of respect. No-bullshit, but fair in return and one of those guys you can learn stuff from.
    The second hand vehicle business works over the telephone, if they can get you on the phone they're pretty good at persuading you to part with your cash to drive away in one of their machines. Their conversion problem therefore lies in getting the customer on the phone in the first place.
    So their site, a large catalogue of vehicles, was and still is plastered with their phone number. No need for a shopping cart or online payments, their industry has enthusiastically gone online but their customers still like to deal with someone directly when parting with cash.
    The problem facing my customer was that his conversion rates were still pretty low. Our spiffy site was generating him lots of traffic so he knew the customers were interested, but they were browsing and shopping around rather than giving him a ring in sufficient numbers.
    His idea was a simple one. If they stop on the page for a particular vehicle for any length of time, they must be interested in it. So he asked me to make a little pop-up that asked the question "Do you want us to call you about this vehicle?" the first time a customer stopped on an individual vehicle for more than a minute. Fill in your name and number, click the "Yes" button, and an email went off to his salesmen who'd give you a ring.
    Coding it took about half an hour. A hidden div containing the HTML form, a little bit of Javascript with a timer to unhide it after a minute, a bit of code to set a cookie so the user didn't get bothered by the form more than once, and an extra address for his form-to-email script. Nowadays I'd use a line or two of jQuery code and probably a fade or something, but back then it was straight Javascript. Still, hardly a big job, and I had it ready for his approval by the end of the day and live on the site the next day.
    A second-hand vehicle dealer like my customer buys his vehicles at auction, mostly not very old vehicles in bulk from the fleets run by large corporates. He then services them and gives them a current MOT test and warranty before offering them to his customers. His is the reputable end of the second-hand vehicle market so his customers pay a premium for good quality vehicles with a provable history, something they can't get from dodgy used car lots. He thus has quite a high turnover and running cost, but the margin on each vehicle sold is also fairly large. If he sells a vehicle by a means that didn't cost him much money, he's made a four figure sum.
    Hence my half-hour piece of Javascript was the most valuable piece of code I've ever written. Because it provided him with many more conversions from his web site at a very low cost, the first vehicle sold through it paid for it many times over and it made him many thousands of pounds thereafter. I'm guessing over the years it will have generated an astounding amount of money, for even though the company I worked for then has since folded in the recession and the customer's site now runs on a different platform it still features an updated version of my pop-up form.
    I'm glad that it was such a small piece of code that did so well for my customer. The customer went away happy and rewarded us with more business and lots of word-of-mouth recommendation, and I learned something important about calls to action and that not all industries fit the same web shop model.
    If only all my code proved to be of such value to the people paying for it!

What was that about "Don't be evil"?

    I'm sure most readers of this blog will be familiar with the famous Google motto "Don't be evil". Having had the chance to look at Google culture from a viewpoint slightly closer than the average Joe it comes across as something taken pretty seriously within Google. When they say that, they really mean it.
    "Being evil" is generally taken as a reference to some of the shady practices found elsewhere in the tech industry. Really good examples of "Being evil" can be found in the history of Opera Software, as the underdog in the browser race they faced over a decade of unfair practices from the developer of the dominant browser.
    But things are different now, aren't they? MSIE is no longer the top dog, and there's a new kid in town. Chrome, from Google, and they have that "Don't be evil" motto, don't they?

    I use all the main browsers, I'm a web developer. I use Opera quite a lot, it's a damn good browser, just like Chrome or Firefox. I'm also a Google user, you might say I've drunk the Google Kool-Aid. So seeing screens like these three from flagship Google services running in the latest version of Opera (12.00) distresses me.

 I develop interactive web sites that work with all major browsers. Chrome, MSIE, Firefox, Safari and Opera. It's standard web developer stuff, not difficult at all. The web is full of HOWTOs, compatibility libraries and guides for the novice developer, so I'd expect the kind of experienced developers Google hires to have no problems writing code that works cross-browser. It's hardly as though Opera makes it difficult anyway, it's one of the most standards-compliant browsers on the market.
    So what I'm seeing is a major browser developer not making the effort to support a smaller competitor's product in their web servicess when I know that supporting that product is straightforward for a competent web developer. And then using the lack of support to display a message pushing users of the smaller competitor product to their own offering.


    "Don't be evil" is Google's motto. It pains me slightly to say this, but as an Opera user I don't think they're living by it here. Come on Google, step up to the plate!

MSIE overtaken

    Back in April I wrote a piece about the rise of Google Chrome and the pending loss to MSIE of the number one browser slot. Based on StatCounter GlobalStats data I predicted that this would happen in June.

    I was wrong. It happened in May. Finally we're in an era in which supporting outdated, insecure, and non-standards-compliant browsers is no longer considered a priority.

    It would be tempting to slam MSIE. Hell, the product deserves it! But I hope losing the top spot reveals Microsoft at their best. When they're top dog they don't behave well, but when they're the underdog, they innovate. It would be great to see a future version of MSIE that really gave Chrome and Firefox a run for their money, a super-fast, secure, up-to-date, non-proprietary, and standards-compliant browser.

    Well, I can hope, can't I.

Preparing for MSIE Overtaking Day

    It's been a trope of the web developer's existence for the last decade: Microsoft Internet Explorer won the browser wars in the 1990s, all other browsers are irrelevant. The customer has this firmly lodged in their heads from the days when MSIE had over 90% of the market and demands support for IE in all its forms over support for any other browser. We may just about have won the war over abandoning IE6 support, but we are still demanded to code in all the workarounds demanded by its just-as-creaky younger siblings.
    It might have been true in the mid-2000s to manipulate the famous phrase about IBM to "nobody ever got fired for supporting MSIE". But as a quick look at StatCounter's Global Stats will tell you, over the last couple of years Google Chrome has come from nowhere and is rapidly converging on MSIE's market share. Extrapolate the graph forward a few months, and it becomes obvious that sometime this summer, probably in June, Chrome will overtake MSIE as the world's most popular browser.

    That's right, June 2012 will see MSIE Overtaking Day.

    You might think it would be unwise to break out the champagne though. After all, the top spot is just passing from one big company to another, won't it just be a case of "Here's the new boss, same as the old boss"? In that we're fortunate: unlike MSIE with its proprietary approach to rendering HTML, Chrome is a Webkit browser, underpinned by open source and web standards. So if we code to those standards we can expect it to work without too many tweaks on all browsers that support them.

    No more browser-specific stylesheets, no more special Javascript hacks, no more compatibility libraries.

    But the title of this piece is "Preparing for MSIE Overtaking Day". We're already there, as developers we're used to coding web standards, all our sites already work in Chrome, Firefox, Safari and Opera. It is the non-technical people who need preparing, all those marketing people at the customer, the legal people and the developer project managers who are stuck in that 2000-era trope. I was shocked not too long ago to encounter a site whose contract specified individual browser versions. Not even "version X and above", so when a legitimate bug was reported in a recent browser the response came back that it wasn't supported because the browser wasn't several years old. That kind of thinking is simply not acceptable.
    So we have to think away from the browser in the post-MSIE world of frequently released standards-compliant browsers. We have to sell web standards such as HTM5 rather than support for particular browsers to the non-technical people we encounter as web developers, and we have to hammer home that message using the clearly visible statistics.
    Otherwise we'll still be coding for MSIE7 in 2017 just like some of us had to support MSIE6 in 2010 And that just ain't funny, not at all.

An AJAX and jQuery driven web feature, the OxfordWords Text Analyser

    If you are a follower of the OxfordWords Blog, you may have seen the launch of the OxfordWords Text Analyser, coinciding with the 200th anniversary of Charles Dickens. Here follows a technical description of the feature, what it does and how it works.
    The challenge was to show the logophile visitors to OxfordWords some of the computational linguistic techniques used in the preparation of the Oxford English Corpus, and thus give some insight into the preparation of a modern dictionary.
    Finding ourselves unable to share the corpus itself with the public, we settled on the idea of  delivering a much smaller text with similar analytical techniques applied to it to those used by our corpus analysis software. Since we already publish a huge range of classic texts in the Oxford World's Classics range it made the most sense to use those as our sources and provide collocate and frequency analysis as well as example sentences for each text. This presented a data problem: to incorporate all this in a single web page would mean adding several megabytes of data to the page, resulting in an unsustainable page load time.
    The obvious solution was to create a lightweight page containing just the Javascript display code, and deliver all the data on an as-needed basis via AJAX calls. There was a time when writing this to work reliably on all browsers would have been the bane of a programmer's life, but fortunately we now have the jQuery library to abstract such nasty jobs from the programmer, so taking that route was a no-brainer decision.
    AJAX having been decided upon, the next decision related to the server-side component. I wrote a piece about this last summer, about how experience of database driven back-ends for language analysis had led me to precomputing data as json files rather than querying a database. Disk space is fast and cheap, server processing power isn't. So my next task was to write a set of command-line PHP scripts that generated a tree of JSON files for each word in the source text, containing collocates, frequencies and example sentences.
    While these tasks are essentially simple ones, they are quite computationally intensive. In a typical Dickens novel for instance, there will be as many as 20000 unique words, and every one of those words needs to be searched for across the whole text and the frequency of its colloscates in all the locations it appears in computed. The whole process takes about six hours, and produces a roughly 20Mb tree of thousands of tiny JSON files which are then uploaded to the web server.
    So that's the surprisingly low-tech backend for the feature, how about the front end?
    The core functionality of jQuery makes coding an application like this very simple. The three main parts of the feature live in hidden DIVs which are shuffled using the jQuery show() and hide() functions. TheJSON data is pulled in using jQuery's getJSON() function. Collocates are shown in a word cloud courtesy of the excellent jQCloud plugin, example sentences are simply loaded into an unordered list, and frequency graphs are created using Google's Image Chart API.
    These plugins and code made a working feature. But to make a single-page jQuery application like this one feel like a proper application, there was one further component required. Users expect to be able to use the back button, and to be able to return to a particular part of the application by URL alone. Miss Havisham's dress needs to be readily conjoured up by linking directly to the word "bridal".
     We thus used the jQuery-BBQ plugin to provide URL and history functionality through the use of in-page anchors. Because the page can't be reloaded, the plugin appends the word to the end of the URL after a # symbol as it triggers any changes to what is displayed.
    In summary, the use of precomputed JSON files made the server-side compontnet of this feature very simple at the expense of using more filesystem space, and the use of jQuery and its plugins made client-side development a lot faster and more reliable across browsers. Sometimes libraries like jQuery are used for the sake of it when simple Javascript would have sufficed, but in this case I believe its use made for a far better application.

Testing an HTML placement for third party sites

    Writing an HTML placement for third party sites used to be so easy. Back in the bad old days of tables and frames, you simply created a little table with all those nasty width, height, cellpadding and cellspacing attributes and called it good. You knew you had a pretty good chance of it working as you intended it to on pretty much any site it would be placed on.
    CSS has changed all that. Our HTML is much cleaner and easier to understand because all the styling and layout has moved into the style sheet, but placing outside code into a CSS page is now fraught with danger. The Cascading bit of Cascading Style Sheets means that the developer has to be extremely careful to ensure that no stone is left unturned and no opening has been created for a global style declaration to affect the placement styling. All of which leads to excessive amounts of inline styling that rather negates the point of CSS to create cleaner code.
    The placement below is an example. Created as a search box for the Oxford Dictionaries Online site, it should work with all modern browsers and degrade gracefully with older versions. But as all developers know, you can test something on everything you have and there will still be a platform out there that will trip you up.
    And true to form, on first load something's changed the formatting. Watch this space, CSS tweaking at work... Carriage returns replaced with <br> tags by the WYSIWYG editor. Lose the carriage returns and there it is.
    Oh well, that's Blogger ticked off the list of platforms it's been tested on.

Free online English dictionary from Oxford