Uncovering the MOLE
A few months ago, before the leaves began to fall and before the cold seeped in and before Jedward forced their way into our living rooms, I wrote a post about what it was like to work in a Live production environment managing the Red Button service for Glastonbury.
I mentioned that I was severely hampered by the content management system we use to build interactive services like Glastonbury. This system was absolutely fine for building a service pre-transmission. We build it, leave it alone and the service plays out with no fuss. However having to coax this system through a live event where constant updates are required of it is rather like trying to drive a tank in a Formula One race.
It was therefore decided that a new system was needed - our very own Brawn F1 version so to speak - which would enable us to make quick updates with speedy response times.
One of the problems with the original system is that the changes that we need to address for updating interactive stream labels, text for the Blue menu and, text page information are hidden deep within the depths of the system, and all on different screens.
In order to change these quickly involves much digging around and navigating between many different screens which take forever to load. As a consequence, three changes that might need to take place over a minute would take over 3 minutes to publish through. This might seem inconsequential but it doesn't exactly look great if the Kings of Leon are playing on the main stage and the service states that you are watching Lady Gaga!
So the new system required all the information that needed to be changed to be grouped in one place for easy access and to enable quick publishing. Thus the production tool MOLE was born (if anyone can guess what MOLE stands for you may win a fantastic prize [1]).
We built the following interface that allowed us to have three main tabs on which all the information we needed to change was easily accessible.
So - how does MOLE actually work?
Well we enter text into this lightweight web-based interface which then populates a snapshot of a particular XML output from the original tool we use to build the service. This populated XML can then be published directly to part of our publishing chain along with the original images from the service. This means that anything we publish in MOLE will overwrite what was originally published.
Imagine, therefore, going to the bank and needing to deposit a cheque. The original publishing system we use would be like having to wait in a long line where every part of the publishing process represented someone ahead of you before you were able to get to the cashier. MOLE allows us, with elbows out and no apology uttered, to push into the front of the queue to deposit our cheque quickly. Or put another way gets you pole position!
MOLE was used for the first time during the Reading and Leeds festival and by all accounts it was a smooth début. While the difference on screen might only be minimal it is another example of the team here trying to improve the on-screen experience, and from an operational point of view it makes things a lot easier. It will certainly allow for a less stressful experience for our Red Button production team when the festival season kicks in again next year!
[1] due to stringent ³ÉÈËÂÛ̳ competition policies and guidelines, it should be noted that the prize is having the warm glow of knowing you are a very smart cookie indeed. Continue reading post.
Chris Tangye is an Assistant Development Producer for ³ÉÈËÂÛ̳ Red Button.
Comments