All this means is that any time a web developer wants to explain what they've been working on, they'll do it at https://bbcstreaming.pages.dev/blogs/bbcinternet, rather than here.

And suddenly, the Internet blog will start to be extra-interesting.

Thanks for your comments... see you on the other side.

exit();

So, when it came to the new version of the homepage, we knew that getting this right was important. But we also wanted to make it better than it was before. But how to do this? In the end we decided on two things - let users set their location to anywhere in the world (good for international users, or people who want to see what the weather's like where they're going on holiday), and stop requiring a full page reload every time a user's location is set.

Going global

The first problem was letting users set a location anywhere in the world. Unfortunately, Postcoder (the data set used by the previous version of the homepage) only knew about places in the UK. Granted, it knew about a huge number of places in the UK, but it was still limited to the UK. So, we had to look at a second data set that knew about the rest of the world - the BBC Weather Search API. This API knew about places all over the world but unfortunately it knew a lot less about the UK than Postcoder did.

This turned out to be a problem. Whilst the Weather Search API knew about the UK's postcodes, it didn't know about a lot of the smaller places within the country. So, for example, whilst it knew about Leicester, it didn't know about Belgrave (the home of Leicester's "Golden Mile" and the largest Diwali celebrations outside of India). This was obviously a problem. Understandably, people would expect the new homepage to know about at least as many places as the old one did, so just using the Weather Search API was not going to be possible.

After a bit of head scratching, I did the obvious thing: I took the best bits of each data set and used them to generate a cohesive whole. Now, whenever a user tries to set their location we send queries to both Postcoder and to the Weather search API. We then throw away anything the Weather Search API tells us about the UK, and just use its worldwide data along with all the data that we previously had for the UK from Postcoder.

Of course, things weren't actually quite that easy. Let's walk through the actual process we have to go through to determine a user's location:

1. The user searches for a location. We send requests to Postcoder and the Weather Search API.
2. We get data back from the APIs (and remove any UK results from the Weather data set). If there was more than one result then we let the user choose between them.
3. Now that we have a single location, we have a decision to make.
   • If the location came from the Weather API then it's not in the UK. We reset the localisation for news, TV and Radio (since we don't have any non-UK localised data for them), and set the weather localisation. At this point we have nothing left to do. Hooray.
   • If, however, the location came from Postcoder then we continue along the branches of our tree.
4. Since we now know that the place the user has chosen is definitely in the UK, we can localise news, TV and Radio. We do this.
5. Unfortunately, Postcoder doesn't provide us with a weather ID that can be plugged directly into the weather system, so we need to find one from somewhere.
6. Using the first half of the postcode we got from Postcoder we once again query the Weather Search API.
   • Weather returns us a single place matching this postcode, and as part of its data an ID that can be plugged into the weather system.
   • If, for whatever reason, Weather doesn't know about the postcode we give it (it's happened a couple of times), then we perform yet another search on the Weather Search API, this time with the name of the place that Postcoder returned us data for and really get some data.
7. Finally, at this point we've gathered all the data that we need for the localisations that can be applied to the page. So, we return the data we've assembled to the user's browser, and they get to see lots of lovely localised data.

Phew. That's basically what we have to step through every time a user sets their location. Essentially, every time a user tries to set their location to a place in the UK we have to make at least three calls to extrnal APIs (and sometimes more) to gather all the data we need to localise the page. And this is before we even get to pulling in the data for the localised modules!

And, with this change in place, the localisation popup on the homepage suddenly became aware of places all over the world. Users can now keep track of the weather in Istanbul just as easily as they can in Dunstable.

Updating modules in-page

The other big thing we did to the user localisation on the homepage was to no longer require a full page refresh whenever a location was set. Previously, whenever a location was set by a user on the page, a full page regeneration was triggered.

Now, this obviously wasn't pleasant. Having to wait for a full page refresh can be tiresome, and the flash of no content as a new page loads just doesn't look very nice. So, one of the aims we had with the homepage refresh was to stop that, and instead just update the portions of the page that needed updating.

When the user sets their location on the new homepage we make several AJAX requests back and forth to the server. These requests allow us to update the model we store that determines how the page is to be laid out for individual users. In the Old World, we would then have forced a full page refresh to enable the user to see this new layout. In the new homepage, we instead return a blob of JSON data to the user's browser.

That JSON data contains everything we need to update the page. Here's a simplified view of the data we return:

{
    "content":{
        "news_local":{
            "html":"...some html...",
            ...
        },
        "forecast":{
            "html":"...some html...",
            ...
        }
    },
    ...
}

Here, you can see that each module that we're going to update on the page is defined within its own section of the returned JSON. Each section is named after the ID of the HTML block that needs updating, and contains (amongst other things) a big block of pre-rendered HTML. This allows us to do the simplest thing possible in the JavaScript of just replacing one bit of HTML with another, and gives the added benefit of being able to reuse the same logic that was used to generate the module's HTML when JavaScript isn't available.

Refreshing the look

The other obviously different thing about setting your location in the refreshed homepage is the overlaid panel that you now see when you enter your location. The nice thing about this panel is that it's provided for us by the BBC Glow team, and it allowed us to take a form that already worked on the page without JavaScript and inject it with a new look and feel.

The fact that this sort of functionality (and a whole lot more) is provided for us by the fantastic Glow team makes our job a whole lot easier.

Other Complications

Of course, not everything was fun and games in the land of location setting. One issue that had managed to slip by me until fairly late in the day was that some places have the option of taking their news from one of two different areas. A good example of this is Chepstow on the Welsh border.

For good reason, there are many people who live in Chepstow who identify as wanting to be provided with Welsh local news. Likewise, there are others who would prefer to receive local news from Gloucestershire. The way we now deal with this on the homepage is by giving users the option to choose between these places within the same popup that they had previously chosen their main location in.

Finally

So, that's what went into the new Homepage's localisation options. Frankly, it's a bigger thing than I expected when I was first given the work to complete. As the developer who worked on this I'd like to thank each and every person who took the time to leave feedback during the Beta process - you really helped to make the homepage what it is now.

When we launched the Beta Homepage we received feedback from a number of you who missed the clock, so we've turned it into a module allowing you to position the clock where you want it on the page (or shrink it or remove it altogether). It continues as before to show your computer's local time and date.

As part of moving the clock to its own module, it now makes use of upcoming HTML standards. Flash is no longer a necessity as the module uses HTML5 Canvas to draw and animate the clock face. This means users of newer browsers (and iPhones) will see the clock ticking on the page even if they don't have Flash. Of course, if you're using an older browser the Flash version will continue to load as usual.

If you're interested in how our Canvas code works, here's a snippet showing how to draw the clock face:

drawDisplay: function(pos){
    this.context.clearRect(0,0,49,49); // clear canvas
    this.context.save(); // save state before translation
    this.context.translate(24.5, 24.5); // move 0,0 to center
    this.context.strokeStyle = "#fff";
    for (var i = 0; i<12 ; i++){ // draw numerals
        var lineWidth = 1.2+(i*0.1), rotation = 30*(i+1),
            startX1 = -0.5 - lineWidth/2,
            startX2 = 0.5 + lineWidth/2,
            startY = -26, endY = -18;
        this.drawLine(lineWidth, rotation, startX1, startY, startX1, endY);
        this.drawLine(lineWidth, rotation, startX2, startY, startX2, endY);
    }
    this.drawCircle(2, 0, 0, 5, 0, Math.PI*2, true); // draw centre circle
    this.drawLine(3, pos.hrsPos, 0, -6, 0, -17); // draw hour hand
    this.drawLine(2, pos.minPos, 0, -6, 0, -24); //draw minute hand
    this.drawLine(1, pos.secPos, 0, -6, 0, -26); //draw second hand
    this.drawLine(1, pos.secPos, 0, 5, 0, 10);	
    this.context.restore(); // go back to the state before translation
    this.drawnPos = pos;
}

The display is then redrawn every second to move the hands to the current time using Glow Animations.

The clock has come a long way since it first appeared in our idents and continues to live on in new technologies.

In praise of Git's index

Aristotle Pagaltzis has a good writeup of the benefits of Git's index (via Ryan Tomayko). This is one of those things that isn't immediately obvious, but quickly becomes invaluable.

Alternatives to inheritance

Curtis "Ovid" Poe has written quite a lot about alternatives to inheritance for code reuse in Perl. His latest post examines the options for using Roles without Moose for his new project at the BBC.

Live SPARQL end-point for BBC Programmes

Yves Raimond announced an experimental SPARQL end-point for BBC programme data, including a description of how the service was created. It's a great addition to the variety of linked data provided by BBC Programmes. See also this case study on the use of semantic web technologies at the BBC.

New Browser Security Features

The Chromium Blog had a good post about new security features in Chromium, but also in Internet Explorer, Firefox, Safari and Opera. It's nice to see browser vendors centering around standards to solve these problems.

Semantic Versioning

Tom Preston-Werner, one of the co-founders of GitHub, has written a specification for a standard software versioning scheme. Many of our teams already use approximations of this (in fact the Glow team document theirs) and find it works well, but as the article says:

The problem is that "close" isn't good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management.

It's a great piece of common sense and we'll be looking at how we can follow this spec more widely around these parts.

Building the Mobile Homepage

Some of the key issues tackled in creating the the personalised mobile BBC homepage are discussed on the Internet Blog. While modern devices are looking to blur the lines between the mobile and desktop web, it's clear that building a compelling mobile experience still poses its own unique challenges.

The Digital Revolution

An upcoming documentary on the history of the internet, Digital Revolution has already made some great interviews available with key internet people available on the site, with more permissive licensing than usual. Gizmodo has published an early trailer for the series and it looks like it's going to be a must-see for anyone interested in the web.

52 Weeks of UX

Something else that has caught our eye this week is the early output of 52 Weeks of UX. The project is aiming to stimulate discussion around User Experience design through a year-long series of short posts on various aspects of the subject. To software engineers the visual design process can often seem a vague thing, lacking definitive answers, so we're hoping this will help improve understanding of just how important this part of our job really is.

By the way...

...we're trying to pick things from the week that might have missed your inbox, so please feel free to let us know if there are any interesting things that seem to have missed ours.

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.

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?

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.

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.

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