Latest entry
Tristram Biggs writes...
Historically FM&T Journalism has focused primarily on web development. The reasons for this are many and none of them are any of my business but it is odd, because the first experiments that BBC News made with 'On Demand' started in the early 1970s and they were on television sets. The experiment still exists today and it is called Ceefax.
The principle is relatively simple, take some text Journalists with access to agency feeds and ask them to write short news stories. Then ask them to keep them updated, all the time. And so On Demand Journalism was born - no printing presses or Six O'Clock bulletin to meet, just up-to-date information when the viewer wanted it.
Read more and comment on the BBC Journalism Labs Blog
Tristram Biggs is Executive Product Manager for TV Platforms at BBC Future Media & Technology (Journalism)
Recent entries
Andrew Bowden writes...
If you use our service on a Sky box you may notice that every now and then you come across a large "Please Wait" screen.
We put one of these up every time a user selects some content that can't be loaded in a few seconds.
In an ideal world, we wouldn't need them at all - we don't want you to have to wait ten seconds or so just to get to the News Multiscreen. However due to the way our service has to be structured, it's an unfortunate necessity.
The reason for that is all to do with bandwidth and positioning.
Satellite space is broken up into chunks called transponders - the BBC has seven of these. The main BBC TV channels are split over six of them, and each contain a series of TV and radio channels - including 18 regional versions of BBC One and 4 national versions of BBC Two.
BBC Red Button has a chunk of space on each of those transponders which enables us to have a service alongside the TV channel - so that when you press red you don't need to leave the channel you're watching.
However that chunk of space isn't big enough to contain all our content, so some of our text content sits in a shared area on another transponder. Our video services too also sit in another transponder to the TV channel. When you select some content - like Flight Arrivals, the News Multiscreen or Sport Multiscreen - the set top box needs to retune to the other transponder and load up the content. This can't be done quickly, hence the "Please Wait" screen - which we call an interstitial internally.
As well as promoting various parts of the service, we also use the interstitials for information purposes, like reminding people that the clocks will be going back or forward. And at Christmas, we like to have a little fun, in the form of our advent calendar - running from the first of December through to Christmas Eve.
The follow up on Christmas Day is my personal favourite, however I suspect many people won't actually get to see it - people are generally too busy cooking turkey and opening presents to be pressing their red button. However if you have a spare moment amongst the chaos and mayhem, why not press red and see what you find!
Andrew Bowden is a Senior Development Producer for the BBC Red Button Service.
Ruhel Ali writes:
The BBC has always been at the forefront of innovation. From producing the first television transmissions; the creation of Ceefax; to taking the UK digital, the BBC has enabled new technology and ideas to flourish.
We have seen a massive change in the way people interact with their TVs from the introduction of digital services on Sky, Virgin, Freeview and Freesat to more recently seeing BBC iPlayer available on PC and the cable platform. The BBC Red Button service has allowed viewers to access extra audio, video and text content on the TV, as well as enabling them to play along with quizzes, enhance their experience of certain TV programmes and in general expect a broad choice of BBC interactive content to be available when they want it.
As more features are introduced on other platforms, such as the BBC Online, a question comes to mind - how do we keep the Red Button service as interesting and relevant for our viewers?
We have done quite a lot in the background and under the bonnet of our service but since 2007 we have also been experimenting with different ways of working to get fresh ideas and services on air for the public to enjoy. One method was to introduce the One in Ten programme.
What is One in Ten?
One in Ten was introduced last year in the Red Button team to allow staff there the time to work on innovative ideas every one work day out of ten. This has allowed staff to explore ideas which they are interested in and which may also be of benefit to BBC audiences or to the BBC internally.
The projects that were submitted had varying levels of success. Some have not progressed far, some have come up against technical hurdles, whilst other have been very successful and made it across the line! All of them allowed the in-house team to explore and investigate ideas that otherwise may have not been looked at as part of usual work stream.
Below are some examples of projects that have made it through to closed user testing.
Generic Real Time Tracker
The Generic Real Time tracker is a prototype system to demonstrate real-time submission of location information from a GPS enabled mobile device via the internet, which in turn is displayed on a BBC interactive TV application.
James Sheppard showing the initial prototype on a cable set top box.
Screenshot of the final version.
The system was used to track ten celebrity runners of the 2008 London Marathon and was broadcast as a "cloaked application", allowing BBC staff to access it but keeping it hidden from public view. This proved the concept worked on a live environment.
Red Button Arcade
The idea behind the Red Button Arcade project is to provide BBC digital audiences with 'classic' arcade games playable from their set top boxes. By carefully selecting the games we choose to develop, it should be technically possible to give audiences a suite of playable retro games, across all TV platforms. Mark Hatton will be explaining his work on the Red Button Arcade in future posts.
BBC News content on Windows Media Centre
The application above was created to test how BBC News might look like on the Windows Media Center TV platform. Unlike traditional interactive TV applications, this one gets all its content over the internet via RSS feeds from the BBC website.
The purpose of this application was to provide a much richer user experience utilising the graphical capabilities of Windows Media Center and distribution capabilities from an always-on internet connection.
The application provides the user with BBC Red Button content overlaid onto BBC channels, similar to the MHEG applications on existing platforms. The application was written in C using the .NET framework. Shalim Khan will be writing in detail about this in the near future.
Where to now? As we continue to innovate within the Red button team and through One in Ten, you should be seeing more cross platform ideas. The ideas we are looking for should, where appropriate, work across Red Button, Mobile, Online and other future platforms as they come online.
Watch out for further blogs about One in Ten over the next year.
--
Ruhel Ali is a Development Producer working for the RAD Unit/Innovation Culture
Andrew Bowden writes:
There's a new addition to our office in West London. Sat in front of a green glass screen, where everything is surprisingly dark and difficult to photograph, is another part of the country. Selkirk in fact.
Well okay, the television of Selkirk to be accurate.
As we're in London, we don't normally get to watch Scottish Freeview, however Selkirk has today begun the process of switching off analogue TV. To support this, we've had to set up a whole batch of new systems and servers, which will later be used for other regions making the switch too.
But how do you test that your new systems are working correctly, when in another part of the country? Well thanks to the wonders of modern technology, it's possible to watch Scottish Freeview in London. As long as you're in our office anyway.
As the sign above the Selkirk TV set says "You are Here. (The rest of us are 300 miles in this [southern] direction)".
Andrew Bowden is a Senior Development Producer for the BBC Red Button Service.
Farah Fahmy writes:
On Thursday the 9th of October, What's On was taken out from the BBC Red Button service. This generated complaints from some viewers, and we have responded both within the Red Button service and via this blog.
The decision to remove What's On wasn't one that was taken lightly. To understand why we took this decision, I'd like to explain the processes we went through to get to where we are now.
In October 2006, we started thinking about how the Red Button service should prepare for Digital Switchover (DSO). DSO, which will replace all analogue signals with digital signals, is being rolled out progressively throughout the UK. It starts next Thursday, and the transmitter at Selkirk will be the first one to be switched over.
A "side effect" of DSO is the demise of Ceefax, as this is currently carried only on analogue.
One of the first pieces of work that we needed to do therefore was to create a gap analysis of Ceefax content against Red Button content. We knew that Ceefax carries more content than the Red Button service and that whilst the Red Button service can accommodate most of this, some Ceefax services, like Share Prices and Flight Arrivals, use up a lot of bandwidth on the digital platforms.
This was a big issue for us. We are constrained by the amount of bandwidth that is available for the Red Button service on all digital platforms. For example, on Freeview the Red Button text service has a total of 700kb/s of bandwidth. That space is taken up not just by content, but also graphics, the MHEG application, templates and some video and audio. Yet here was more content that we needed to fit in.
It was very obvious to us that there was no way we could fit all this content and still hope that the service would remain as accessible as it currently is. To find out how much slower the service would be if we added all this content, we ran a series of tests. The conclusion was as expected - the service took a much longer time to load if all Ceefax content was added. We know viewers like the performance to be as fast as possible so this provided us with a challenge.
Our tests also showed that we could only add an extra amount of content before the service started to deteriorate. The question was, if we couldn't add all the content we wanted, what content should we have on the service?
Running parallel to the technical tests was a series of discussions between the TV Platforms Group and our colleagues in the BBC's Journalism division, who produce our News, Sport and Weather content. Obviously all Ceefax content is important, but if we couldn't carry all of it, which ones should we carry?
A series of research projects was carried out, aimed at finding out what content was deemed the most valuable by Ceefax users. The results helped us decide what we felt was the best of Ceefax content, and this in turn formed the basis of the content that we offer on the Red Button on all platforms. We also looked at what content was available elsewhere both via TV screens, in newspapers and online via websites.
We agreed that these pieces of Ceefax content were needed on the Red Button:
- UK Flight Arrivals
- Community content (which includes information from voluntary organisations and Read Hear, the magazine for deaf and hard of hearing people in the UK)
- Farm Prices for the rural community
Now we had to find the space to fit all this content in.
This is not such an issue on the Virgin Media platform, as our space constraint isn't as great here. On Sky, we were broadcasting duplicate content on various transponders, so we took the decision to re-structure our content so that we avoid duplication as far as is possible. This meant that no content was lost, even if the journey to get to that content may change.
Freeview however was a problem. The service on Freeview was already as small as we could technically make it, yet we were still required to add more content. Was there anything we could lose on this platform?
Earlier in the year, we removed our Movies service. This definitely helped, but we still needed more space. After much debate, we came to the conclusion that the only service we could lose to make room for newer content was What's On.
When What's On was first launched, many Freeview set-top boxes did not include Electronic Programme Guides (EPGs). However, modern set-top boxes now do include the EPG. Therefore we felt that it didn't make sense for us to continue this service when it is available elsewhere, and when we need to use the space it occupied for other content.
We realise that some people are unhappy with this decision, but in our opinion, the experience of getting programme information alongside the broadcast and being able to tune to it is better via EPGs than the old What's On service.
As more and more of the TV screens become IP enabled then viewers will see more textual information being made available this way. Watch this space!
--
Farah Fahmy is a Development Producer for the BBC Red Button service.
Andrew Bowden writes:
Some point in the 1990s the BBC ran a series of on air promotions, telling viewers what this brave new world of digital was all about. A series of TV and radio stars told us that soon all programmes would be made in widescreen, and that we'd be able to see as well as hear radio.
Anyone who has listened to the radio via their Virgin Media or Freeview box will already be seeing their radio and on Tuesday 30 September, we launched our first radio service on the Freesat platform too.
At the minute, the Freesat version appears pretty simple, consisting of a station logo and LiveText - programme related information which is updated as you listen.
It's small - a maximum of 128 characters at any one time - but LiveText is perhaps one of the most challenging feeds that our technical team have to deal with.
The reason for that is the sheer amount of updates that are received. Each station updates its text roughly every 30 seconds - for some stations it's even more frequent.
Of course there's more than one station doing this at once - the same backend system is updating 17 different stations at once on Freesat, with the data coming from two different systems. Naturally each station publishes at a slightly different time, meaning that there is an update somewhere every few seconds.
Once published, the text has to get on air as quickly as possible as the data is time sensitive. The text could be related to a particular song that's playing, or short report that's being broadcast. The LiveText needs to get on screen whilst it's still relevant to what people are listening too! Keeping the time from publish to appearing on air low, is an important metric for all our services, but is most prominent on radio.
Still, once it's all done, it's a great service, providing a variety of background information, news headlines, weather and track information for many of the music stations. But if you'd rather not look at all the stuff we've put all that effort into, don't worry because we always provide an option for you. All our radio services on Freeview, Virgin Media and Freesat offer a screensaver option too!
Simon Lumb writes:
Let's say you've just made a change to some software you're developing that you expect an audience of thousands to use daily to check news headlines, sports results, the weather or the state of the markets. Let's say it runs on a digibox. How long would it take to press the keys the remote control 10,000 times and check that what you expected to happen, happens? When it comes to the shiny new Freesat platform, it takes us less than 20 minutes. Here's how.
Last August we were handed the brief to provide a digital text service for Freesat, the joint venture between ITV and the BBC to offer an alternative packaging of the free-to-air digital channels broadcast by satellite, due to launch in Spring 2008. The product manager, Andrew Bowden discusses the challenges on the BBC Internet Blog.
We were repurposing the channels currently available to view via Sky (or free to air satellite receivers). We already provide a complete BBCi red button service on the Sky platform. But that service is written using software licensed to Sky's platform (called OpenTV), which Freesat chose not to licence, so we couldn't just run that BBCi service on Freesat. Instead, Freesat uses an updated version of the software that runs the red button services on Freeview. It's free, it's called MHEG and it's an open standard.
We didn't have much time. But we knew that we had an opportunity to refresh the service. We took the Freeview service and asked how important each section is to our viewers? How could we improve the look and feel, the navigation? How many sections are there? How many pages in each? How is the information fed through to screen - how many feeds are there? How many back end systems will we need to update/port/repurpose? Once we had that we did some estimates to see how long it would take to build. Then we took the prospective launch date and worked out what the minimum we could deliver on launch day would be and what we could add in subsequent updates.
We concluded that News, Sport, Business and Entertainment would come first and deliver almost 800 pages of content. Then we could follow up with 300 pages of Weather shortly after launch. We scoped work on updating the content systems that supply the Sky, Virgin and Freeview platforms and had confidence we could generate the content. But there weren't any Freesat set-top boxes when we started. We couldn't build a digital text service blind. Well, we could but it would involve something akin to staring at The Matrix.
Luckily for us, BBC Research had been working out the grand plans for Freesat over several years. They developed extensions to the MHEG specification, worked with manufacturers to define hardware requirements and provided us a "concept receiver" that we could use to start building a service on. Essentially this was a Linux PC with a DVB-S decoder and a custom software stack built to emulate how Freesat was specified to work.
Then we had to build the software. For those that are interested, the systems that were built to drive the Freeview back end were largely based on the Perl programming language. We now use Java. We used CVS for several years: we have since switched to SVN. There was no automated build so we couldn't track and enforce stability or run automated tests on any changes we made whereas new projects are plugged into CruiseControl. Projects are being planned to bring Freeview in line, but we didn't have time to wait for them to complete. So, based on newer services and much learning undertaken in recent years we went for Java, the Eclipse IDE, using SVN as our repository, using Apache Ant and CruiseControl to automate builds and used Agile methods (SCRUM, XP, TDD) to manage the development process.
How do we build a service? Essentially we receive XML feeds from our colleagues in the Journalism department that are content based and described generically, e.g.
<Story>
<Page>
<PageTitle>Zombie plague sweeps the internet</PageTitle>
<Body>The summer saw a surge in the number of hijacked home PCs or "zombies", say security experts.</Body>
</Page>
</Story>
Fed through a custom content management system and out to our platform plugin, we add the look and feel for the platform and generate and build a data stream ("carousel") to be broadcast alongside the video and audio that make up digital television channels.
Our broadcast application is designed to be content driven, so the backend just updates the carousel (essentially a static file system) and the application picks up the changes and updates the pages you see on screen. We couldn't take the Freeview application and re-broadcast it exactly because Freesat has a different specification, which also includes lots of goodies that Freeview is missing.
Briefly, the new stuff includes an extended graphics model, a greater number of colours, true colour backgrounds, the ability to use Sport Interactive without visibly changing your channel, use of an internet connection (including https), the ability to get data from broadcast, the internet or local storage or have your box remember settings even if you turn it off, support for downloadable and smooth fonts, support for HD and lots of digital video recorder extensions to allow MHEG applications to exploit content stored locally (such as programmes you've recorded or downloaded). From our point of view this allows us great scope for future services, especially internet enabled ones.
Lot's of fun toys, but not much time! Luckily we have undertaken a lot of work internally to build new tools to allow for easier coding of the MHEG language. We call the new toolset "MHEGPlus". Anyone who was at Mashed might have seen it, and hopefully, after some licence issues are sorted out you should see it available for anyone to use. Watch this blog for updates and an in depth explanation of what the kit can do. Quickly though, it offers an interactive debugger including a visulisation layer (essentially a virtual set-top box, run on a computer server), integration into the Eclipse software development environment (including syntax highlighting), extended and simplified language syntax (think C++ over C) and FitNesse compatibility.
And it's FitNesse that provides us the most interesting piece of this puzzle. For the uninitiated, FitNesse is a software development collaboration tool, built around acceptance testing via a Wiki. Essentially, it allows software acceptance tests to be written in pseudo English, in a 4GL kind of way. We set up our FitNesse wikis to model interaction with our user interface. So a tester can describe user journeys in the wiki and the FitNesse backend provides a translation (a "fixture") that takes the wiki syntax, wraps it up as code and (effectively) calls our MHEG set-top box emulator. In reality it's a bit more complex than that underneath - our MHEGPlus toolset includes "MHEGUnit", a full unit testing JUnit style wrapper which the FitNesse fixtures interface with - but the result is that we have an almost natural language interface to testing user journeys.
e.g. The following wiki "code" navigates from the Home page ("bridge_default") to a News menu (menu_max9) and then uses the Yellow key to navigate back the way we came.
|check|scene is|tv|
|press|red|
|check|scene is|bridge_default|
|confirm text box visible containing|News Headlines|
|press|select|
|check|scene is|menu_max9|
|confirm text box visible containing|World|
|confirm no text box visible containing|News Headlines|
|press|yellow|
|check|scene is|bridge_default|
|confirm text box visible containing|News Headlines|
|confirm no text box visible containing|World|
Given we have a known input device and known language semantics, we can automate the generation of our automated acceptance tests. One of our System Testers built a virtual remote control so he could generate the wiki test scripts using a mouse and keyboard and then just copy and paste into the FitNesse pages. We also added the ability for the MHEGPlayer debugging tool to read and execute the scripts against code. So, if we find a bug using the automated tests then we can run the same test exactly against the code and debug it. Up next is integrating the generation into the concept receivers or adding some IR layers so we can just capture remote control key presses and bugs found in manual or exploratory testing can be recreated exactly. Anyone who is involved in software development knows that the less "randomness" and more repeatability there can be in bug discovery and reporting the better.
The final step, and my favourite bit, is the fact that we can plug FitNesse into our build system. So, every time the code is changed and checked into SVN the build system picks up the change and builds a new release. It compiles the Java code and runs the unit tests, uses FindBugs, EMMA, pmd, and Lint4J. If the build was successful, it generates installation RPMs ready for deployment to our continuous integration chain - a dedicated replication of the live chain that runs Freesat, including a dedicated internal TV channel that pretends to be BBC One. The build system also compiles and tests the MHEG code. This is where FitNesse, er, "fits" in. When the MHEG is compiled to ASN.1 (the broadcast data format) we inject it (play it out) to a broadcast carousel that is not connected to the broadcast system (i.e. compiles but doesn't go to air). The FitNesse test suite then connects to this carousel, injects to it a sample service and runs almost 10,000 assertions on the code. That's correct! Thousands of virtual remote control presses and other checks of the resultant data, all written by the test team in advance and added to continuously. The time to build and perform these tests is around 15-30 minutes depending on how much the server is doing at the time. The confidence we have in our user experience is awesome. I know that I can change something such as how the back key remembers where to go and that there is a huge safety net of automated tests that will guarantee the key presses and channels tuned to are all correct.
Currently we have 3 builds running and the little light on my desktop is green, so I know it's all OK. If the light was red it means that the last thing a developer changed broke something in the behaviour of the application. Everyone gets notified by email as well. The tests can be run locally too, so we can develop and check before we commit changes that the tests work. As things come together at the end the cumulative testing can check scenarios that we possibly couldn't check in the development environment. The three builds are our currently live service, which is in the Support phase - more to come in this blog about how we handle support. There's also the new JBoss enabled version of our backend due to go live any day now. When interactive TV was first created, Service Orientated Architecture wasn't invented yet. As we evolve we are moving our systems forward, implementing enterprise standard architectures. The My Sport Now team who built the Sport Interactive service for Virgin, Freeview and Sky went to air successfully using JBoss as a tool to manage their application as a web service. We updated our system to follow suit in time to launch the Sport Interactive service for the awesome Beijing Olympics. The other build is Freesat Radio, due to launch in the coming weeks, to give our digital radio stations a pretty face.
I hope you enjoy using the Freesat service and that this post has given a hint to how we try to push forward and refine the development process to support what some might have called impossible. We launched a complete new platform, using new architecture, with new extensions to a complex language; without hardware yet with complete confidence, no critical bugs and a fresh look within eight months. We followed it with a complete weather service a month later, Sport Interactive followed 2 months after that and Radio is on it's way. After that... well, I'll leave it as "to be continued..."
- Rob Hardy
- 31 Jul 08, 2:49 PM
Hello! The image above shows the burndown charts we use to track project progress - the period covered is from sometime in 2003 to mid 2007. Burndown charts are one of the artefacts used in agile software development; we've been doing agile development since at least before I joined, and we've found it works tremendously well. I'll share some personal insights here.
Continue reading "32 burndowns"
- Rob Hardy
- 28 Jul 08, 5:20 PM
Like any IT service, we have a continuous flow of support issues for the live service (or incidents, if you're an ITIList). Occasionally an issue is high profile enough to garner some outside interest, and I'll report on these here. Here's the first report.
Symptom: Aspect ratio incorrect on certain video streams (16:9 displaying anomorphically - it looks squeezed). This applies to the videos accessible under the Sport Multiscreen.
Diagnosis: The OpenTV middleware is responsible for handling the aspect ratio, taking into account the viewers' individual settings, and the aspect ratio of the broadcast video. If the application uses any of the OpenTV API calls to manipulate the video, then the responsibility to maintain the aspect ratio moves to the application. In this case our new OpenTV browser used for the sports service was overriding the middleware's automatic handling of the video aspect ratio.
Resolution: Code modified so that O_video_set_auto_mode is called with AUTO_ALL, and other video manipulation functions are inhibited for fullscreen video. Code was released to live on 15th July.
Ruhel Ali writes:
Many sports fans may have noticed a change to our digital text service on Sky, Virgin and Freeview. These changes were made to enable a more comprehensive sports area which enabled viewers to access all sport content, both text and video, from one location.
Here I'm going to write about the new service.
Continue reading "All change in Sports"
Paul Ashun writes:
The year is 2008 and IPTV projects are beginning to make their mark on the industry and imminently, our audiences. The exciting world of TV via Internet Protocols (and all that goes with it) is at our fingertips.
Within the BBC, I have set up a Future TV Platforms Special Interest Group where we share information regarding the newest developments in TV Platforms (including but not limited to IPTV).
After so much discussion I thought it would be worth giving the outside world an overview of what IPTV is.
The presentation does not aim to answer everything, but it does aim to answer questions such as:
- What is IPTV (or is it definable while it is still emerging?)
- How does VOD fit into IPTV
- What are some emerging models/companies involved in IPTV/VOD
- What technologies/formats/protocols are involved
Ladies and gentlemen, introducing What is IPTV? (PDF) (Powerpoint)
- Rob Hardy
- 15 Jul 08, 6:01 PM
On 26th June we jointly won the 'Best Use of Interactive TV' at the New Media Age Effectiveness awards, with our colleagues in BBC Vision Multiplatform Studios; the award was for an interactive service called 'How Green Are You?' Here's the blurb: '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.'
In order to see this content you need to have both Javascript enabled and Flash installed. Visit BBC Webwise for full instructions
This is a good time to go under the bonnet for this show. In TV Platforms, we've built a collection of authoring tools (or products), one of which we call the Two Stream Quiz. This product has been used for many shows, such as How Green Are You, Spooks, Child of our Time, and Doctor Who: Attack of the Graske.
Continue reading "Under the bonnet: The Two Stream Quiz"
The BBC is not responsible for the content of external internet sites
© MMVIII~RS~q~RS~~RS~z~RS~40~RS~)