Building Workflows for Authoring Digital Fiction

When Haig Armen and I set about building a technical infrastructure for our workshop (and for digital storytelling generally), we scoped out a presentation layer (focusing the reader’s experience) and an authoring layer (for the writer’s experience). We’ve happily been building upon Caleb Troughton’s excellent Deck.js framework, which provides an open, layered, web-native toolkit for building sequential stories. But the authoring environment has been a different story.

We thought that a good candidate for an authoring and content-management system would be the fabulously flexible Tiddlywiki, a “personal wiki” toolkit written entirely as a browser-based Javascript application, and very, very malleable. Malleable, yes, but all designs carry their own constraints, and over the past few weeks I’ve learned that the places we needed to go with this project don’t mesh well with Tiddlywiki’s assumptions. To put it briefly, Tiddlywiki attempts to provide an abstracted layer away from the usual building blocks of the web (HTML, CSS, Javascript), where what we wanted to do was to work with them directly. So I spent a couple of weeks learning where my assumptions conflicted with the assumptions built in to Tiddlywiki. Eventually, I got to a point where – despite my admiration for the way Tiddlywiki has been designed, and the flexibility it affords – I needed to move on.

I moved on – or rather back – to my document-production standby, Pandoc, a “swiss-army knife” for document conversion. Pandoc can convert just about any structured format into any other structured format. In our case, I need it to start with a simply formatted story, in plain text, with some annotations marking narrative structures, media, and events, and build that into the HTML+Javascript structures that Deck.js brings to life.

To do so, I built a custom HTML template that defines all the boilerplate CSS and Javascript needed by Deck.js (and its extensions). Next, I crafted some simple structural cues that allow sections to be defined, background media to be called, and on-screen formatting to be set up. The result is a very simple text file that an author creates, and a one-step build process to turn it into a rich media environment. That took only about an hour to craft, using Pandoc’s rich toolkit. What a difference compared with last week’s hacking!

My next steps are:

  1. to further tweak the Pandoc process so that writers can write less code (or at least write media directions with a minumum of formal syntax); and
  2. to embed the authoring and build process in a wiki or other web-based CMS so that we can have a collaborative writing experience rather than people working in isolation.

More to come! Stay tuned…