Transmedia storytelling (also known as transmedia narrative or multiplatform storytelling) is the technique of telling a single story or story experience across multiple platforms and formats using current digital technologies, and is not to be confused with traditional cross-platform media franchises, sequels or adaptations.There is a brilliant buzz going on nowdays about the importance of a simple thought. "never think of building a mobile application. Instead you need to think about building a single application that presents across multiple devices: mobile, desktop, tablet - or whatever device your users might use." says Martin Fowler in his post about the topic. I would like to pick up where he left off, and share a little secret which I found very useful.
From a production standpoint, it involves creating conten that engages an audience using various techniques to permeate their daily lives. In order to achieve this engagement, a transmedia production will develop stories across multiple forms of media in order to deliver unique pieces of content in each channel. Importantly, these pieces of content are not only linked together (overtly or subtly), but are in narrative synchronization with each other.
It all begins with a product idea, which is then implemented by several platforms.
Let's use Twitter for our example. Twitter's business features are implemented across many different operating systems, and even more software platforms. You find clients written in almost every capable programming languages, for reasons one would never imagine. There is even a Twitter client for the unix console. But what can you know for sure about each and every tweet capable software out there? It can surely tweet, or at least retrieve tweets. Twitter's core business features are tweeting, and allowing users to view others' tweets.
Remember, I am using Twitter as an example, I have no clue how they go about this topic at all.
The common part in each application is that they all have a product vision. a goal, they want to achieve, a purpose of their existance. They all have at least one feature which is mission critical for their business to function. Google would take an enourmous hit if the search engine would just stop working. Twitter would probably not be in business if people would be only able to tweet for themselves.
There are always a set of Business critical requirements which must work. In the realm of transmedia applications, the next layer which needs attention is the platform layer. How would you feel if the routine you've gained using an application on the iPhone 4 would be utterly useless on the iPhone 5? Or if you switch to another vendor's phone, you wouldn't even recognize the Twitter client? A high profile company does not want to couple their users' experience to the device their product runs on. To address this issue, they have a set of requirements that must be met on every mobile phone for example. These are Platform specific critical requirements. I emphasise critical because I believe that a negative user experience is indeed a critical failure if it could've been avoided by being consistent.
Though the whole project domain has one set of business requirements, it can have several platforms. Mobile, Tablet, Desktop, Web, you name it. Within each supported platform, lies some number of applications. These applications must implement every single requirement provided by the platform they run on, and the business needs they serve. If this fails, the users will find the problem and react to it. An application on th other hand has the freedom of having its own set of features too. They can be experimental features for the platform, or some nice extras the programmers thought of. It doesn't matter too much to the product until it adheres to the upstream requirements.
In my next post, I will show a method how you can use BDD to support this structure, and how to share the requirements using git.