Saturday 3 November 2012

Requirement structure of transmedia applications

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.

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.
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.

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.
Let's narrow our scope to the official clients. Imagine, that as a brand, Twitter has to make sure that there is no major difference in the user experience even if the devices are all so different. They cannot rely on embedding the website, because it causes more incompatibality, and more bandwidth consumption for the end user. So they create specific programs for the different platforms.
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.

What matter is knowing which feature of the product lies where on this pyramid. Introducing a change on the bottom is easy. One application of one platform needs to be changed. If we're talking about a carefully crafted software, the change might even be less than 10 lines of code. Piece of cake. But what would happen for example if Twitter would decide to remove the capability of posting textual updates, and would rely solely on pictures? Each participant of the product should know the impact of the changes they are about to introduce or communicate. Even if a businesss level change seems to be a good idea, it is most likely worth to try it out first, to minimize the potential waste. What if the new cool idea is never used by the users? Is it worth implementing it on 50 different applications? If a new feature is a hit on a mobile device, will it work on the website too?

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.

No comments :

Post a Comment

Note: only a member of this blog may post a comment.