• Print

Mobile native publishing: The rise of dynamic content services

Why our concept of content must evolve in the post-PC era.

One reason that industry disruptions prove so vexing to market leaders is that disruptive waves simultaneously barrel through assumptions about customer needs, industry economics and operational best practices.

Consider the case of the motion picture business, an industry that was disrupted when the “talkie” — once derided as a costly gimmick — subsumed the silent picture in the 1920s.

The takeaway from the film industry’s transition is instructive. The talkie not only changed how movies were made and the economics of the business itself, but critically, it changed our concept of what a movie could be.

In doing so, it transformed the medium forever (The Speed of Sound by Scott Eyman is an excellent book on this topic).

Disrupted by digital

As we move toward a post-PC universe of 10 billion mobile devices, a similar disruption is playing out in the publishing business.

Print media is patient zero in the ongoing saga of “disrupted by digital,” an unstoppable force that has decimated one time toll road businesses like newspapers, and is threatening to squeeze out the last breaths of magazine and book publishers.

That this occurs at a time when physical bookstores are also under assault is hardly a coincidence given the tight links between publishers and bookstores on book distribution, discovery and monetization. The brutal reality is that when an industry is disrupted, the entire ecosystem feels the pain.

The medium is the method

Take a moment to ruminate on the significance of iPhones, iPads and Android devices, and their emergence as a “broadcast-scale” environment for discovery, monetization, delivery and consumption of all forms of media.

The talkie wasn’t destined to become silent film with words, so too it follows that in the age of smartphones and tablets, publishing will evolve to become much more than a simple carbon copy of print.

Every medium, after all, has its own set of native methods, and these methods, in turn, shape the medium.

Case in point, any person — be they toddler, teen or techie — instantly recognizes mobile native functionality for what it is: more alive, more optimized, and more dynamic than the mobile-web-based equivalent. Right?

That explains why Google, the king of the web, delivers its own killer mobile apps as native apps, versus focusing exclusively on mobile-web-browser-based experiences.

The reason for this is simple: you have to design experiences for the environments where they’re going to be consumed, and great user experiences are native, not converted into a lowest-common-denominator format from another medium.

An extensible model for mobile native publishing

So if publishing must evolve, what does this mean for publishers?

Most basically, it suggests that whereas static text and pictures define our current concept of publishing, in the mobile era, we need to think about what is being “published” as a native app that re-configures itself based upon the content being served. Logically, this type of system autonomously generates data.

This has significant ramifications for how such content is made, what it can do, and the underlying systems required for delivering and receiving the same.

But, the upside of thinking about publishing along these lines is that it enables new types of content-driven experiences that are interactive, responsive and analytical.

These experiences can incorporate play, learning, testing, rewards and assessment. This opens the door to a richer set of outcomes for users and a wider range of narratives for brands and publishers to cultivate with their audiences.

From a systems-design perspective, the ideal model is one that delivers a native experience and offers developers an agile content-update model, just like the web.

This implies a hybrid approach that is one part native client and one part cloud.

Dynamic Content Service Model

The hybrid approach: one part native, one part cloud

You can think of the native client as a kind of configurable state machine that is pre-instrumented with all of the workflow templates that the runtime needs to complete designated jobs to be done, be they games, exercises, puzzles, quizzes, etc.

Resident in the cloud is a JSON-based content layer that provides interfacing methods for content to: A) Automatically download from the cloud into the device; and B) Integrate with the runtime’s available workflows in a composite fashion. This layer includes settings that define active functions, specify preferred layouts, and establish the contextual state of the system.

Because this approach creates an abstraction between function and form, new content and new presentation schemas can be downloaded outside of the build process. This means that new derivatives of the workflow templates can be added at any time to extend the experience for the user. It also means that an app store submission is only required when new workflow templates are added.

Unlike the web, the system can work fully and optimally in both online and offline modes.

Case study: Macmillan Books’ “Play and Learn with Wallace”

So how does this work in the real world? Consider “Play and Learn with Wallace,” an early learning series of apps developed via this same model by Macmillan Books. (Disclosure: my company co-created the system with Macmillan.)

Derived from content in Macmillan’s Priddy Books unit, the series incorporates titles for math, drawing, spelling, and cognitive and creative skills development.

The client runtime is pre-instrumented with dozens of templates for core workflows, which in their generic state look like the following:

  • Drag complete set into bounding space
  • Correct answer only remains upon completion
  • Matching pairs card games
  • Object match in a series

In addition to the JSON-based content layer, the system provides simple access to personalization, scoring, assessment and rewards functions.

From a design and user experience perspective, this type of system offers a great deal of variability, while remaining accessible to consumers, creators and illustrators.

A scalable model for dynamic serializable content.

A scalable model for dynamic “serializable” content.

This is because in addition to the runtime being able to host hundreds (or even thousands) of these workflow templates, individual screen loads can be randomized or re-mixed, and design layouts can be shaped by either algorithms or pixel-specific coordinates.

In summation, the rise of dynamic content-driven services represents a rethink of what publishing can become in the post-PC era. It is the talkie to the silent film.


tags: , , , , , , ,

Comments: 4

  1. It will be far more interesting when they can incorporate real content from their own world into these stories. I suspect even the dullest child will get sick of Clifford The Kinda Brown Dog after a couple hundred iterations.

    • Fair perspective, although some of this is age bound. Really young children are all about repetition, and many of the most durable games in that segment are incredibly repetitious (speaking as a parent).

      That noted, there is nothing incongruent with providing either local (runtime level) or cloud based interfaces for customizing with the user’s own content. My experience here, having built a bunch of products where the enduser customizes, is that a fairly low percentage of users are serious customizers. There are definite categories, though, where it’s a great use of the model. We haven’t gone that path so far in this particular implementation.

  2. Is an environment necessary for each device or OS?

    How far can one stretch the basic purpose of the runtime environment to do X and Y using the same or different data repositories? For instance, a runtime that read text aloud and another that allowed notes to be taken beside a text. Or, a text to be read and an editor space in which to write.

    • Great questions. As to the first, layouts can be algorithmically generated, such that a centered 2 * 2 grid is always centered regardless of the device’s aspect ratio. The underlying framework that this particular system is built around uses Corona, so the complexities of multi-platform (iOS, Android, Kindle Fire, etc.) are less of an issue.

      Now, where that becomes a bit more nuanced is that let’s assume that the creatives want a pixel specific layout, then you are going to need a separate JSON content layer for each form factor. The way that we built this, it’s pretty straightforward in terms of how client and cloud sync up, but from a product lifecycle manage-ability perspective, there are tradeoffs between automation and target specific precision.

      Now as to how far you can stretch these things, the short answer is it’s proven to be pretty malleable. We have created templates for things like coloring pages, connect the dots drawing activities, dynamic charts, etc, and the range of achievable derivatives (what we call a playspace) has proven both broad and deep.

      I will say that your question of data repositories touches upon a related question of what you put into the cloud layer and what you put into the runtime. Our experience was that some elements that we had assumed would be uniform and, thus we pushed into runtime, we later concluded needed to be configurable at the template or derivative level.

Leave a Reply

Your email address will not be published. Required fields are marked *