CBeebies Storytime app: Downloadable library gives more choice to kids and parents
Senior Software Engineer, BBC Children's
In July 2014 we released CBeebies Storytime - the interactive storybook app designed to help children and grown-ups enjoy stories together, which was developed entirely in-house here at BBC Children’s. I put together a blog post all about how we built the app, which can be read here.
Since it’s release, the original version of Storytime has been downloaded over a million times across iOS, Android and Kindle, and has been used to read millions of stories to some of the youngest members of our audience. The success of Storytime has been great to see; however the approach we took with the original release did come with a few areas we wanted to improve and build upon.
Firstly, while it offered a good range of stories to suit many tastes and reading levels, the content was all built into the app itself, meaning it was a little difficult to add new content - we put out a 1.1 release containing two new stories, but this was still a ‘new’ download of the whole app.
Secondly, because the app had all of its stories built-in, it became fairly large in terms of file size. Finally, we also wanted to greatly enhance the accessibility of the app to users with visual and motor impairments, so we could make Storytime available to as many members of the CBeebies audience as possible.
With these concerns in mind, we set to developing version 2.0 almost immediately following the original release, and it's a radically enhanced experience: instead of a single large app containing a set number of stories, the new version of Storytime is a small app that allows users to download new stories from the internet (more on how this works below).
The main advantage of this new approach is that the user now has the ability to essentially curate their own content in Storytime. Where previously the user would be potentially stuck with stories they had no interest in, they can now choose to delete any unwanted stories and replace them with new ones.
Once downloaded, the user can keep the stories indefinitely, or until they choose to replace them with new ones. The book has a total of 12 available story ‘slots’ in the book, mostly to avoid performance and memory issues. It’s possible in the future that we can raise this cap too.
The second big win with this approach is that CBeebies now has the ability to continually add new content to the Storytime virtual library - no app updates are required for the user, as we’re now in a position where we can simply add new stories to the remote library at any point and make them available for download. This is a huge change for Storytime: it’s gone from being a single app, to a flexible and future-proof platform.
As with the original release, Storytime’s design was handled entirely in-house, which allowed the UX team to really get under the skin of solving how we’d present this new system to our users. At its core, the system simply had to present a list of stories to the user, allow them to download one onto their device, and delete it. However within this seemingly simple requirement there was a wealth of complexity that needed addressing.
Additionally, and arguably most importantly, this process had to be child-led and not controlled by the grown-up, meaning that a standard list of panels, buttons and words simply wouldn’t do the job. What the UX team came up with was an absolutely beautiful solution to presenting a list of stories.
The way it works is like this. First, a new cloud icon was added to the 3D storybook screen:
As well as a “blank” page at the end of the book too:
When the users hits either of these icons, the camera seamlessly pans up away from the book and into the sky, at which point all of the available stories are presented as playful dangly clouds:
Each cloud contains a single story, with supporting voiceovers for younger users. Pressing a cloud flips it over, and shows some description about the story, along with a single big “download” call to action:
When the user hits the button, the story is downloaded to the device, with progress shown in a colourful rainbow preloader:
Once the download is complete, the rainbow disappears and the cloud descends back down into the book, which is automatically flipped to a blank page. The cloud then “rains” the story into the book...
…and the story grows out of the page and becomes part of the book:
From this point, the story is permanently installed in the book, and can be taken away and read offline. There is also a large amount of edge-case handling built into this process too: as children control it, we need to ensure that errors are handled well, and information is communicated back to the user in simple clear terms. We also had to factor in the portability of the app, and its potential use cases: for example, users cannot delete stories from the device if they have no internet connection, to prevent scenarios where a child may delete content and then be unable to download it again.
The .story Format
Re-architecting Storytime to support this functionality was surprisingly complex: the player and much of the 3D book front-end needed to be changed so that new content would work within it. The key to this was understanding how stories needed to be stored and served to the app - we need something that would allow us to wrap up everything that makes a complete story, so it could be stored and maintained online safely, and consumed robustly by the new Storytime app. After some lengthy technical investigation, we created a dedicated “.story” file format especially for the app.
The .story format is actually just an uncompressed ZIP file, with a customised extension for ease of search, and a very tightly defined content structure. Compressed ZIP files take some time to work with on devices, and didn’t offer us a significant file size saving in most cases, so we opted for uncompressed files (typically a complete story takes up between 15-25MB including all audio and 3D textures). The contents of the file are structured extremely strictly, so that we can ensure our external creatives (who actually create the content) can work within a consistent framework, and build structurally consistent and testable stories - even if the story content itself varies wildly.
So now we have our app, and we know what our stories look like: the final piece of the puzzle was to change how our content pipeline worked. For the first version, creating and releasing content was an entirely developer-led process. A third party built the stories, which were then signed off by the team here. Our development team would then integrate the stories into the app, and handle the app release process. For the new version of Storytime however, this process had to be radically reworked - this version is designed to be installed once and then have content continuously pushed out to it. Therefore, this process had to be usable by none-technical staff, for example our editorial colleagues, or a project manager on the team.
This was achieved in a number of ways. The stories themselves are served from an Amazon S3 instance, which is in turn sat behind the Children’s Binary Store front end. This allows none-developers to create and manage files on S3 with a straightforward toolset. On top of this, we have a number of validation steps that cover both the remote data, and also things as fine-grained as building the story assets themselves.
For example, we use an automated build process to take our story assets and compile them into the finished .story binary - this process doesn’t physically complete if errors are found, meaning that it’s much more difficult for someone none-technical to make mistakes during the build phase. The story list for the library is also validated, meaning that if an error is introduced (say for example, if a story listing is accidentally duplicated), the error will never get close to live.
As well as broad content validation, we also do some very fine-grained checks on the assets to ensure that they are valid on mobile platforms. The biggest of these is to ensure that there is no code present in any of the SWF assets that make up our stories – this is prohibited by the iOS app store for security reasons, and will cause an instant app rejection, so we’ve taken this validation stage very seriously! To accomplish this, we’ve leveraged an AIR SDK tool that will confirm very clearly if the SWF’s are “clean” of code or not – something as small as a single “stop()” action anywhere in any single asset will cause a rejection flag, so this tool allows us to say with absolute certainty that the assets are OK to go up. In fact, this check is so tightly coupled with the process that constructs our .story files that we’re unable to build an actual story if any code is present, as we’ve set it to halt the build and throw and error if any is found.
The final major enhancement we’ve added to Storytime is vastly increased accessibility options. Both iOS and Android have a number of excellent native accessibility features that allow users with visual or physical impairment to interact with their devices. Notably, these include robust text-to-speech options, and things like single switch control methods and touch-explore options. However, one of the major drawbacks of sandboxed technologies like AIR and Unity is that their contents can’t be indexed in the same way that a native app can be, so for example the device isn’t able to see our “read to me” button and so cannot read it out.
Our solution for this was to mimic quite closely the same functionality within Storytime itself. We added a togglable “auto scan” mode, in which the app is fully navigable with a single press on the screen using configurable timed item scans. This mode also features optional voice-over on all buttons, screens and interactions, meaning every part of the experience can be accessed.
This functionality may even be able to be leveraged by things like external switches in the future. As well as being manually controllable from the Grown-ups menu, we also hook into the native accessibility features of the device too – if the user has any native features turned on, we’re able to detect this and handle their route through the app appropriately.
Storytime also continually monitors for changes in the accessibility features on the device, so it can handle common scenarios like triple-click shortcuts, which are used to quickly enable and disable features on the device.
The end result of these sweeping enhancements is something we’re very proud of – Storytime 2.0 is now finally a robust future-proof platform that users can keep coming back to again and again, and we’re able to keep our content fresh, exciting and fun without users needing to constantly update their apps.