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?
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:
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.
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":"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…<\/p>",
"excerpt":"This is the story of two Puerto Rican kids from Washington Heights
who are abducted by the Shadowmen…",
"date":"2010-09-03 10:08:07","modified":"2010-09-08 22:52:09",
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.
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.
Remember last post when I was talking about the “dictionary” idea. Seems like great minds think alike, huh? Stephen Fry’s new app.
Posted in Storytelling The Lost Children tools and services transmedia
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.
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.
Continued in Part 3.
Posted in Storytelling The Lost Children tools and services transmedia
So I’ve been waiting for WordPress 3 to come out before really diving into this, because in WP 3 they introduce easy use of custom content types. Up to this point, you were allowed to create either a post or a page. Now you can create any type you want. These types are still just posts really, but it allows for something I’ve been working on for some time.
Mobile apps for films and storytelling have been a hot topic for a while. There have been good ideas and bad ideas. But the one thing I think any mobile content app should have is the ability to update the content on the fly. This is where WordPress comes in. It’s a robust and widely used CMS option, which saves us the time and hassle of writing our own CMS. It has a large support base, active development and just about every feature you could ever ask for in a tool like this.
So I had been thinking for some time about how to use WordPress to power mobile app content. One problem was that I did not want the mobile content to show up on the site. So the custom content types came in exceptionally handy for just this. I was able to create a type called “mobilecontent” and thus guarantee that I could direct that content only to my mobile devices and not to the site itself.
What’s beautiful about this is now I have one place to manage my story-world, my BTS, my articles, my Transmedia data, etc. All in WordPress.
But how do you get it to the mobile apps? One way to do this would be for the app to read an rss feed off of the site. RSS is XML. The problem I had with this was that the standard RSS feeds did not give me as much data as I wanted about posts. So I first set out to write my own plugin to create the feeds I wanted. Then I got to thinking about it a little more and decided I liked JSON REST services better anyway. They are simpler to deal with and both Objective-C and Java have super-simple methods of consuming them and turning them into objects for use in your app. So as always, before I started in on my own JSON plugin, I searched existing WordPress plugins. And sure enough, some dude made one that suited my needs (nearly) perfectly. So I installed that and wrote a little Android code to consume it. But the one thing this plugin lacked was access to custom content types. He had written it before these were available. So I added this to the plugin myself. I will submit it back to him to see if he wants to keep my code in there.
But what this got me was exactly what I needed to serve up WordPress content to my mobile apps.
Of course, you could have the standard mobile app that looks like a mobile version of your website. Or you could launch a whole mobile story, fed through WordPress, and served up to mobile devices. Adding custom fields to WordPress posts for lat/long means you can now tag a post for geolocation. Then your app can respond accordingly. Now, WordPress can be used to create a scavenger hunt. Or a location based ARG delivered to mobile devices. All with this off the shelf, FREE CMS system.
There is still a lot of work to do on this and a lot more detail to add. But I thought I would kick it off with these initial thoughts to plant the seeds and see if anything catches for people. I am moving forward on this now, probably working out a framework in Android first, because it’s so much more fun to code than Obj-C. I will be using this on the LOST CHILDREN apps, and would be happy to have some more guinea pigs as well. If you have an app in the works, and looking for some way to update the content regularly, hit me up.
Posted in Storytelling creative collaboration tools and services transmedia
Recently, I’ve been keeping a close eye on tools for audience building. Several months ago I was very excited about a project, being funding through Kickstarter, called Openindie – if you’re not following Kieran Masterton on twitter already, then you should be. The site is still in beta, and what is exciting about Openindie is that it’s still finding and building it’s community: it is open to ideas and able to adapt quickly to what the filmmaking community needs.
A few nights ago I was in night-owl mode, with a moleskine and pen in hand, as I was pouring over some of the most-requested films on Openindie. Among them: Heart of Now, We Live in Public, and What’s Up Lovely. I was sketching out site designs that made use of an integrated Openindie request button. Researching which of these top-requested films on Openindie were heavily using Openindie on their film’s main site, the answer: none of them.
Which, I found very strange. But I’ll get to that below.
What I mostly wanted to talk about is: better approaches for audience building. Either for the purpose of mapping out which zipcodes have enough support + demand to schedule screening events, or for other purposes. A question I kept coming back to was “is it necessary for the audience to actually sign-up?”. Openindie does make the process quick and painless by offering Twitter Oauth and Facebook Connect – but does this benefit Openindie more than it does the film?
For example: I’ve been very interested in using twitter as the main engine behind building audience interest – asking that someone interested in FToM simply twitter the hashtag #requestFToM (for those who do not have a twitter account already, they could simply text #requestFToM to 40404). If Openindie could make use of that kind of information, I think it would be a far more powerful tool then having people navigate to a specific URL, sign-up, and then click on the request button. Any #hashtag attributed with GEO information could be mapped immediately, and any #hashtag without could be @replied back to requesting a zipcode. There is no sign-up form, there is no Oauth or Connect needed. Anyone with a cell phone that walks past your flyer on the street could immediately voice their interest.
What I would most love to see from a site like Openindie is a request tool that is 100% flexible on the filmmaker’s end. By that I mean, the request button does not change, you can grab a short piece of code and embed it anywhere you like. But from within Openindie the tool can be scaled out and adjusted in reaction to what is working best and what isn’t. As a filmmaker, what would I like to happen when the request button is clicked?
I would like the visitor to never leave the film’s site. Or if they do leave, much like Paypal, they are returned right back to where they started after the request is finished.
I would like control over what the visitor sees. Have I turned on the options for both twitter and facebook? Or am I just asking them to provide an email? Am I offering all 3 or 4 or 5 options? Does it take them straight to a pre-written twitter with the #hashtag and other important info? These should be settings that can be controlled from the Openindie dashboard without having to replace any embed script.
Once a visitor clicks the request button, that same button then reads: promote. And, of course, have 100% control from within Openindie as to what exactly happens when that is clicked. Does it take the visitor to Openindie’s list of sharing options? Or point them to a site of sharing tools still under the film’s URL? Perhaps I’m running a campaign that involves real-world action like flyers or stickers in public places and want them taken to a page walking them through that idea.
Only a tool that is 100% flexible is going to be a perfect fit for each different filmmaker.
I’m really excited about where Openindie is heading – and I’ve already pestered Kieran about some of these ideas and he seems very open to them, even more so he seems excited about talking to filmmakers and getting feedback on what tools are going to take independent film the furthest.
Posted in audience distribution promotion tools and services
WHY DO THIS IN THE FIRST PLACE?
About a year ago, there was a lot of talk about the merging of broadband internet and the televisions in our living rooms. That has since been subplanted by a shift in focus toward the creative process and making better films. However, when Google TV was announced not long ago for a Fall release, I found myself revisiting the importance of discovery and distribution for a 24 hour period in which I built my own video on demand portal. If Google TV is able to populate amongst our TVs and other home theater devices as quickly as Netflix Watch Instantly did, we could be having some interesting conversations a year from now. In anticipation, I began digging into what it would cost in time and money to launch such a portal online for the films of Sabi Pictures and the films we’ve curated via the CINEFIST Screening Series. We’re calling it CINEFIST TV.
First I looked into services offered by Youreeka, Maxcast and others – disappointed at the cost, how little of the purchase price would go into our own pocket and the fact that the customers had to start accounts with these other companies. So then I began to look into doing what they do, but on our own site. I wanted to mimic the Netflix Watch Instantly experience — streaming video, a simple interface, a way to pay for the content with the option to make it free, and I wanted it cheap.
Now, I’m sure there are a few of you that are ahead of the curve on this one. This might not be for you as these are the discoveries of someone who has never done this before, but maybe you could offer some insight that would improve it a bit. That being said, this article assumes you know how to compress videos for the web and that you’ve got a handle on building web sites, registering domain names and setting up a hosting service. What follows is just the first incarnation of our VOD portal. It will evolve.
THE FOUNDATION AND PORTAL INTERFACE
First I needed a platform that would work in any browser. I’ve long been using Wordpress for all our sites and have become a great admirer of the premium video-based themes designed by Jason Schuller at Press75.com. For purposes of this VOD portal, I chose the appropriately named “On Demand” theme. They have a number of themes that would work equally well.
After securing my new .tv domain name, I uploaded all the Wordpress 3.0 files to my server and the theme files were uploaded to its theme folder. I created a mysql database with my hosting service and entered the appropriate information into my Wordpress config file before uploading that. Then, by going to my url for my new site, I followed the installation procedure for Wordpress and within seconds the site, devoid of content, was up and running.
If you are familiar with php and css stylesheets, the Press75 themes are easy to customize, and this theme in particular has a number of customs settings one can set in your Wordpress admin control panel.
A STREAMING VIDEO SERVER IN THE CLOUDS
I needed a cost-conscious streaming server. Most charge so much that selling a 99¢ stream would be a losing proposition. I turned to Amazon Web Service’s CloudFront service and started an account. Their pricing is much more manageable at 15¢ per GB. Considering a feature-length stream is in the neighborhood of 1 to 2 GB, this was a no brainer.
So I first set up an AWS Simple Storage Service (S3) account where the media would live. Using my existing Amazon account and a credit card, I was receiving an email containing a link to my S3 account details within seconds. When you follow that link, the first thing you want to attend to are your two password keys — the Access Key and the Secret Key.
To manage this new account’s files and folder and various settings, I downloaded S3Fox Organizer plugin for Firefox as its really the best thing going for managing your files on an Amazon S3 account. With this I was able to upload all my media files (trailers, previews, shorts and features) and make them public and read-only. Here’s how:
Click on button that reads “Manage Accounts” in the upper left corner of the S3Fox interface. The window shown above will prompt you for an account name and your two access keys.
Now, you’ll need to create a “bucket” (aka a folder) in S3 where you’ll upload your videos. Click the blue folder button at the upper-right side of the screen and enter a name for it. I chose to use the domain name for the site it would serve videos to.
When you’re ready, this is where you’ll upload all your video files to. Each file will have to have its permissions set to be read-only for public viewing by right-clicking on the file, selecting “Edit ACL” from the menu, and changing “Read” + “Everyone” from a red X to a green checkmark. You can’t do this as a batch as far as I can figure so its a long process if you have a lot of videos.
Next you’ll have to set-up a “Distribution” in Cloudfront. Go to the AWS Management Console and add the EC2 and Cloudfront services to your account, if you haven’t already. Then go back to the main console and click the tab for Cloudfront. Click the button for “Create Distribution” and select the “bucket” you made earlier. Then set the delivery method to “Streaming”.
Now you’re looking at a list of your Cloudfront Distributions. Make note of the assigned domain name that looks something like a1b2c3d4e5f6g7.cloudfront.net. You will take that domain name and build the url to your streaming media as follows:
The /cfx/st/ path is required. While “your_video_file.mp4″ is the video you uploaded (or will upload) to your bucket.
VIDEO PLAYER AND ADAPTIVE DYNAMIC STREAMING
Dynamic Streaming is where the video player monitors the user’s broadband capabilities and selects one of several videos files to play that are identical in duration and content but differ in size and datarate. The player is capable of switching on-the-fly seamlessly.
As tedious as it may be, you’ll want to encode multiple versions of each video at different datarates. I chose to do three at 500kb/s, 900kb/s and 1800kb/s to support viewers with a variety of bandwidths. The player is given a list of corresponding videos in the form of an XML file and it plays what the user’s system can handle without stuttering and stopping. It’s not always flawless, but it’s pretty remarkable how well it works.
Here’s how I set mine up:
First download the free JW Player and upload the “mediaplayer” folder and all its content to your web site’s FTP. I placed mine in the directory labelled “wp-content” where other items like Wordpress themes and plugins are kept. Next, in your Wordpress admin control panel, go to the settings for the “Simple Video Embedder” (a plugin which comes with the Press75 themes) and enter the location of the JW Player files as: http://yourdomain.com/wp-content/mediaplayer/
Next open a text editor and create an XML file by saving an empty text document with a .xml extension. You can download an example xml file here. Be sure to fill in the names of your video files and your unique cloudfront domain name where indicated in the code. You’ll need to make on of these XML files for each video and once you’ve filled it out with your own info, upload it to your web site’s directory.
Next, use this code to embed the JW Player with instructions to call for the XML playlist. If you’re using the On Demand theme from Press75, create a new post and scroll all the way down to “Post Video Options”. This is where your embed code goes.
MAKE ‘EM PAY!!!
Finally, unless you’re happy giving all your films away for free, you’re wondering how do I make certain videos viewable only after a customer has paid to see it? This is the area I’m still experimenting with and I’d love to hear some ideas in the comments below. For now, I’m using a Wordpress plugin called S2 Member that allows you to lock specified posts and pages as “pay-only” content using Paypal to process the transactions. This plugin was desgined for bloggers who wanted to have premium content on their sites, and since each video we host is essentially its own blog post, this works well enough for now. The instructions it comes with make it easy to set-up so I’m not going to repeat them here, but quickly i will note that you have the option to be post/page specific or to offer a subscription that opens up all the content for one price.
Still, I’d like to have the pay system integrated into the player itself, so it can be embedded on other sites as well. The JW Player has an add-on that allows for Paypal donations to be made, but that’s not quite what we need. So these are the primary areas we’re working on before the official launch in the Fall to coincide with GoogleTV. In addition, we need to replace the video player with an HTML5 compatible one so the videos can be viewed on Apple devices too. The challenge being that no HTML5 players do true fullscreen which kind of kills the home viewing experience when you can see the browser. And its the home viewing experience we’re building this for.
So that, believe it or not, should do it. You can poke around on the site for the JW Player to learn how to use different skins and add-ons too. It was important for me to share how this is done, how easy it is, and how little it costs so you can avoid being taken advantage of. There’s little need to give away 50% or more of your potential online VOD revenue just to have it available in this manner. Anyone with $100 and a couple hours can do it.
Posted in tools and services video on demand