6 Technical Principles behind Βι¶ΉΤΌΕΔ News on Connected TV
Post categories: Βι¶ΉΤΌΕΔ News,ΜύConnected TV
| 10:26 UK time, Tuesday, 28 June 2011
Βι¶ΉΤΌΕΔ News on a connected TV
I've written here before about publishing content to multiple platforms. Our newest product is Βι¶ΉΤΌΕΔ 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:
- 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
- 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
- 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
- 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 that's independent of the target platform. We can hook this into the vendor's API if necessary.
- 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
- 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. ). 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 Βι¶ΉΤΌΕΔ News on Connected TVs
Comment number 1.
At 28th Jun 2011, Robert Andrews wrote:I'm interested in the thinking behind the non-technical model, the tension between push and pull.
TV rolling news is push - its main viewers are content to sit and watch, to be informed by what they don't yet know, perhaps to have it on in the background whilst making dinner.
The web, and web video, is pull; users are in control of what they watch.
How are you thinking about introducing pull to TV news? Ae we convinced this is a workable paradigm? Seems to me like the onus to appeal to viewers must be set higher still - each item now has to work to earn their selection. That presumably means the number of videos on offer must be significant. Yet news video volume tends naturally to diminish naturally toward just a few lead stories.
Complain about this comment (Comment number 1)
Comment number 2.
At 28th Jun 2011, robhardybbc wrote:@Robert - this is something that Aaron, our product manager, considered. The way we implemented here is that, by default, the news is pushed to you, and if the user doesn't interact, then the video moves automatically on to the next one in sequence. It turns into a 'pull' operation if the end-user interacts, and chooses an alternative video either from the banner at the bottom of the screen, or from the pop-up 'carousel' (shown in the screenshot above). It's a hybrid model.
Complain about this comment (Comment number 2)