³ÉÈËÂÛ̳

We have been showing our ideas to the rest of the partners in ViSTA-TV to show the sort of thing that's possible, and to help guide the requirements on clustering, recommendations and data processing. We will do some more work later in the project, building on what we've learned in making these prototypes, to make an integrated testable prototype.

To generate the initial ideas, a few of months ago we held a workshop involving a mixture of ³ÉÈËÂÛ̳ and non-³ÉÈËÂÛ̳ people. Four proposals came out of it:

• 'Heartbeat EPG' - a heatmap showing what people are watching now
• 'Infinite Trailers' - a 'channel of continually playing clips of available content on iPlayer, which learns what you like, presenting you with better suggestions depending on whether you skip or like an item.
• 'Radio Dashboard' - a dashboard of real-time radio-related data for the Audio and Music team to quickly see any problems
• Taking iPlayer to you - a variety of techniques for integrating iPlayer with your online life more closely.

Of these, the first three each seemed to have a core idea that we could develop into a prototype in a short period of time. Dan Nuttall, Chris Newell, Ant Onumonu, Andrew Wood and I got together as a team, set aside a week for each idea and created a prototype for each. In practice things took a little longer than we had hoped, but we now have prototypes that we can demonstrate to project partners and within the ³ÉÈËÂÛ̳. We hope to develop some of these into public prototypes in the future.

I want to thank the workshop participants, and the people we've talked to within the ³ÉÈËÂÛ̳ who've offered very helpful advice on the directions to take.

In the rest of the post, I've asked the team to describe what we've made in a little more depth, including some of the technologies we've used.

Chris provides some background to the underlying data: "As the ViSTA-TV system is still under development we needed a simple way to extract interesting real-time statistics from our media server logs. Luckily we had an existing system which maintains a table of open iPlayer streams in memory from which we could collate statistics for channels, programmes and user platforms. The only limitation we had was time - it can take 20 seconds to download the minute-by-minute logs and update the table during busy periods, leaving 40 seconds to collate the statistics. This was enough but the ViSTA-TV system should provide a more efficient approach."

Heartbeat EPG

In some ways this was the simplest of all the ideas, but also very powerful: show in real time what people are watching on iPlayer - both 'simulcast' (programmes watched online at broadcast time) and 'catch up' (programmes watched after broadcast).

During our initial discussions we thought it would be interesting to show updates without reloading the page, and this became the core of the prototype. Andrew decided to take a clean, simple 'list' approach to the design, and included a way to show the proportion of the audience watching each programme, highlighting the most popular item.

Andrew says: "The design pattern for this was essentially a table with the top 20 results. First quick sketches were made and discussed with the team, this was a very quick and iterative process due to time scales. Once the team had agreed on the route I passed mocked up Photoshop assets to Anthony for the front end build. I then had some time before our next sprint to look at a more conceptual route for the UI. Using colour and scale I mocked up the "ball interface" We revisited this for the Radio Voyeur sprint. I also met with Chris Kimber to discuss a version that would work as a dashboard for his team. This is more specific as it shows 2 columns - one for Live content and one for On demand which I have art-worked. The rest of the design team within IRFS have seen this work and a possible outcome is to develop it as a 10% project for responsive design experimentation."

The underlying APIs from Chris that we needed for this prototype were already in place. Dan says:

"The backend needed to be able to handle multiple incoming data streams and to push that data out to clients as quickly as possible. was the perfect match for this. The application polls Chris' API for new data points. When new data is found, we search for applicable metadata using a combination of ³ÉÈËÂÛ̳ Programmes' API and our own programmes' powered datastore. Once the dataset is complete, connected clients receive the new information over , using . Socket.IO has a very straight-forward API, allowing us to pass a simple JSON object to Ant's client-side code each time the data changes."

Infinite Trailers

The idea for this prototype was a continuously playing channel of ³ÉÈËÂÛ̳ TV videos available on iPlayer, which the user could choose from to play now, or indicate 'like' or 'dislike' to get better suggestions. The initial idea from the workshop was to have skip or play, but this didn't give the recommendation engine enough information - just "dislikes".

The team decided to create a mobile application for this prototype: Ant in particular was interested in looking at HTML5 video for mobile. This turned out to more difficult than we initially thought, as browser vendors on mobile have different interpretations of some aspects of HTML5 - but we still managed to create a prototype that works on Android phones, iPads and as a bonus, in Chrome, and Ant says he "learned a lot".

Andrew says: "My starting point with this sprint was a smart phone interface - the concept is a passive experience for the user - flicking through trailers - so the design needed to be simple and uncluttered. A simple title screen labels the content then fades off, the user has the option to move on, or add the trailer to their playlist. Once the front end was in development mode I had some time to look at other options - the egBox platform (a two-screen prototyping system) seemed appropriate to the concept - so I mocked up the 2 screens (trailer and playlist) - as with the EPG longer term development would implement responsive design templates."

Dan says: "Ensuring that each recommendation was backed by a video clip was the key to the liveliness of this application. Chris' API was polled every few minutes to keep the pool of available programmes up-to-date. As new programmes are found, their identifiers ('PIDs') are entered into a multi-state system, backed by a database. First of all, metadata is applied using similar techniques to the EPG application. With this data, we then query the to see if the programme has been captured internally. If this is successful, we schedule a snippet to be taken from the first minute of the programme, of around 30 seconds in length. As these clips become available, they are downloaded and put onto the web server. When all the clips are downloaded, the recommendation data is copied to the server, refreshing the available programme list."

Chris: "The recommendations were obtained using the client-side recommendation engine we use in an existing prototype recommender system called . The engine provides a list of available programmes which is ordered to reflect the preferences of the user, based on programmes they like and/or dislike."

From Ant: "Since the videos from the Snippets Transcoder service are provided in h.264 we could deliver the trailers to users with a HTML 5 Video player that worked on the Desktop and Mobile. We also made use of Local Storage to store the user's playlist. Video playback currently only works in Chrome, Safari and Internet Explorer. Support for h.264 in Firefox is in the pipeline and can be accessed via nightly builds. We wanted the videos to auto play once the application had initialised but this only worked on the Desktop. We also noticed on the iPhone that the video played only in the native player. This wasn't an issue for the iPad."

Radio Dashboard

This prototype was designed for internal ³ÉÈËÂÛ̳ use - to give a technical or production team an overview of audio IP streams, but also allowing them to dig into the data in detail to identify potential causes of increases or decreases in traffic. The design goal was therefore to show as many pieces of information as possible in a way that allowed the user to make sense of them.

Andrew comments: "The starting point for design was to implement the "ball interface" from the EPG design sprint earlier. The "balls" are vector graphics of the Radio brands - which allowed Anthony to scale them. The intention was to make something that looked and responded dynamically - so when the page updated - the balls would grow / shrink and move. A scale had to be set for the smallest ball size based on legibility."

"The user can click on any of the "balls" (radio programmes) for more contextual information - the design pattern used here is a simple lightbox which displays a graph showing viewer figures from the last hour on desktop and mobile."

The third screen shows even more detail - the number of users joining and leaving the channel in a five minute period and where they go, the number of tweets in that period, and what track was playing, if any.

Dan says: "The backend of this system was a frankenstein-build of the previous two backends. We used the Node.js server from Radio EPG and added Chris' additional data streams. We complemented these with data from other ³ÉÈËÂÛ̳ APIs; social media information from Buzz and music metadata from our internal playout system. It was important for data points to be emitted only when fully-formed with data from all the available sources. We added the multi-state system from Infinite Trailers in order to ensure all sources are integrated before updating the client in real-time. Every five minutes, an aggregation process iterates across the recent data points and emits the collated data, producing the 'blobs' in the activity graphs. Like Infinite Trailers, the data is stored locally in SQLite. This allows us to offer the previous 1 hour of data immediately on connection, while keeping users up-to-date as new information is received."

Ant: "The frontend for this application consisted of three charts built with SVG and HTML. Initially we used a JavaScript library called but switched to because it was easier to work with the vector assets once they were converted into ¸é²¹±è³ó²¹Ã«±ô JSON. One challenge we encountered was displaying the bubble chart in a random manner without any overlapping. This would have been easier if the logos were the same size. We ended up using a technique called circle packing to ensure the logos didn't overlap whenever an update occurred. It should also be noted that we found animation performance was greatly increased by animating parent divs and not the SVG elements directly."

Conclusions

Due to the rapidity of the prototyping process we chose, we cut some corners and made some assumptions, but as a team we feel like we learned a lot because we made working systems. We'll take this new information as an input to the decision on what to build for our main application in ViSTA-TV, but we can also show these prototypes to colleagues within the ³ÉÈËÂÛ̳ to see if they are interested in the approaches we have taken; and use the technical knowledge we've gained from this work in other projects too.