Building Connected Red Button
Hi I'm Duncan Fortescue the technical lead for the BBCs Connected Red Button.
See Matt Coulson's blog post for more information.
Connected Red Button on TiVo
This has been a fairly long journey for us in terms of the use of agile techniques in a technology project so I'll attempt to give you the what, why and how of the project from a technical point of view.
Techies like requirements
The project team responsible for this first iteration (or version) of the Connected Red button is a dozen strong multi-disciplinary software engineering team but due to the nature of the project many other areas of the BBC have been involved in a design or engineering capacity.
The high level requirements for the Connected Red Button were outlined by Daniel Danker in his blog post.
In short it had to:
• Be multiplatform
• Be accessible from the red button on remote controls
• Overlay broadcast
• Be contextual to broadcast
These requirements sound quite simple but it’s not all as trivial as it first appears.
Put it on the telly
From the beginning the requirement for multiple TV platforms dictated some of our architectural choices.
Even when the technology is the same there are often different implementations from one manufacturer or operator to another.
Regardless of which platform came first it was blatantly obvious to us that we must create the vast majority of the application logic as a common service and allow it to be used by many applications.
This gave us a very simple Client-Server architecture with the ability for multiple client implementations to be driven by the same data.
The client implementation just provides the user interface 'paint' to present the content to the user.
Now we have one server side for multiple client implementations we can just build more clients right? Well, not quite.
The different platforms have different requirements from a performance and optimization point of view. For example ActionScript based devices perform best interpreting XML, but HTML devices tend to perform best with JSON.
There are also other subtleties such as slightly varying channel line ups and reliance on different streaming technologies.
This forces us to identify the client implementation on each request made to the server side for us to be able to provide the correct data.
Data, data, everywhere...
The data that BBC Future Media produces is enormously varied and contains a huge amount of information. As it is domain specific BBC iPlayer data looks quite different to BBC News data which again looks different to BBC Weather data and so on.
This variety led to our next significant architectural decision - domain providers.
For each section we created a provider service that is aware of the source data for that particular domain.
Each provider can then transform that data into a structure common across all Connected Red Button providers and decorate it with all the information a client will need to render it.
In order to tie these providers together we created another provider for the navigation. This means that any client implementation only needs to know how to request its navigation and the navigation provider can then tell the client how to access the rest of the data.
We have to be able to launch our app from the red button on TV remote controls. But how do you launch an app that needs linear broadcast for the product to make sense in the world of app stores?
You can’t. The whole ‘Press Red’ paradigm is fantastically simple for our audience but causes us real headaches in a software world – particularly in a ‘Request – Response’ model as we are here.
Launching applications from the red button varies from platform to platform. This requires us to have mechanisms specific to the client implementation.
In a MHEG/HTML world an MHEG application must use a specific resident program to launch the HTML Browser at a specific URL. This is only just appearing in UK smart TVs.
What happens when a flagship show’s presenter says “Now press red for more…”? Well a proportion of the current audience on that channel will press red within a very short space of time.
Up until now our trigger mechanisms have all been broadcast over the data carousels rather than IP so we have no really accurate figures for exactly how many requests could be made and in what time period.
We have implemented a significant caching strategy including a serve stale while revalidate mechanism that ensures the user gets a quick response while our service gets new data.
In short we’re monitoring it very closely to make sure we can always cope as the demand increases.
‘tis but a scratch
Showing an error message on a TV is something we really want to avoid.
From an operations point of view we can turn on and off sections individually without releasing new software. This is fine but we prefer to build in preventative steps to stop that being an issue.
For example we have built in default images for when none exists and employed robust detection and degradation for data errors.
Developing for constrained devices also requires we monitor system resources very closely.
We perform extensive profiling during the development process to identify bottlenecks such as load times and this allows us to reorder events to give an improved user experience whilst still doing the same amount of work.
This profiling also shows us where memory is being used and more importantly when it is released.
Even though the Connected Red Button was only launched to the public last month we’ve had it running on a select few set top boxes in people’s homes for many months.
Like most software projects at the BBC we work using agile development methods incrementally adding small features to the product.
Our first version of the product had just two buttons and all it did was launch iPlayer over broadcast.
But this was enough to be able to see it work on a set top box and then iterate adding functionality at every sprint.
Our team tends to work in a scrum framework predominantly using two week sprints but this varies depending on the features being developed.
For each sprint our product owner Matt Coulson and stakeholders from around the BBC can see the new features developed in that sprint and decide if it should be released.
Now we have released the first version we are continuing this methodology so you’ll see features coming fairly frequently and enhancing the service.
Building the Vision
Like other software teams at the BBC we have recently adopted behaviour-driven development (BDD).
This practice involves our product owner sitting down with a tester and developer to write the acceptance criteria for each feature in English but with a strict syntax describing the scenarios of how the software will behave.
We then use this ‘feature file’ as the basis for our testing. This testing can be manual but is increasingly automated and triggered to run as part of our continuous integration process.
These automated acceptance tests provide us with an integration test suite that we can run on devices and show the software works at a fundamental level allowing the testers to use their expertise to stress the system in other ways.
This process is augmented using test-driven development (TDD) at the unit test level.
TDD allows the pairs of engineers to have a huge degree of confidence when writing new code and performing small refactors. The automated test suite extends that safety net to larger scale refactors and regression testing.
To Infinity and Beyond
The future holds more great BBC content on more platforms supporting Connected Red Button.
Duncan Fortescue is the technical lead for the BBCs Connected Red Button.