By Mark Harris, September 18th, 2010

So in parts 1 and 2, we started working with custom content types, and then moved on to building relationships between our various pieces of data. So now what are we going to do with it all?

Linking Content

Now, we have the makings of a kind of dictionary of our film. We have entries for characters, external blogs, storylines, short films, short stories, etc. One thing we can do is simply make our website the dictionary. This would simply involve writing a new theme, or altering an existing theme to take advantage of the structures we’ve created. The related plugin already provides an automatic “related” section at the bottom of each post, if you want it to. But it might be cool to have things in our content hyperlink to their entries in the dictionary. We could manually create hyperlinks in the body of each post. But that kind of pollutes our data. With what we want to do, we might not always desire HTML hyperlinks. So what about creating our own kind of tag system? This is pretty common. for instance, maybe create a tag that looks like this:

[CHARACTER=12345]CHANCE STURGES[/CHARACTER]

This way, whatever our display mechanism, we can have code that turns this into the proper kind of link for the system. Our data might be displayed in many different ways: iPhone and iPad native views, Android native views, HTML views in either platform, HTML views on websites, etc. So if we’re going to do this, it’s in our interest to keep the data as clean as possible. WordPress already adds certain mark-up to your posts if you use the WYSIWYG editor. But we’ll live with those for now. And in fact, maybe that alone will determine the format of our link structure. We certainly do not want to write another rich-text WYSIWYG editor for WordPress.

I did my due diligence on this one and went plugin shopping again. I found several that do this, but none really to my satisfaction. So I will wind up writing something of my own. I’ve been considering one that combs your content based on the posts related and automatically makes links. But I’m not sure yet if we’re going to want this to be automated or manual.¬† So we’ll table this for a bit.

Delivering Content

This is where my post on using JSON to serve content from your WordPress install comes in. JSON is a data format. It’s similar to XML in that it’s pretty easy for people to read and it’s structured so that machines can very easily read it. To the naked eye, it looks like this:

{"status":"ok","count":1,"count_total":1,"pages":1,"posts":[{"id":1659,"type":"storylines",
"slug":"hector-and-celia","url":"http:\/\/desperatecomfort.com
\/site\/blog\/storylines\/hector-and-celia\/",
"status":"publish","title":"Hector and Celia","title_plain":"Hector and Celia",
"content":"<p>This is the story of two Puerto Rican kids from Washington Heights who are
abducted by the Shadowmen&#8230;<\/p>",
"excerpt":"This is the story of two Puerto Rican kids from Washington Heights
who are abducted by the Shadowmen&#8230;",
"date":"2010-09-03 10:08:07","modified":"2010-09-08 22:52:09",
"categories":[],"tags":[],
"author":{"id":2,"slug":"mark","name":"mark",
"first_name":"","last_name":"","nickname":"mark",
"url":"http:\/\/","description":""},"comments":[],
"attachments":[],"comment_count":0,"comment_status":"open"}]}

Now, that looks like a lot of goblygook, but you can see that there is some form to it. So using this, we are able to create feeds that our various devices and platforms can consume. For instance, I’ve written an Android framework which consumes this format, and stores it in the local Android database for use in apps on the device. Say, once a day, or when the user starts up the app, I have a service which call our feeds, gets new content, and stores it on the phone. Then the app can determine what to do with it.

This is nothing new. Most mobile content providers use some kind of feed to get their data to phones. NY Times, Huffington Post, etc. no doubt do something similar with either XML or JSON, or some custom format of their own. But again, one major hurtle I see is managing your data in a Transmedia experience. So using an existing tool like WordPress saves you a ton of headache in writing your own.

But as I also said before, I see an opportunity here to do more than deliver blog posts, an opportunity to use this for storytelling.

Add custom fields called “latitude” and “longitude” to a post and that gives your device the information it needs to present something on a Google map, or in Augmented Reality. Like if you had a documentary about something in New York City, you could use these location-based posts to create an Augmented Reality walking tour of actual locations used in the doc.

Add a custom field with a random date and time stored, and this gives us the ability to make our app look randomly “hacked” or “highjacked” by some bad guy in the storyworld.

Adding other custom fields gives you the ability to add metadata to your posts. Not the most elegant solution, but the possibility is there. I am going to try to talk about Metadata in another post on this topic.

Caching

It’ s no secret that plugins can make WordPress slow. The more stuff the application has to do, the slower it will be, and the more traffic you get on your site or feeds, the more load on your server and database, the slower these will be. This leads to problems and can take your site and feeds down. We’re going to combat this with a couple of levels of what’s called caching. In case you’re not familiar, this just means you store a static version of your content on a server so that web browsers hit that instead of your actual server. It makes your site load faster for users, and it saves your butt. There’s almost no successful site that can live without some kind of caching. Interactive things like Facebook are an exception, but I suspect even they do some form of caching along the line. Even a cache that expires every minute can save you thousands of hits on your site if your traffic is high.

Caching Level 1: We are going to employ a CDN (Content Delivery Network), like those offered by Amazon cloud, or Rackspace cloud to store static versions of our JSON. So WordPress will generate the JSON, it will be stored on the CDN, then the mobile apps can grab that static version. For the most part, our WorkPress install is a place to manage data, not to serve data.

Caching Level 2: As I mentioned before, the Android framework I wrote stores our posts, characters, storylines, etc. on each device. Android and iPhones have a small database built in. This means, when the user is interacting with our storyworld, they can be grabbing our data right off their phone, so there is no network lag time. It also means the user can interact with at least some of the content “offline,” where they don’t have a network connection. The feeds to update new storylines, characters, posts, etc. will be called by services behind the scenes.

So, apps on phones will be hitting the server for new data, in our case, maybe several times a day. And they will be getting a cached version of the data from the CDN. So we should be pretty safe to scale this up to as many users as we want. It will get trickier with something like a real time game, but for what we’re starting with, this will serve us nicely.

POSSIBLE MOBILE APP DIAGRAM

POSSIBLE MOBILE APP DIAGRAM

Mobile apps are fine today, but what about tomorrow?

Zak Forsman wrote a popular post some time back about putting together a VOD portal on your own with a few simple tools (WordPress being one of them). This is really a great thing for Indies. But what if we looked forward a bit. What if it’s true that Google TV and (probably) Apple TV will run apps? They are based on the same OSs as the mobile platforms. Now, what if you had an app that lived on a customer’s Google TV, fed by your WordPress install, and granting access to your storyworld right there on their TV? Same principles as the mobile apps use. You can grant access to this app on a subscription basis, say.

Others have tried packaging films up in apps, by just sticking their films into the apps. I find this to be…well, not a good plan. It’s a static thing, and once you watch the movie, it’s just a lump of uselessness sitting on your phone, taking up space.

I’m talking about the app for your film as a portal to the world of the film. Perhaps the Google TV app will allow the user to purchase the entire film, whereas a mobile app will only have access to shorter content. But the point is that that content can be updated on the fly through your WordPress install. It becomes an ever-changing, living thing, with your film being only one aspect to it.

Of course, if they are sitting on the couch, watching their Google TVs, why not just go to a website version of your world? Sure. Maybe. We don’t yet know how integrated browsers will be in these platforms. So far, these companies seem pretty set on pushing us away from the web browser as a primary means of interfacing with the Internet. In addition to that, making this an app allows you to much more specifically design the interface for the device. Make it more conducive to using with a remote, say. And of course, since you will be sitting several feet away on the couch, the interface elements will have to be larger, so you can see them. Seems to me this would be another benefit of the app version over website version.

P.S.

Remember last post when I was talking about the “dictionary” idea. Seems like great minds think alike, huh? Stephen Fry’s new app.

  • Share/Bookmark

Posted in Storytelling The Lost Children tools and services transmedia

Mark Harris is a filmmaker and technologist in New York City. In addition to producing several shorts Mark is currently working on his first feature film, THE LOST CHILDREN. Mark also runs Gowanus Software, a technology consulting firm in Brooklyn, NY focusing on enterprise and mobile solutions.

RELATED
COMMENTS

blog comments powered by Disqus
  • twitter
  • facebook
  • delicious
  • youtube
  • vimeo

Join the WorkBook Project mailing list - enter your email below...

NEW BREED twitter
READ

There are no events to show at this time.

Powered by Lifestream.

Podcast Archive