BBC News on a connected TV

I've written here before about publishing content to multiple platforms. Our newest product is BBC News for Connected TV (blog entry by Phil Fearnley) . I thought I'd write a little about how we implemented this; lots of the concepts here are standard computer science ones, but I thought it's worth reiterating as it shows the similarities between publishing to devices with different form factors and technical capabilities. So here are our six TV software design best practices:

1. Our internal data sources need to be platform-neutral - meaning we can target multiple platforms with different front-end technologies. News content has been multiplatform for years, since we already publish to the web, mobile platforms, mobile apps and the four broadcast platforms
2. To allow this, the content needs to be structured. A blog, for example, tends not to be a useful data source, since the markup tends to be unstructured, and contain objects like Flash videos that aren't multiplatform
3. Each platform is a specific rendering, or a 'view' on the data. Our user-experience team and product owners need to ensure we can take advantage of the specific characteristics needed for each platform; for instance one form-factor may be a hand-held device with a touch screen, whilst another will be large screen with a remote control. Whilst the data is platform-neutral, we've learnt we can't simply take the web site and put it on a TV screen, as both the physical interaction and the mental engagement differ for each form factor
4. We abstract away from vendor-specific APIs so that the code is platform-neutral. This lets us play back videos, or handle remote control key-presses in a way that doesn't create a large development overhead for every additional platform. We do this by creating a state machine and model-view-controller architecture that's independent of the target platform. We can hook this into the vendor's API if necessary.
5. We use a test suite and harness to drive the implementation of the functionality. This lets us add new functionality with confidence, and also target multiple vendors to ensure the code works the same across devices
6. Non-functional requirements, which aren't exactly sexy, feed into the project to ensure proper error handling, scalability and failover procedures in case there's a technical problem

Not all of the services we create use all the concepts above. Sometimes the front-end code is developed by a 3rd party, which can result in an independent implementation of the code (cf. Conway's Law). Other times we have legacy systems to work with - so it can becomes a bit of a balancing act to decide how much we work around an old system vs when do we invest in an wholesale upgrade and port the content. The list above is idealised - hopefully it shows the sort of things we have to think about.

What best practices do you apply in TV software development?

Rob Hardy is Broadcast Platforms Team Leader in News and Knowledge, and the technical lead for BBC News on Connected TVs

Read more and comment on the BBCi Labs blog.

Rob Hardy is Technical Manager, TV Platforms Group, BBC Future Media & Technology.

The Vision team produced a visually stunning quiz based on the BBC Two Series It's Not Easy Being Green. The application allowed viewers to interact by scoring themselves on their environmental attitudes. Through seamless video switching, positive or negative feedback was given before presenting the viewer with their own individual "green audit" scores".

This is a good time to go under the bonnet for this show.

Read more, watch video and comment at BBCi Labs Blog.

Rob Hardy is Technical Manager, TV Platforms group, BBC Future Media & Technology.