Almost a year ago we put Radio Explorer live, a project that was born from one of our learning and innovation days, a 10% time initiative
What does Radio Explorer do?
It’s not always easy to find radio content across the BBC, especially based on topics you like or interests you have. For instance: I may not be aware of the show name, or presenters on air but at the same time be interested in what I’ve just heard (producers would call me a “light listener”). Perhaps an interview with Lewis Hamilton on Radio 1 had sparked some interest and a listener would like to hear more interviews with him.
So we created an online application which searches not just programmes titles, but subtitles, short synopsis, long synopsis, descriptions, basically anything we can get our hands on! We then made sure any results coming back were available to play, this predominantly included clips (because they don’t expire) and programmes that can currently be played.
Radio Explorer offers you a stream of available content, giving you your own mini radio station of episodes, clips and podcasts which are related to your search term. It’s continuous so you can just leave it to play.
Below is a demo of what Radio Explorer looks like.
(Almost) One year on
Fast forward 8 months and Radio Explorer is on BBC Taster.
When checking feedback most requests were for adding stations such as BBC World Service and Local Radio. So we did exactly this. Radio Explorer now searches through all 57 Radio Stations, giving listeners local content as well as the World Service and music-based interviews from Radio 1 and 6 Music.
Since landing on Taster I was keen to find out what people have been listening to and how long they’ve been listening for.
We have recorded listening times from the past 3 months, i.e measuring how long people listen for and on what brands; these are the results.
Here almost 30% of listens on Radio Explorer have been to an “in Short” clip. Why is this so popular?
In Short, which is Radio 5 Live’s short-form content offering, has a substantial amount of clips in the database (over 4000+), each having a well-filled-out description, meaning they get picked up by Radio Explorer effortlessly. A good description means that Radio Explorer can offer more specific results which users are searching for. The user can also read the description and make a more informed decision to listen or not.
Although listening back to full episodes is available, our listeners seem to be saying short-form content is serving their needs more, at least in this case.
Radio Explorer is always likely to give back content, due to its aggressive keyword searching across all fields in our database
I wanted to see how this fared when compared with the programme search box on the radio home page, here are 10 popular searches performed by users over the past month.
On average Radio Explorer will almost always give back more results, whereas the radio home page search is currently trying to solve a different problem, namely to get you to the right piece of content. However, entering a category such as ‘comedy‘ will yield far more results (62) than radio explorer’s max which is 30. Seeing that BBC iPlayer Radio’s current search only checks programme titles, specific searches like “Katy Perry”, or “David Bowie” don’t perform too well.
As we move forward and continue to improve BBC iPlayer Radio, I hope we can improve search results across BBC iPlayer Radio and offer audiences a continuous stream to listen to which will include clips & podcasts from across the BBC.
The aim was to have a more up to date navigation bar which is fully responsive across all platforms. We took the Behaviour Driven Development (BDD) approach which involved us writing tests & defining the behaviour of our nav first. Before doing that we needed to come up with a way this nav would work.
Architecture & Idea
The radionav was broken down into separate modules (using RequireJS) which gave us a Model, View, Controller structure. The View would manipulate the DOM, our Models would gather data (for our Programmes panel) and the Controller would handle everything inbetween such as user actions.
Building in a BDD fashion
We then moved to the visual behaviour of the radio nav itself; including animation, colours changing, links working properly and content showing on certain screen sizes. Each of these scenarios were written in a language known as Gherkin. Gherkin can be understood by cucumber which in turn talks to Capybara, a tool which simulates real world interaction. These tests are then ran in a browser automatically and therefore becomes very useful when building anything that’s responsive as we can resize the browser, check what appears, resize again, repeat..
The advantage became clear when we changed how we wanted certain modules to work before writing up any code, had we changed our minds later the process would have taken longer. You are also clarifying your requirements from the beginning with everyone, this should mean less confusion across the board when features (and their usability) are brought to light. Stakeholders being able to read and understand the requirements (scenarios) you wrote down for each feature provides an advantage too.
The BDD process certainly takes more time, you need to think about investing time to write tests, to consult with others when sketching out scenarios on how your product will work and learning new frameworks/languages. There’s no denying this adds more overhead and its certainly not something which will run smoothly amongst the team overnight.
Libraries and Techniques
We have our models which asynchronously go of an get data for search results in the programme panel. Instead of using typical JS callbacks we use promises. Promises are very powerful and represent the eventual outcome of an asynchronous action, they’re also chainable. You can read more about the Promises/A+ spec here
EventEmitter & RequireJS
By calling events rather than functions directly means we can hook multiple functions to a particular event. Our section of code that handles the view fires off events when actions happen by the user (I.E clicking on the search box, typing in a query etc). The event fires and the view sits and waits for data to come back. By separating logic into modules we can swap out how our implementation but keep the view the same.
These modules are put together with RequireJS.
Well it seems we’ve reached a point where we can do CSS transition and have them degrade gracefully; browsers not supporting these just open and close. The opening and closing of the drawer is a CSS transition. This brings us a nice advantage of having the animations being handled directly by the browser; It should give us a much smoother transition. Our JS code can listen on the transtionEnd event to know when the drawer has finished opening/closing.
W3schools holds too much inaccurate information which many readers take at face value without even challenging. This causes issues which usually ends up with users coming back to us asking why something isn’t working, when in reality none of which would have happened if they chose the right place to begin with! Another issue is transparency, we don’t know the people updating this site, how often they’re updating and what they plan to add/remove. It makes the source quite untrustworthy.
W3schools also holds outdated information: Lets take a look at PHP for example, here it still advocates the use of mysql_connect(). Something developers would warn you against using! Lets also remember that
W3Schools.com is not affiliated with the W3C in any way. Members of the W3C have asked W3Schools to explicitly disavow any connection in the past, and they have refused to do so.
More info: W3Fools
Mozilla Development Network (or MDN)
We are an open community of developers building resources for a better web, regardless of brand, browser or platform. Anyone can contribute and each person who does makes us stronger. Together we can continue to drive innovation on the Web to serve the greater good. It starts here, with you.
Using it effectively
MDN doesn’t come up in search results very well, its usually overshadowed by someone’s blog or W3Schools (argggh!). I find the best way to bring up the MDN reference is to prefix your query with mdn. So in google your search would be like this; ‘mdn canvas’.
Lets make this faster
Ok sounds like some effort? Lets make this easier. If you’re using chrome click ‘the spanner’ -> settings -> then click ‘manage search engines’:
In Search Engine Name – enter ‘MDN’ (without quotes)
In Keyword – enter ‘mdn’ (without quotes)
in Link – enter ‘https://developer.mozilla.org/en-US/search?q=%s’ without quotes.
Now we have our own MDN search. Lets give it a try: Typing in ‘mdn’ (followed by spacebar) now triggers our search engine for the Mozilla Development Network (awesome!). Now we just need to type in our keyword. I want more information on the article element so im going to search for that.