By Ben Moskowitz
This is an emerging field. But for filmmakers hacking on Web-based stories, it basically boils down to this:
You have to commit to the fact the “thing” you are making is not a linear, unchanging video with a discrete runtime (even if your users will experience it as such). For all intents and purposes, you’re making a Web app.
And you wouldn’t go about making a Web app the same way that you make a traditional film. You have to start in pre-production with the “thing” in mind; conduct and store your research the right way; and have the right mental model.
You can’t tack on “connectedness” after you’ve produced something completely disconnected. Here are some specific tips to help you, starting in pre-production.
#1: Always stay in service of story
Your number one job is to tell a story. Never forget!
Technology can serve as inspiration, but never substitute for story. Technical possibilities can certainly serve as inspiration. The Pixar artists on Up were inspired by the challenges of rendering thousands of balloons with rainbows and refraction techniques using computer graphics. But the movie succeeded because those technologies helped captivate viewer imaginations and better tell the story. And, frankly, all the beautiful rainbows in the world won’t make up for the lack of a strong story.
Credit: Pixar
Your creative process should start with a strong, compelling story, with characters who have real motivations (or motivating circumstances).
Start from the story, think about how you’d want your user to experience that story. Then—and only then!—you should start to figure out the specific technology steps you need to take to make your vision become reality.
#2: To thrive on the Web, adopt “systems thinking”
After telling a compelling story, your second job is to create a technical framework and system through which to tell the story.
This will be a different process for each story. But there are two concepts that almost everyone will need to wrap their head around: information architecture and procedural storytelling.
Information architecture refers to the way your app is structured. If you were making a traditional documentary, you’d need a basic information architecture to keep track of your notes, research, and footage. But the finished film requires no such architecture, since it’s a flat 90-minute film.
A connected documentary is a Web app, so it needs an information architecture. If, for example, your connected documentary brings images into the page: you need to have a mental model of where those images are stored, and how they’re retrieved.
Procedural storytelling refers to a way of designing stories so they’re different every time. Procedural storytellers write the rules once and trust a computer to actually execute the story. Chris Milk’s The Wilderness Downtown is a procedural story, in that it changes depending on the viewer’s address. Modern videogames are procedural stories, in that they respond to player actions. Madlibs are a kind of procedural story. Here’s an example:
[User] watched [favorite documentary] and really liked it.
This is a horrible story, because it a very weak (i.e., nonexistent!) dramatic arc. But bear with me.
Let’s say that in order to tell this story, you require your user to authenticate to the Facebook social graph. In so doing, you can get information about the user’s favorite movies, and fill in the variables in your procedural story. Depending on who watches, your story might be told like this:
[Amanda] watched [Supersize Me] and really liked it.
or like this:
[Ben] watched [Manufactured Landscapes] and really liked it.
or like this:
[Chris] watched [#null#] and really liked it. <——(careful, procedural stories can backfire! Design them to fail gracefully.)
Or take another story:
Today, [today's date], it is [local temperature] in [user's city]
You could fill in the variables in this procedural story by getting the date from a Web server, using the browser’s geolocation API to get a zipcode, and looking up the weather by that zipcode. You can achieve this in a few lines of Javascript, and fill in the variables for a result like:
Today, [February 14], it is [65°] in [New York City].
Conceptually, that’s pretty neat. But what makes it powerful in a connected documentary is the way it supports your story. What if you incorporated the previous procedural story into the title card for a documentary about the worst winter in New York City’s history? It might read:
Today, [February 14], it is [65°] in [New York City]. But in the Great Winter of 1936, the temperature fell to lows of -6 degrees—a cold that froze the very soul!
This is a pretty big shift in thinking. Please don’t be that cheesy. But do consider how you can use the medium of the Web to tell more engaging stories.
In some cases, your Web documentary may never be finished. In others, it will be finished, but will always be experienced differently. That’s up to you. The good news is, since it lives on the Web, you can evolve it whenever you want. Update your code and deploy. Which brings us to #3…
Filmmakers are in the habit of polishing their work until it’s meticulously crafted and extremely shiny.
Don’t do that. You’re making software. And in the software world, we like to say that you should “always be shipping.” Always have a version of your project available for testing. Give the evolving versions of your project point numbers if you want (0.1, 0.2, 0.3). But release at least every week. Release every day if you can.
This is a major difference between developers and filmmakers. Filmmakers are afraid of showing things that are half done. Filmmakers do a lot of iteration, but it usually happens in private—they continue to tighten your edit to test the flow, tempo, and rhythm of a certain cut. But to adapt to the Web, filmmakers have to be willing to do this kind of iteration in public.
You’re making software. And in the software world, we like to say “if you’re not embarrassed when you ship your first version, you waited too long.”
It takes one day to make something cool. Two days to make something interesting. A week to make something great, and a year to make something that will change the world. So take it one step at a time. Be iterative. Show your work, and your process in real-time. Because “usage is oxygen for ideas.” See, we have a lot of sayings.
#4: Be an auteur, and work backwards from your user experience
In film theory, an auteur is the person whose pure creative vision shapes the film. Though many people may work on a film, the auteur’s voice is distinct enough to shine through through the collective process and to a final cut.
A great example of auteurism in action is Chris Milk, who directed the Google Creative Lab in the creation of The Wilderness Downtown. He created this animatic to cull out the vision that was living in his head. It helped the people on the production team to understand and build his vision.
Credit: Chris Milk
You should work similarly. Start with a story — not a set of themes, but an actual story about actual people and their motivations. Then have a vision for how you can tell that story more effectively using the Web. Then, and only then, figure out the specific technologies you will use to implement this vision. Rinse and repeat.
Credit: Ben Moskowitz
Connected docs need to be imagined for the Web. But you need to imagine them the right way: story first.
#5: Don’t reinvent the wheel. Get help
If you can at all avoid it, don’t waste your time writing code. The beauty of open source is that often, someone has already solved your problem.
It’s much smarter to spend time repurposing and mashing together code, rather than starting from scratch.
Here’s some useful resources, especially if you end up building your doc with HTML5 (which I really recommended):
Popcorn.js: The glue for any HTML5-based connected doc.
Badass JS: A gallery of badass, open source JavaScript to incorporate.
MDN: Developer reference for HTML5, CSS3, and other open Web tech.
Ben Moskowitz works for Mozilla on projects like Popcorn, the Knight-Mozilla fellowships program, Universal Subtitles, and more. He also does a bunch of cool stuff on the side. You can contact him about Mozilla's media-related projects and in general to discuss, build, and test ideas. http://benmoskowitz.com. Follow him on Twitter @benrito
The Future of Film blog is a place where leading filmmakers and experts within the film industry share their thoughts on film, technology and the future of media.