We’re using test-driven-development on the code generating the pages, but obviously these techniques don’t cover the visual appearance of the site. As we reuse the same visual modules on different pages across the site, CSS bugs creep up unexpectedly on different pages across the site.

For example, the code generating the links module is reused on three different pages:

• http://www.bbc.co.uk/music/reviews/2h54
• http://www.bbc.co.uk/music/artists/cc197bad-dc9c-440d-a5b5-d52ba2e14234
• http://www.bbc.co.uk/music/artists/cc197bad-dc9c-440d-a5b5-d52ba2e14234/links

And to illustrate the problem, I just noticed a CSS quirk with the background of the links module on that third link. So I started thinking about how one might go about regression testing CSS and hacked a simple solution together using CutyCapt, ImageMagick’s compare tool and Ruby Rake.

The result is illustrated here:

Stable version of BBC Music Beta artist profile page

Development Version of BBC Music Beta artist profile page

Difference between the stable and development versions of the site

The first image is a screen capture of the stable version of an artist’s profile page, taken directly from the live BBC Music Beta. The second image is taken from our development version of the site. The third image shows the difference between the two - in our upcoming release we are shuffling some of the modules around so these changes are very noticeable.

At the moment, my tool is very basic: you give it the stable and development host names, and a list of paths to test (example configuration). It uses CutyCapt to pull down each of the paths from the stable and development hosts, and then runs the ImageMagick compare tool between each pair of images. It then produces a very simple HTML file that displays all of the pages being tested.

While we’re just using this tool informally at the moment, it’s already been really useful to catch unexpected CSS bugs on our site.

I’m keeping notes of what’s going on here:

Matthew Shorter describes at the bottom of his post how to use MusicBrainz to find a given artist. Here’s a little something to make that a touch easier: a BBC Music/MusicBrainz bookmarklet!

Drag this BBC Music/MusicBrainz link to your bookmarks bar in your browser. Now, when you’re on an artist page (e.g. Coldplay) click on the bookmarklet to switch between BBC Music and MusicBrainz artist page.

Enjoy!

When I came to the Giles Peterson show, I was surprised that the system was recommending artists such as ‘The Automatic’ and ‘Arctic Monkeys’.

This struck me as extremely unusual recommendations for a show featuring “Latin, funk, soul and hip-hop”, but I suspected that the data rather than the system was at fault. I had a quick look at the source data that had been fed into the system for this show and found:

• The Wombats (1)
• My Chemical Romance (1)
• Hard-Fi (1)
• Gideon Conn (1)
• Armand Van Helden (1)
• Editors (1)

Looking at this list, it seems that the recommendations actually make sense: there is very little data for the show, and actually it doesn’t even look correct!

This data has been generated from the digital play out system but we are unable to track some of the shows, especially specialist music shows such as Giles Peterson. The DJ might play directly off their own vinyl/cd/computer/other crazy device, or the show might be pre-recorded.

So what I’ve done is simply ignore brands with a low average artist play count (<=1.0), which should avoid this kind of situation.

I also want to point out that there is a basic API in place, although it still needs documenting. Just add '.json' at the end of brand/artist/last.fm profile URLs to get a JSON feed of the data.

I’ve just returned from Mashed 2008 where I formed part of the BBC Radio Labs contingent.

We were providing all sorts of fun things for people to play with, from live BBC Radio audio streams, feeds of what track is being played over the air and archives of both the audio and metadata feeds. All of the details are available on the BBC Audio and Music Interactive at Mashed 2008 site.

One of the things that I was directly involved in was the “How many times brands have played artists” data set. By matching the music tracks played on air to MusicBrainz artists, and then work out which radio show the track was played on, we can build this index of which artists were played on what shows. For example, we can see which artist Jo Whiley has played the most, or work out who’s been playing the Arctic Monkeys the most.

It is also a great resource for recommending artists and shows and shows to people. So what I did for Mashed was feed this data into the Semantic Space engine, developed at the University of Southampton by Jon Hare, and build a web app around it: music-recommendations.metade.org.

The site let’s you browse around artists and shows, and view lists of other artists and shows the system has recommended. It also provides recommendations based on a last.fm profile top artist feed.

There is a little more detail on how the technique works on the site (hint: it’s based on latent semantic analysis), and I intend to carry on working with Jon to improve both the quality of the recommendations and how they are visualised.

Read more about it on the Radio Labs blog.

While talking about Augmented Reality, I was browsing through the recent O’Reilly “Augmented Reality - a practical guide” by Stephen Cawood and Mark Fiala. It looks like a great introduction to the subject, describing some of the new augmented reality frameworks that have improve on the trusty old ARToolKit. However, I felt that the demo application that the book presents could have explored the tangible augmented reality side of things more.