It was just before the first release of BBC Programmes, and it was a couple of months before the iPlayer streaming service on the web launched in December 2007.

I came to the BBC because having developed a number of research prototypes in academia for a few years, I wanted to build stuff with a significant number of real users. And I’ve certainly been able to do that, having worked:

• on a page for each artist on BBC Music and clickable tracklists for programmes pages
• a year at Radio 1 working on things like the chart, live lounge and getting twitter to drive Scaletrix cars
• on the Radio 1/1Xtra homepage project
• on a number of music events sites, both in the good old static html days and with the new music events platform
• on the launch of iPlayer Radio

It’s been incredible. I’ve learnt so much, not just from the technical side but also as an individual. I’ve worked with really brilliant developers, designers and editorial - making great friends along the way. I’ve worked on some amazing projects, and written code that is used by millions of users each week.

However, all good things must come to an end and I’ve decided it’s time for me to move on.

Friday was the last day at the BBC for me, and today I’m starting as a technical lead at Sidekick Studios.

I managed to convince my girlfriend, the brilliant Kirsten Fletcher, to join me. Kirsten is a freelance costume designer-maker, who is more used to working on theatre and movie productions than hack days.

Screecha

Together we made Screecha: an interactive musical toy aimed at children. It’s a puppet that can house a smart phone in it’s belly and an app to go with it.

Using the app, children can: - listen to their favourite songs (using the Spotify Metadata API and Cocoalibspotify) - view the lyrics as the song plays (using Echonest and Musixmatch) - record their own songs and upload them to SoundCloud - listen to the masterpieces they’ve previously uploaded to SoundCloud

As a song plays, the puppet can be manipulated to sing along with the music.

The idea

The idea was mostly inspired by hanging out with some close friends who have a baby. They were talking about how many children’s songs and nursery rhymes were available on Spotify, which led us to think about a Spotify app as a physical toy.

We then started looking on other music services for children’s songs and came across a recording of a toddler singing “Twinkle, Twinkle Little Star” on SoundCloud. That’s when we decided that the ability of recording and saving children’s performances would add an interesting angle to the hack.

Hacking with a sewing machine

While I was was doing the usual coding activities involved in a hack day (basically throwing code together until it worked), Kirsten designed and built the puppet from scratch.

This obviously required a fair bit of planning and organisation upfront. She had to have an idea of what the puppet would look like in order to select which materials she’d need to bring to the hack day. She had to bring in her sewing machine (the first sewing machine at a Music Hack Day!) and a big bag of fabric as well as the other tools required to make the puppet.

It was really interesting to see the process that she took. Based on a simple sketch for the design, she created a pattern: a paper template from which she made the preliminary shape for the puppet. After some tweaking, she adjusted the pattern and cut the fabric for the final puppet prototype. Then it was a matter of sewing it all together and finishing it off.

It really made me appreciate how lucky software and web developers have it: all we need is a laptop and internet connection and we’re effectively limited by our imagination and ability.

Hacking with iOS

The Screecha app was actually the first time I developed a native iOS application. It was implemented using PhoneGap, so most of the user interface was developed using HTML/CSS/Javascript and Twitter Bootstrap. However, I did have to integrate cocoalibspotify so I did get to tinker about with some Objective C.

As a Hackday prototype, it was actually a bit disappointing to have developed a proof of concept that couldn’t be shared or made publicly accessible. If I had to do it again, I think I would go down the mobile webapp route using the HTML5 Audio API.

Focus

From the start, we had a really clear idea of what we wanted to build: a puppet and a simple app that allowed you to play music, record sounds and upload them to SoundCloud.

We focused on implementing just that, resisting the temptation to add more features to the app or consider hacking some hardware into the puppet - there simply wouldn’t have been enough time to complete the prototype otherwise.

In my experience, good hacks can be the result of lots of iteration, last minute changes and a great deal of “hacking”. With Screecha, we took a good idea and focused on implementing just the essential features.

Screecha won an award from Spotify for best use of the Spotify API, and an award from SoundCloud.

A couple of years ago I helped develop a fundraising application for the Child’s i Foundation, a charity and worldwide community aiming to build a home for abandoned babies in Uganda.

At the time the charity was raising money to set up a home in Kampala, so the team at Childsi came up with Buy a Brick, a web app where users donate from £2.50 to £500 to purchase a brick to build a virtual wall.

In the 2 years since it launched, the Child’s i Foundation community has bought nearly 400 bricks, raised nearly £18,000!

I implemented the backend of the application in Ruby on Rails, in particular the integration with the payment gateway for processing donations. It was the first (and only) e-commerce website that I’ve ever deployed and maintained - I learnt a lot!

Over the last couple of weeks, we’ve been tinkering with the application so it uses the Just Giving donations API instead of the original payment gateway. We ended up using (and patching) the Just Giving Ruby gem, so the switch over was pretty simple to implement.

What wasn’t so simple was upgrading an old, pre-Bundler Rails 2.2 application to Rails 2.3 and getting the right combination of gems versions to play together on Heroku! But I got there in the end…

The application is at buyabrick.childsifoundation.org/ and the code is all on Github: github.com/childsi/buyabrick/

I’ve written a “under-the-hood” post on the BBC Internet blog, describing how we approached the technical challenges to meet the editorial ambitions for the new homepage.

I was on attachment with the Radio 1 and 1Xtra Interactive team when the design was conceived, and although the site was built by the fantastic team at Kite I’ve been heavily involved throughout it’s development.

I might be a bit biased, but I think it’s pretty special! What I’m most happy with is how we’re pushing content to the page using BBC PushFeeds (i.e. XMPP PubSub over Websockets or Flash as a fallback) to enable the live experience. On top of that, we’ve delivered an admin system that allows producers to promote content to the homepages within seconds.

Track now playing information has been present on the BBC national radio networks sites for a number of years, but in the new homepage they are put into the spotlight. The beautiful packshots (album art) are mainly taken from the Radio 1/1Xtra charts and playlists. Using MusicBrainz identifiers we’re able to surface content from BBC Music, including artist biography, latest clips and album reviews.

I believe this reinvents the way the stations present themselves online, and potentially on air. Whenever something happens in the studio, it’s on the website in seconds in the form of an update, photo or live video stream. The audience’s reaction to the show can be surfaced online in the form of their texts, tweets or Facebook comments.

It’s opened up a new toy box of possibilities, and I’m really looking forwards to see how both the audience and the stations engage with what we’ve built.

Together with Dave and Kerron, I was one of the mentors at the Young Rewired Blackfriars which was hosted at Fluxx Studios. Our group started by brainstorming during the first morning, focusing on 4/5 ideas which eventually led to 1 project: searching and visualising University course data.

The team built UniMatch:

There’s a live demonstration available at http://unimatch.net/.

I was really impressed by the Fluxx Capacitors team. I loved the way they came up with ideas during the brainstorming sessions - there was some really great things coming out of it. Coding wise, there was a wide range of abilities, from those who had been programming for years (i.e. since they were 10), some of them had tinkered with some HTML and CSS and others who hadn’t coded at all but were keen to learn. The more experienced ended up doing the heavy lifting on the server side and more advanced Javascript front end work, and the rest of them worked on designing the UI and then implementing the design and HTML/CSS.

There were some really ingenious approaches to working collaboratively too. When they started editing the code on a shared server space, they used a system consisting of wooden blocks for each of the components (e.g. HTML, CSS, database and server code) to prevent multiple people editing the same file at the same time.

As a mentor, it was brilliant to be able to point the more code-oriented people in the right way in terms of software development best practices such as source code control and web applications frameworks.

I wasn’t able to attend the presentation, but it’s available on the YRS UStream channel. They did a fantastic pitch (about 1h 9m mins in), and came away with the Most likely to be bought (code or concept) prize. Great work Leon, Richard, Joanne, Hugo, Kerron and Priscilla!

Some of them are continuing to work on the project, so it’ll be interesting to see what they come up with.

I have been pretty busy over the last few years at the BBC. I did a lot of work on BBC Music, and I spent a year with the Radio 1/1Xtra Interactive team where I had lots of fun. More recently I’ve been working on the music event sites.

Away from work, I’ve been to a few hack days including a couple of Music Hack Days, Linked Gov Hack Camp and a few Rewired State events.

I’m going to try imposing a new rule on myself: I will force myself to write up anything I work on that I spend more than an hour on!

Photo by Jenny Ekelund

A few weeks ago I took part in the Said.fm Radio Box Hack weekend, where I did some experiments with Mobile HTML5 geolocation and audio playback on mobile devices.

I had been playing with what I was calling a “GeoSoundBoard”, where users could walk around unlocking sounds when they reached certain locations. My demo was using sound clips from a BBC Radio 1 soundboard for Tim Westwood - imagine walking around the corner and hearing Westwood drop a bomb!

You can try it out for yourself - drag and drop the blue marker onto one of the nearby orange markers to hear it go off.

On my iPhone I found that while the HTML5 audio would play fine when I dragged and dropped the marker, it wouldn’t play when I actually walked towards one. I never got to the bottom of this issue but it’s likely to be because HTML5 audio playback on mobile devices must be triggered by direct user interaction to avoid excessive data charges or battery consumption.

So at the Said.fm hack day I decided to change the UI so that it would display information about the track a user had unlocked such as an image and description and offer the option to play the track. I also wanted to prototype an authoring solution so that curators could produce audio playlists around a certain theme and scatter those tracks in the real world. And with Abdel’s help we got a more robust player implementation for the audio playback.

You can check out what we built at http://geosoundboards.heroku.com. It uses: - Ruby and Sinatra - JQuery Mobile - JPlayer for the audio playback (thanks Abdel!) - Google Docs for the CMS check out the instructions and a sample playlist

And the source is on GitHub.

Thanks to the Said.fm guys and all of the other Radio Box hackers - it was fun!

I worked on the we-need.org project, which was led by Craig Griffin from Fresh Voice. The idea is to provide a web site where people with disabilities are able to express their needs through an accessible web interface rather than having their needs assessed by the system as it is currently (i.e. by filling in a 50-odd page form). The site would then aggregate and present interactive visualisations of the needs in a given community so they can be more efficiently handled. Hopefully the video of the pitch we presented on Sunday will be made available online soon, where our team explained the concept far better than I can!

For the weekend, we built a Ruby on Rails application where users could use a basic html form to express their needs. We also experimented with a graphical radial interface which is better suited for people with certain types of disabilities. We used the Geokit Rails plugin to geocode users’ addresses so that their needs could be plotted on a map. We used Simile Exhibit to prototype the visualisation of the aggregated needs of communities on a map.

As mentioned during the project presentation, we required some sample data so I put together some Ruby to randomly generate some users and their needs. So here is the infamous Ruby “random needs generator” one-liner:

(0..rand(3)).to_a.map { |a| rand(@@need_count)+1 }.uniq

I’ve bravely put all of the we-need code on github, but do keep in mind that it was all built in less than 24 hours!

I had a really amazing time, worked with some fantastic people on We Need and also really enjoyed the post-SICamp discussions in the pub on Sunday! Big thanks to the SICamp team for organising everything - I’m already looking forward to the next SICamp meetup!

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.

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 (brand/artist/last.fm profile URLs to get a JSON feed of the data.

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.

It’s been quite a ride: starting as an undergraduate, doing my PhD, and then four great years as a research associate/fellow at both IAM and LSL.

Tomorrow I start a new adventure, as a Software Engineer at Audio & Music Interactive at the BBC…

I worked with Jon Hare, and we went for the augmented reality web service, which was pretty crazy. We made the ARToolKit, which you can see in the video below, into a web service!

Although it’s a little rough around the edges still, you can play with our hack online at: http://multimedia.ecs.soton.ac.uk/artheworld

I’ve also posted the slides from our 90 seconds presentation on Slideshare:

This work was done using the ARToolKit, an augmented reality toolkit that does the computer vision tracking of the marker cards you can see in the video.

I’m very tempted to build something based on this for Hack day!

In collaboration with a couple of guys from the research lab I work at, we recently had the crazy idea to make the ARToolkit into a web service.

The basic idea is as follows: you take a photo of an ARToolKit marker in a fun place, upload it to the web service and it renders some 3D content over the card using the ARToolKit.

I started putting together a basic web app using the Ruby Camping framework. I even managed to get it to upload result to Flickr if the user decided they liked the resulting image.

Here’s a screenshot of what we have so far, plus the Flickr account for the service.

The app still needs a lot of work (e.g. letting people choose which 3D model they want rendered), but the basics are there for a nice hack.

What we really need to do is work out an actual application/scenario for this - there probably isn’t one and it’s just a bit of fun, pointless hackery. But I’m quite intrigued to investigate some kind of whacky “physical meets the digital” experiment…

The title of the lecture was: “The Semantic Web: a Medical Perspective”.

I described the issues surrounding the sharing of data in the medical domain, and how the current web fails to address the needs of users wishing to integrate different data sets. I then introduced the semantic web, but I did it from the perspective of linking data rather than the top-down, formal ontologies and logic route.

Although presenting a full lecture was a new experience for me, I think it went well. I gave the presentation in English rather than try a mixture of rusty Portuguese/English, although looking back now perhaps I should have gone with the Portuguese. It’s so easy to drop in a typical English expressions or word that non-native English speakers won’t have a clue about!

I’ve made the slides for the presentation available here: slides (PDF, 7Mb).

Back in the 1960s, my grandparents made an incredible home video. They recorded their trip from Alnwick to Edinburgh - a trip of around 90 miles reduced to 7 minutes!

From what I understand, they mounted the camera to the car’s dashboard and then my grandmother had to press the camera shutter every eight seconds or so. It’s amazing to see the old cars and trucks on the road, and then right at the end there’s a brand new Mini!

It’s also fun to see how little time they spend behind other cars - as soon as one comes up they’ve overtaken it!