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.
Searches
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
Rather than the old nav which showed a dropdown on hover we decided on pushing the page down to show some content (see above). The nav itself extends revealing individual sections such as “Stations”, “Programmes” and “Categories”. The content shown can be interactive; for example the “Programmes” tab allows you to search with results changing as you type. These sections are called Panels, and are inside a container which moves up and down known as the Drawer. There is only ever 1 Drawer but we can have as many panels as we like. The panels are Javascript objects (extending the Panel object) which reference HTML elements containing markup. This allows us to extend the nav and change panel content very easily without touching the core functionality, if we wish to bring in a new Panel we can populate a Panel instance with content (written in HTML) and add that to the Drawer. In this example we create a new (stations) panel object, passing in the name of the panel, reference to the button (its control) and the element which hold the panel content.
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
Testing the Javascript, TDD First
For testing we started with modules that weren’t directly affecting the layout; for example modules which just handled collecting data for search results (Models). The tests treat these modules as a black box; they input a query then get data returned. The implementation right now is not important, just that it handles every edge case and weird condition we could come up with. Jasmine is a Javascript testing framework, and was used to run several tests over these modules (inserting special characters, numbers, faking 404’s, mocking ajax requests. etc). All tests failed as we had no implementation yet; over 30 tests were written overall.
Testing Behaviour
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 Good
Our build process involves using Hudson to automatically push our changes to a test server. Adding the Jasmine tests to run on each build meant we could spot any issues before our code is deployed. We achieved this using PhantomJS: a headless browser engine which can execute Javascript code in the terminal and output errors. The Cucumber tests were ran manually but often as we could not easily have these run on different servers or environments automatically
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 Bad
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
when.js
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.
CSS(3) Transitions
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.
Outdated Information
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)
MDN holds a wealth of information about HTML, CSS and Javascript. It is the best Javascript reference on the web so it should be taken advantage of! On top of that its also a wiki which means we, as knowledgeable web developers, can add or change information so the pages are as effective and comprehensive as possible. Let’s take a look at what the MDN is:
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.
