The BBC’s central team of web developers has been talking about starting a blog for quite a while now. While our friends over in Radio Labs and Journalism Labs have been busily sharing the fruits of their hard work, it’s all been a bit quiet over here. So, before we begin: a quick apology (sorry we’re late), and a quick explanation.

var_dump($this->explanation);

One of the reasons for the delay is that, despite the mention of a ‘central team’ about two sentences ago, there is no main set of people that builds bbc.co.uk. Instead, there’s a teeming colony of developers and designers of all kinds, spread over a huge range of different projects. It turns out that arranging for a representative group of these people to write articles is a near-impossible task, so a few of us are just going to start writing about what we do, and hope for the best. As with most things in web development, if something needs to change along the way, we’ll change it.

glow.dom.get("#plan");

The Internet Blog already exists, of course, and designers and developers often appear there to explain what they’ve been up to. Normally, though, it’s a place for major announcements and discussion of the big issues. This new blog will be from people who spend their days up to their eyeballs in the nitty-gritty of building bbc.co.uk. It’ll be less about the grand scheme of things, and more about the details of how things work – and often don’t work – down on the front line. If the Internet Blog is the view from General Melchett, this is Blackadder. And, inevitably, Baldrick.

If all goes to plan, over the coming weeks you’ll hear from a good selection of people. The person who builds the main page template of bbc.co.uk (which means chunks of his code have been rendered about 5000 times since you started reading this sentence) will, for example, be going into depth about how it all works. The people who build BBC iPlayer will, amongst other things, explain some of the advanced CSS techniques they’ve been experimenting with. The Jedi from the Glow team will tell us about the thinking that’s going into future releases of the BBC’s open source Javascript library. And other developers from teams with exciting and top-secret names will write about their plans to introduce some completely new things to BBC Online.

As we go along, some posts will be about code, some will be about the code behind the code, and some will be trying to tie it all together into some kind of grand unifying theory of everything. If you’re involved in the web, or are just curious about how things work behind the scenes on a website like this one, hopefully you’ll find some good food for your feedreader.

View full post on Web Developer

No tags

Hi, I’m Frances and I work on Glow, the BBC’s JavaScript library, alongside Jake, Michael and Stephen. We’re looking forward to keeping you up to date on what’s going on with the project on this lovely new web developer blog.

The big news this week is that we’ve released Glow 1.7.0, which is now available to download. This release focuses on stability and overall usability; we’ve fixed a number of bugs, added handy new features to the DOM module, and improved accessibility for some of the widgets. Here’s a quick overview…

The core glow.dom.NodeList class gets a range of new methods:

• ancestors() – get all the ancestors of a node
• data() & removeData() – associate arbitrary data with elements in a memory efficient way
• scrollLeft() & scrollTop() – get and set the scroll position of the document or elements
• wrap() & unwrap() – add and remove parent nodes to elements

The AutoSuggest widget also receives a bit of attention. We have made a few UI bug fixes, changed the behaviour of the left/right keys to be more consistent with similar interfaces (such as Firefox’s search box). There are also some new events, the option to filter model data before it is displayed and an way to control the caching of data from URLs. You can also disable the text highlighting feature that is used by default when using the “complete” option.

Other changes include the addition of heading and list formatting options to the Editor widget, and an improvement to the glow.net module’s handling of XML returned with the wrong mime type.

Last but not least, we have also improved some of our accessibility features. The Overlay widget now prevents focus from going to other elements when set to “modal”, InfoPanel has better ARIA support and the Slider widget has more intuitive keyboard access for screenreader users.

Take a look at the 1.7 overview page for more details, including the full changelog.

If you’re interested in knowing more about Glow, or even if you’re already using it, we’ve got plenty of ways for you to get in touch with us:

• Google Group – join in at glow-users
• IRC – join us on irc.freenode.net in #glow
• Twitter – follow us at @bbcglow

View full post on Web Developer

No tags

Hi, I’m Mat, and I work on bbc.co.uk’s page layout system, Barlesque. You may have seen it, and its amusing name, discussed before over on the BBC Internet blog, but here I’m going to give you a bit more of a technical insight into how it actually works. Before that though, a quick 140 characters on what it actually does:

Barlesque delivers the head and foot of every page on bbc.co.uk, as well as all the pan-site modules: registration, survey, advertising etc.

There’s lots of things I want to talk about at some point: download efficiency for millions of page views per day, writing front end code to play nicely with other people’s code, making Barlesque available on lots of different server environments, and so on. However I’m going to start with one of the very first client-side features we wrote: a CSS reset.

Resetting the scene

A CSS reset is a snippet that zeroes CSS values for all elements – zero padding and margins, no borders, 100% font sizing and so on. They’ve been around far longer than Barlesque, for example this one from (the extremely smart) Eric Meyer.

When investigating them for Barlesque, we pretty quickly decided a reset would be of overall benefit to developers on bbc.co.uk: we have a lot of browsers to support and zeroing everything would get rid of those inconsistent default values, like paragraph margins for example, that different browsers have. Also, with so many developers swapping code, moving around the business, debugging each others work and so on, it would be a big win to have everyone’s stuff starting from the same known base.

Looking round, though, there were a few things used in some existing resets we weren’t so keen on; for example:

• Setting a load of values on every element, particularly containing elements like <div>s, makes a right mess of Firebug’s CSS inspector – it’s a long statement, and if you nest some elements (e.g. an <a> in an <li> in a <ul> in a <div>) then Firebug puts it in the pane multiple times (as shown in the screenshot opposite).
• Some stronger resets were putting font-weight:normal on strong, taking the italics off, or other things which I felt would break developer expectations.
• Outline was sometimes removed, however it’s important for keyboard navigation.

So we made a key decision for our reset: We’d only change values that varied between browsers. For example since all browsers default to zero margins, padding and borders on a div, we left it alone in the reset.

We did this by making some sample content using all commonly used elements and trying it in lots of browsers. For the fine tuning we took a screenshot the content, then setting that picture as the background to the file so we could see if other browsers overlaid it perfectly.

In doing this we were also able to break the reset down into multiple declarations, thus ensuring it didn’t interfere too much with Firebug.

Here’s a css file containing the uncompressed reset code as it stands now.

regret.css

Of course, there were one or two ‘issues’ along the way. In the process of trying to get the test page to look consistent, we used list-style:none; on lists, which breaks expectations and causes support queries to this day, but which we can’t change without breaking backward compatibility. (Sorry about that, bbc.co.uk devs.)

A more major thing we’d consider changing if we got to do it again is that we’d probably avoid zeroing typographical values, instead applying default padding, margins and header sizing. This wouldn’t require any more CSS for those who didn’t want the default, but would mean those who didn’t mind it would need no code at all. You live and learn. Instead we’ve provided a default typography class to help those without a specified typography in their designs.

Classy

So that’s the basic reset. However, as mentioned before, developers do share code quite a lot around the site. This sometimes means dropping one developer’s front end code into a page amongst another’s. We thought it would be handy if the reset was available as a CSS class as well, to act as the foundation for embedded snippets. This did mean making more declarations, because it has to override what the sites may have defined, rather than just what the browsers differ on. It’s also made more verbose by having to prefix all the elements with the class name (in this case “blq-rst”) so this one really does make a mess in Firebug… but at least it’s optional.

Coincidentally, the first customer for this reset class was actually Barlesque itself: the masthead and the footer of the page were exactly the sort of snippets that could do with a bit of protection from page-wide declarations made by the sites. Add .blq-rst and they stay looking ok, as this test page shows.

Of course, Everyone has their own take on these things, so comments and suggestions are welcome as always.

View full post on Web Developer

No tags

Now we’ve got Glow 1.7 out the door, our minds are turning towards planning for version 2, our next major release which will be out in the new year. We’re planning a significant overhaul, and as the major version increment indicates this will include a fundamental rewrite of large portions of the library.

Now is also a great time for users and contributors to get involved. Please tell us what you’ve liked and disliked about version 1, and what features you’d most like to see in version 2.

We have produced a set of four themes that we’d like to explore in Glow 2. These might get you thinking about what your perfect desert island library would contain, or maybe you think we’ve missed something vital?

• Accessibility – provide a step-change in accessible and usable widgets
• Performance – reduce load and execution times to the bare minimum
• Design – build widgets that look fantastic alone or in combination
• Community – open up the project and help the community thrive

We really want to hear what you think. If you’d like to talk to us about your ideas then join us on our mailing list, chat with us on IRC or you can send @bbcglow a message on twitter or by adding the hastag #bbcglow2 – we’ll do our best to respond to everyone who sends us a suggestion.

View full post on Web Developer

No tags

It’s taken a lot of work, and there’s plenty more to do, but BBC iD is now starting to appear across BBC Online.

There’s an article over on the BBC Internet Blog that explains what this means if you have an existing account, and outlines a few of the changes you can expect over the coming weeks. If you have any problems, you can find answers in the new FAQ section.

As well as supporting existing services, BBC iD will evolve to allow us to start building some new and previously impossible things. This, as they say, is just the beginning… and we’ll explain some of the developments here as we go along.

View full post on Web Developer

No tags

Hi, I’m Ben Smith, and I’m developing a new set of web services that add social features to BBC Online. Starting this project was clearly an exciting prospect, but without a handy crash course on how to get going, we ran into our fair share of problems. Now that we’ve solved a few of them, I thought I’d better start writing about it.

Forging ahead

The BBC’s overall web architecture has been rebuilt over the last couple of years, and a new breed of websites is now starting to appear (the platform’s called ‘The Forge’, and you’ll hear more about it soon). In a nutshell, these new sites are delivered through an application layer that relies on making HTTP calls to RESTish web services to get the data they need.

If we want to develop something social, we need some social web-services, and you don’t have to look too far into this before the OpenSocial RESTful specification jumps out and does a little dance in front of you. (Well, that’s what it did for me, but I may have been drinking too much coffee.)

It’s Open and it’s Social

OpenSocial defines a common set of APIs that applications can be developed against. The REST API allows applications to make HTTP requests, and get back things like a list of a user’s friends

/people/<userId>/@friends

or their recent activity

/activities/<userId>/@friends

Lovely stuff. Not only do we have a specification to work to, we have a popular one that many applications have already been developed against.

Additionally, to aid in the development of OpenSocial-compliant sites, the Apache Incubator project Shindig provides OpenSocial implementations in both Java and PHP. As the BBC’s new platform is particularly fond of developing web services in Java, it’s all looking pretty good.

Is that it?

Unfortunately, life is never that easy. OpenSocial is designed to be a generic API to present your data through, whether you’re a Google, a MySpace or a jonnynewsite.com. But different websites have different needs: different relationship models, and various data and business logic around the creation of things like new users or relationships between them. It would be presumptuous of OpenSocial to define how a website should approach them, so it doesn’t.

For example, while OpenSocial allows clients to get a user’s information:

/people/<userId>/@self

it doesn’t define a way to create a new user. So we have to do these things ourselves.

A bit of a Shindig

Shindig, the OpenSocial container implementation, quite rightly implements the OpenSocial specification and no more. As everyone will have their own infrastructure, with different databases, key-value stores and identity systems, Shindig defines software-level interfaces for you to implement. So, for Shindig to be able to respond to:

/people/<userId>/@self

you need to implement:

Future<Person> getPerson(
    UserId id, Set<String> fields, SecurityToken token)
    throws ProtocolException;

which is defined in the PersonService interface.

Extending OpenSocial

The BBC website has no social graph or any real social features to speak of. This meant that when we started, we were presented with an interesting opportunity: with no existing system to integrate with, could we extend the OpenSocial spec, and Shindig itself, to provide the features we were missing?

As I mentioned before, OpenSocial allows clients to retrieve a user’s friends:

/people/<userId>/@friends

So, to create a friendship between two users that’s consistent with the existing API calls, it seemed reasonable to POST a document (JSON in this case) that contains the new friend’s userId to the same URL:

POST {id: ‘<friendId>’}
/people/<userId>/@friends

Some may argue that a PUT to:

/people/<userId>/@friends/<friendId>

would smell more RESTful, but it’s not really any better and, considering the criticisms of OpenSocial’s RESTful-ness, keeping the API consistent was most important. However, if we were, say, keeping a description of the type of friendship (colleague, family, etc.) then we would need to be able to update that metadata, and would have PUT to the specific friendship resource:

PUT {type: ‘colleague’}
/people/<userId>/@friends/<friendId>

Extending Shindig

To add this function to Shindig, it’s a matter of extending the right bits. I’ve created a repository on github.com that shows how you can do this, but it’s worth saying that this isn’t production code, especially as it is backed by a non-persistent JSON store (and probably has more bugs in it than a student’s beard). As I mentioned earlier, Shindig specifies a service layer for you to implement. Conveniently, they also provide a sample implementation that persists to an in-memory JSON store which is populated with dummy data.

Shindig is sensibly split into layers: the domain model layer, the service layer, and the request handling layer (there’s actually a lot more to it than that, but you can read about that here). To extend the RESTful API you have to define the new endpoint in the appropriate handler, and a service that will administer the appropriate model objects.

So, to allow clients to POST new friendships to /people/<userId>/@friends, you must firstly extend the PersonHandler:

@Service(name = “people”, path = “/{userId}+/{groupId}/{personId}+”)
public class PersonHandlerImpl extends PersonHandler {

Now you can implement a createFriends() method that will respond to POSTs to /people/<userId>/@friends:

@Operation(httpMethods = “POST”, path = “/{userId}+/@friends”)
public Future<?> createFriends(SocialRequestItem request)
    throws ProtocolException {

You can see exactly how this is done in PersonHandlerImpl. The annotations are Shindig’s own home-brewed routing mechanism, but they’re pretty standard MVC controller fare. The handler itself shouldn’t do the work of creating a friendship, but should leave this to a service interface for the management of relationships:

public interface RelationshipService {
  public void createRelationship(String personId, String friendId);

Now you have to implement the RelationshipService, in much the same way as you need to implement Shindig’s own standard services. As this is an example I simply extended the JSON implementation to include a fleshed out createRelationship() method:

public class JsonDbServiceExample extends JsonDbOpensocialService
    implements RelationshipService {
  public void createRelationship(String personId, String friendId) {

Dependency issues

This is all fine and dandy, but how do any of these pieces actually know to use each other?

Shindig uses Google-Guice, a lightweight dependancy injection framework, which you use to tell the system that you actually want to use your handler and service implementations over theirs. To do this, you simply reference your own GuiceModule in your web.xml or tests.

It’s also worth mentioning that you can integrate Shindig and Guice with Spring, which also provides dependancy injection and is very popular, as Chico Charlesworth documents on the Shindig wiki.

Anyway, if you fancy trying it out, git clone the example and, assuming the code still works, tinker to your heart’s content.

View full post on Web Developer

No tags

Hi, I’m Giv Parvaneh, and I’m a senior PHP web developer at the BBC. When I started working here earlier this year, I quickly realised that I would have to re-think the way I develop web applications. As a public service and one of the most visited websites in the UK, the BBC has an obligation to deliver quality products; the websites we build not only have to conform to web standards and be fully accessible, they need to be scalable to handle millions of users. Quickly hacking things together isn’t really an option here…

The need for speed

Developers at the BBC tend to use Agile methodologies as a way to quickly release iterations of products. But where does rigorous code testing fit in with the short development and release cycles? How can we maintain the quality of our code when things need to change so fast?

A confession

OK: I’m guilty of releasing untested code in the past, where I’ve needed to meet deadlines. I’m probably not alone. And if you’re a developer who’s worked in a big team, you’ll know that often you’ll have to work with code that was written by your predecessors or contractors who didn’t create ‘test-friendly’ code. Often this means having to waste time re-writing the code so that it can be tested. Naturally, this eats into your valuable development time during sprint cycles.

The Agile Manifesto states that we should value “Working software over comprehensive documentation“. Some might see a problem here, because this seems to place a higher importance on “working software” than the quality of that software. The way I see it, you can’t truly maintain “working software” if it’s not well-tested… and the truth remains that many developers compromise good test coverage in order to complete tasks by the deadline. So what can we do?

A compromise

One thing I love about Python is its built-in support for documentation and testing. Even if you’re not in the habit of writing unit tests for your code, you should at least comment your code so that you and other developers know what your classes and methods do. Python’s “doctest” kills two birds with one stone: as you write your comments, you can optionally specify how the code should be used and what the expected outcome should be. Comments now serve as valuable documentation for your code, and can be executed as a test to ensure your logic is intact.

This method is not supposed to replace unit tests. In fact, there’s only so much you can do with doctests, and your code can quickly become a huge mess if you try to write too many. But the idea is that they can be quickly used when you don’t have time to write a full test suite. Some tests is better than no tests.

Let’s have a look at an example in Python first:

def greetings(your_name):
    return 'hello, %s!' % (your_name)

This function takes a person’s name as an argument and returns a greetings message. Let’s add this description and a test to the docs:

def greetings(your_name):
    """
    This function takes a person's name and
    returns a greetings message
    >>> greetings('Auntie')
    'hello, Auntie!'
    """
    return 'hello, %s!' % (your_name)

When you execute this script, Python is smart enough to know “>>>” means the comment needs to be interpreted as code and what the returned value should be.

We use PHP at the BBC, so I did some research and came across a PHP equivalent called PHPDT, which can be installed via Pear. Here’s the PHP version of the above function:

/**
* This function takes a person's name and
* returns a greetings message
* 
* greetings('Auntie');
* // expects:
* // 'hello, Auntie!'
* 
*/
function greetings($your_name)
{
    return 'hello, ' . $your_name . '!';
}

You can test this by running $ phpdt example.php in your terminal. The comments inside the <code> tags will be interpreted as PHP code.

Testing times

These are simple examples, but you can see how easily you could combine your comments with some testing to make sure that any accidental changes in your code are caught. Again, doctests aren’t meant to replace unit tests, but they might help to keep things working when you’re faced with the need to write code faster than your tests can keep up.

I plan to try adding doctests to my code, as well as continue writing proper unit tests in PHPUnit. I’d be really interested to hear from anyone who has tried this approach: on large applications, is this a good way to move fast without letting your test coverage slip?

View full post on Web Developer

No tags

Text fields in forms need to have labels, so that people know what they’re meant to enter into them. Next to a username field, for example, it’ll say something like “Enter your username”. The HTML you’d use for this would involve a <label> tag, with id and for attributes tying everything together. The association between <label> and <input> lets the browser know which hint applies to which field.

Username

<label for="username">Username</label>
<input id="username" type="text" />

When properly associated like this, the label becomes a handy way for users of visual browsers to send focus to the field. Users of non-visual browsers, however, need the label to be there so that when the field is reached, there is any information about it at all.

Multi-labels

The pairing of one input tag with one label tag only allows space for one chunk of text for each field. It’s not unusual for a design to call for more than one chunk to be associated with a field, often with the second one appearing elsewhere on the page.

This design pattern often appears when we need to explain more than one thing about a field: the fact that the username can’t contain spaces, or that it needs to be more than a certain number of characters, for example. It’s also a common way to show feedback after form validation.

Can’t we just add more labels?

Sadly, no. You might think that if you need two labels, you could just use two label tags. But as Roger Johansson pointed out in an article over at 456 Berea St a while back, this appears not to work. Generally, only one or other of the labels is noticed by screenreaders.

As a result, out in the wild, extra bits of hint text usually end up separated from the label, inside another tag, with CSS then positioning them according to the design. The HTML generally looks something like this:

<label for="username">Username</label>
<input id="username" type="text" />
<span id="username_info">Pick a name to use on this site.</span>

The problem with this approach is that the second hint chunk won’t always be read out by screenreaders, as only the main label tag, “Username”, is explicitly associated with the input. To use a common but sometimes hard-to-pin-down phrase, this way of doing things is inaccessible.

A quick aside about forms mode

When interacting with forms, some screenreaders enter ‘forms mode’. This switches the keyboard over from page navigation (using the keys to jump to different parts of the page) to allow regular text input. This allows you to type your username, rather than perform browser-related shortcuts. In this mode, only form-related tags are read out. Other tags (apart from links) tend to be ignored as you move around the page.

This means that if the text in your second chunk of label text is important, it may be ignored. This could be a problem:

<label for="user_code">Please enter your user code</label>
<input id="user_code" type="text" />
<span class="hint">but only if you want the nuclear reactor
	 to shut down immediately</span>

The importance of being important

If the additional chunk of text isn’t vital for users to read, then you might say it doesn’t matter that it’s not available to screenreaders. In the example above, the hint text “Pick a name to use on this site” is arguably not as critical to understanding the form as the nuclear reactor label. But if something’s important enough to be in the page, then – all other things being equal – it should be available to everyone… otherwise, it arguably shouldn’t be there at all.

Two for one

Time for some actual answers. Provided we don’t use it as an excuse to write an essay inside the label tag, a solution to the ‘two labels’ problem is to place both the main and hint chunks together. As they’re both important to understand, it’s really just one label anyway.

<label for="username">
	<span class="main">Username</span>
	<span class="hint">must be more than 5 characters</span>
</label>

<input type="text" id="username" />

If a screenreader reads this out, however, it’ll join the two hints together as if they’re a single sentence, and this might sound slightly odd. To make things read more sensibly, we can insert a hidden full-stop. This makes the screenreader pause for a moment and read the two chunks as we might expect them to be read: “Username [pause] must be more than 5 characters”.

<label for="username">
	<span class="main">Username</span>
	<span class="hide">. </span>
	<span class="hint">must be more than 5 characters</span>
</label>

<input type="text" id="username" />

Presentation

There are lots of ways that you might want to present the label and its hint text, and even more approaches to the CSS. But to separate the hint and place it below the field, you could do something like this:

#container {
	background-color: #eee;
	position: relative;
	width: 270px;
}
#container label { display: block; line-height: 1.5em; }

#container span.main {
	font-weight: bold;
	display: block;
}

#container span.hint {
	display: block;
	margin: 1em 0 0 0;
	text-align: right;
	font-size: 0.9em;
}

#container input {
	position: absolute;
	top: 0;
	right: 0;
	width: 13em;
}

.hide { position: absolute; left: -2500px; width: 1px; }

Which turns out like this:

Username
.
must be more than 5 characters

Potential issues

Nothing is ever simple, though. While this technique works well, it doesn’t work everywhere… and in particularly quirky cases, we can end up with a situation where nothing is read out. This is, of course, exactly the problem we were trying to solve in the first place…

Voiceover 3.0 on Mac OS X, for example, appears to ignore elements inside the label that are set to display: block; this problem doesn’t seem to happen in earlier versions. And using absolute positioning to move the hint chunk into place can, in some situations, cause problems in JAWS. More work needs to be done to pin this one down, but it seems to involve the vertical height of the hint relative to the main label, and which elements (the label and the spans) are set to display: block.

One way to resolve this, although it’s a shame to have to do this, is to add the label and hint text as a title attribute on the input tag:

<label for="username2">
	<span class="main">Username</span>
	<span class="hide">. </span>
	<span class="hint">must be more than 5 characters</span>
</label>

<input title="Username. must be more than 5 characters" type="text" id="username2" />

In the absence of a label, the title is read out by Voiceover as if it was working normally. When things are working as expected, the title should be ignored in favour of the label.

hammer.crack("nut");

In summary…

• Form <input> fields need to be properly paired with a <label> tag
• Screenreaders in forms mode tend to ignore anything other than single <label> tags
• If you need to add more than one chunk of text to a label, try putting both chunks inside the label, and then moving the chunks into place with CSS
• Use hidden full-stops to make things flow as expected
• Always test what you’ve done as widely as you can, because these things can be unpredictable…

This is a tricky problem, so if you have any thoughts or suggestions, or have a chance to try these examples in assistive devices that you have access to, it’d be great to hear from you.

View full post on Web Developer

No tags

A little while ago I was talking to our interaction designer Pekka about a link we had in the masthead that was under-performing. We suspected it was the wording that wasn’t working, and after thinking up a few possible options Pekka said it would be great to be able to “A-B test” some of them. This led to some blank gawping from me, and so in turn to an explanation from him.

It turns out ‘A-B testing‘ is a way to show different options for part of the UI to two (or more) groups of users, and then monitor what they do as a result. This can be done in normal user testing of course, but more interestingly it can also be done on a live site with large numbers of users – getting real world results on a statistically valid scale. In our very simple case we could show the different wording options to different groups and see which one generated the most clickthroughs.

This sounded like a great idea, but not something I could fit onto the project backlog at the time. Luckily, some teams here set aside a little time within their project planning specifically to let developers ’scratch that itch’. No, not like that. I mean work on something that’s bothering them rather than whatever’s needed next in the project. Our team uses a gold card system within our normal project planning process, Scrum, to give us up to a day a fortnight for this.

Thus I decided to spend a day writing this mechanism for doing A-B testing on bbc.co.uk.

The code

The JavaScript is split into two parts. The first is used for new visitors, and, aside from checking the function’s configuration is valid, simply uses the probability value to decide whether the user is going to be part of the test, and cookie them accordingly.

The second is used for those who already have a cookie, and have been randomly selected for testing. It cycles through all the links on the page, checking for any that have a class starting ‘abtest_’. When it finds one it adds an onclick which, when activated, makes a call to a tracked image so that the click is counted.

This tracking is done using the BBC’s click tracking stats system, known internally as ‘go-tracking’, which allows us to easily get reports from the server logs showing how many times particular URLs are visited.

To make these calls I used img.src="..." to make an asynchronous call from JavaScript. Note however, if the link in question goes to a new page about 1/3 of browsers won’t complete the request before the page unloads. If this was an issue for a particular test the links’ hrefs could be changed, so they go via a tracked URL instead.

Finally, in the page itself we place some small snippets of SSI (though we could easily use more Javascript or PHP) that check for the cookie, and change what the user gets shown according to its value.

Example use

For 5 in 100 people to get a two-option test running for 24 hours the function is initialised like this:

abtest.init(
    'mydemo', {
        probability:5,
        numOfOptions:2,
        path:'/includes',
        duration:24
    }
);

Within the markup, content is changed according to the cookie value:

<!--#if expr="$HTTP_COOKIE=/abtest_mydemo=a/" -->
	Text a
<!--#elif expr="$HTTP_COOKIE=/abtest_mydemo=b/" -->
	Text b
<!--#else -->
	Default text
<!--#endif -->

And classes like this are added to links that are to be counted:

class="abtest_mydemo"

Any clicks on that link will result in an asynchronous call to an image with a path that includes “mydemo” from the class and the option value (e.g. “b”) from the cookie:

/go/abtest/int/abtest_mydemo_b/

Thus after the test we can count the totals for each option, and use those figures to help decide which solution to go with.

And the winner is…

Well, whaddya know: the design changed, removing the button in question, so I’m still waiting for my first excuse to use it. However, my friend Manjit over in World Service has just run a test of the wording for the main link to their syndication widget, and immediately proven a small tweak would be three times as effective at getting users’ attention. Not a bad first outing.

As a method it’s not without its dangers of course. Your presented options must be realistic, and not just chasing clickthroughs for example – but with an experienced information architect at the helm I think this little snippet may come in quite handy.

What do you think? Have any of you used this kind of testing?

View full post on Web Developer

No tags

Like at any other company, the email accounts and feedreaders of our developers are always overflowing with new articles from around the web. Here’s a quick set of some of the links creating discussion among bbc.co.uk development teams this week.

Asynchronous Servers in Python

There has been a lot of hype around the Node.js
project over the last couple of months. Whilst not a brand new concept,
JavaScript does seem particularly well suited as a language to the
event based model of I/O. Nicholas Piël has written a detailed
comparison of Python frameworks which use this model and it will be good to see this expanded to cover frameworks in other languages such as Node.

Alt and Title Display in Browsers

Steve Faulkner from the Paciello Group has done a thorough
examination of the behaviour of Alt and Title attributes on images in
the major browsers. We really liked the methodology here, taking a
discrete problem and covering it completely, rather than trying to boil
the ocean.

iPlayer Stats

Over on the internet blog Paul Murphy gives an overview of the
latest iPlayer usage stats. Particularly noteworthy is the uptake of
iPlayer on new platforms such as Wii and Playstation 3, which now makes
up 6% of requests for TV programmes.

Woosh – JavaScript Performance Testing

The Glow guys are hard at work on Glow 2 and to make sure it’s as fast as it can be, they’ve developed a speed testing framework. Frances from the team has written an overview and getting started guide.

View full post on Web Developer

No tags