remixable

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

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.

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

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.

Sorry it’s been a couple of weeks, but editing, client work, and wedding plans have eaten up my life. This is part two of a small series I’m doing on how we’re experimenting with Wordpress as a platform for managing our whole storyworld. In part 1, I talked about data types, or custom post types, as well as the UI for creating those. I went on to discuss some of the fields each post type would have assigned to it, and how they would help the functionality of those fields.

As I said in part 1, this is not a tutorial so much as us sharing our process in real time. So here I’m going to show you a mistake.

Building the Relationships in our Data

We’re going to start here with Data Relationships. There are any number of ways to do this, but in keeping with our goals of leveraging as much existing code as possible, we searched for WordPress plugins we might use. And we came up with Related by Matthias Siegel. This plugin allows you to manually relate posts to the current post you are editing.

Plugins Menu With Plugins Highlighted

When I got Matthias’ plugin, it only had the ability to relate posts to other posts. Obviously, since we are creating all kinds of other content types, this wouldn’t be enough. So I altered the plugin to give it the ability to relate a post of any content type to a post of any other content type. The whole point of this is that if we now have  a content type called “Short Story,” and another called “Short Film,” and both of those have the same character, we can now create a “Character” content type, and relate it to both the short story and the short film. This way, we can later query our data and report by character, say, and see all of the Transmedia elements a character shows up in.

So now, with my altered version of Matthias’ plugin installed, every post you edit of every content type  has this new section:

Related Plugin on Post Edit Page

That’s kind of cool. Nice. Simple. Explicit relationships.

D’Oh!

Okay, so once I got Matthias’ related plugin installed and altered, I made some relationships and was happy. Then I realized something bad. This plugin does not make bi-directional relationships. Meaning, when you relate a post on one edit screen, if you go to the related post’s edit screen, the first post is not related there! Wha??????? But nope, I took a peek under the hood and that is in fact how the data model is set up. Bummer. This renders this plugin useless for my needs. I was just about to set out altering it further, when I discovered another related posts plugin. This one was by someone named “Microkid.”

Microkid Related Plugin

Not only does Microkid’s plugin include bi-directional relationships, but it also handles custom post types out of the box, and has a more attractive interface to boot. When you install it, each post edit page adds this:

Microkid Related Posts

As you can see, the interface is very nice. It breaks up the custom content types and shows you how many of each is related to this post you’re working on now. There is a fancy little AJAX search box that allows you to look up posts by name, so it keeps things clean and organized. Nice little plugin. And once again, saves us the work of having to write it ourselves. And the lesson here is that I should have looked a little harder before I focused on the first one.

One thing to note about this plugin is that it has an options panel. And when you add new custom post types, you have to go to that panel and tell it you want to include them in the relatable types.

Microkid options

This options page also gives you the option of showing related posts automatically on your blog, or turning that off and placing them where you want with a widget. Since we’re not really using this for its intended purpose anyway, we turned it off.

Now that we have relationships among our data, what do we do with them? Good question. Well here’s one example besides THE LOST CHILDREN, where this might come in handy.

Neal Stephenson’s new venture is called “The Mongoliad.” This is a “digital novel.” You sign up for a subscription and get new installments every week. But it will also include other media, as well as user submitted content. They have a wikipedia type thing where users can go contribute to the world. And they say if you write something great, it might even make it into Canon. I like this idea, It’s inherently Transmedia. I think it actually has a decent business model about it too.

I don’t know what their back-end is, but it looks like something common. The “‘pedia” has “tags” just like Wordpress, or typepad, etc. But the system I am developing here would pretty perfectly serve their needs. If you go to the “stories” section, you will see they have things called “Content” and “Illustration.” Those are content types. Relationships can be made and so you can sort of generate your own “wikipedia,” or world dictionary, automatically.

And I like this idea. Whether you’re in a world created by SABI, or one created for Hotwheels, I like the idea of spending hours thumbing through a world’s dictionary, then dipping into a story linked off of a certain character bio, sinking into that story for a while, then coming back up to the “dictionary,” thumbing through some more. Or getting into one story, then finding a link to another interesting character and following that. Like, imagine going through the “Fringe” world, then deciding to go off and watch or read some stories about Walter’s past at Harvard. I kind of dig this. And again…is there a business model there? Just selling subscriptions to the world of the story? Low cost. Levels of access and access from anywhere, because you were smart enough to document your world with an online tool like Wordpress? Again, as indie folks looking for the edge, I think this stuff is worth really thinking about.

Though, as the Romans would say: “nihil sub sole novum.” In Andrea’s post on interactivity, I remembered a “novel” from the 80s, written like a dictionary. And beautiful, moving, and subtle.

What I also like about this “dictionary” road, is that it doesn’t have to reduce the quality of any one piece. If a video game is not right for your world, then for God’s sake, don’t make a video game. But I see nothing wrong with cross-linking between, say HEART OF NOW, and a short film about some other part of Amber’s life made by another SABI director. And I think that can be done without violating the integrity of that world.