If you found my content helpful then please consider supporting me to do even more crazy projects and writeups. Just click the button below to donate.
In Part 1 of this post we looked at a brief background of Object Based Media, the Data Model we created and StoryPlayer. In this post we are going to look at authoring that data model and the experiences that have already been created.
Backend
With StoryPlayer and Make Along: Origami Jumping Frog we had proved the viability of the data model and audience playback of it. The StoryKit authoring tools and backend to go with it didn’t exist yet. This resulted in the Make Along having to be hand coded in JSON. Therefore, the next step was to build out the backend. The backend eventually resulted in a quite complex system of IP Studio services, transcoders and data stores. The first part of it to be constructed, however, was the Data Model Store (DMS).
The Data Model Store was a NodeJS REST microservice using Express, Sequelize and sitting on top of an AWS PostgreSQL database. Much like the other microservices, this API was designed to be stateless to allow horizontal scaling. Using the JSON schema of the OBM data model, data is validated both into and out of the database ensuring consistency of the data. The initial implementation was fairly inefficient and hard to work with so I led a complete re-architecture of the database structure. I used MySQL Workbench to design the structure and feedback the plans to the team. This design was implemented and made the DMS much easier to work on. On top of this, over the time I was on the project I optimized many endpoints when increased user numbers started to strain the system. This taught me a lot about Sequelize and PostgreSQL optimization.
I took on a lot of the responsibility of the DMS. Along with deploying it, I also maintained a lot of the code that integrated it with legacy IP Studio services and wrote and designed the pipelines that handled media processing and uploading within the private part of StoryKit.
StoryFormer
The next tool to be developed was the authoring tool, called StoryFormer. This was the critical part of the toolkit as it is the component that would allow creatives to be able to make OBM experiences without software development experience. Again it was deployed as a microservice with Javascript frontend running React, Redux & React Router. The communications between frontend and backend was over GraphQL and both were originally written in Flow before being moved over to TypeScript.
I was heavily involved with this tool like the others and was responsible for deploying the system as well as implementing Audit logging, authentication and authorization. I achieved this by fostering a collaboration with the Partner Platform team which sits on top of BBC Login. This allowed us to enable authentication and authorization on StoryFormer for everyone in the BBC easily. This collaboration lasted throughout the project and we often were the test bed for new features of the Partner Platform which was amazing.
Experiences
The authoring tool, media processing pipeline and scalable audience playback systems were all ready for use. As such. we were ready to let creatives loose with the tools to see what they could create.
Click1000
The first team to use the tools were the BBC Click team and they created a special 1000th episode using the toolkit. Click1000 was what they produced. The experience had a staggering amount of content in it and was a wonderful showcase of what StoryKit could do. Audience interest was also amazing with the experience hitting 500,000+ of viewers. You can read more about the episode on BBC News. The fact the system was stable with this many users showed that we had engineered it well. If you’d like to know more about the technical backend details then see my IBC talk.
HDMAdventure & Others
Other experiences produced whilst I was working on the tools also include a documentary about Instagram called Instagramification, a His Dark Materials find your daemon experience called HDMAdventure and a showcase of current BBC R&D work called R&D 2020 Showcase.
All of these experiences showed a different facet of StoryKit and Object Based Media experiences and were generally well received. In particular the HDMAdventure experience also received a similar number of viewers to Click1000. The most interesting part of these experiences was the rich analytics coming back from the system. I highly recommend reading my colleagues blog posts on these analytics and what it allowed us to find out here and here.
Automated Story Checks
During production of these experiences it became clear that mistakes were made in authoring which were not picked up until late in the process. To aid this I developed a selection of authoring checking scripts to look for common issues like missing links, incorrect assets and broken media. These automated scripts became extremely valuable during the HDMAdventure experience and eventually led to the production of an author checking tool called StoryAnalyser.
Summary
Over the course of this project we’ve taken an idea and turned it into a successful product that is being used by teams across the BBC. Several experiences have been released using our tools with many more to come as we continue to learn the pitfalls and easy wins of Object Based Media.
Personally, I’ve been responsible for a large chunk of the system design and code. My main responsibilities were developing, maintaining and keeping the backend running. At some points during the project I was handling this on my own including managing deployments, keeping the build server running and debugging problems in the large system of backend microservices we had. I’ve learnt and applied a lot of knowledge to be successful at this, in particular a lot of knowledge in AWS, troposphere and CI. I also learned a lot of frontend development and UI design as I was often developing those tools too.