Sharing the process of developing the Eagleman iPad app

Over the summer Canongate was approached by author David Eagleman with a proposal to adapt a talk he had given to the Long Now Foundation entitled Six Easy Ways to Avert the Collapse of Civilisation and turn it into an iPad app. After several months of toil the app, now entitled Why the Net Matters: How the Internet will Save Civilisation, is available today (December 9th 2010) worldwide on the appstore.

Dan Franklin, Digital Editor at Canongate, recognises that this project has thrown up lots of interesting questions about how publishers can work in the digital age and where the boundaries between an author, editor and developer lie. So he opened up a Google Doc with Jonathan Skuse and Berbank Green of PopLeaf – the developers on the project— to do a post-mortem on the process.

In this frank and honest dialogue between publisher and developer, exclusive to The Literary Platform, we get a refreshingly transparent account of the production process.

Dan Franklin: Can you give the readers a quick introduction to what you were doing with Jumped Up Games before you started the PopLeaf side of your business, i.e. before  I came along and ruined everything?

Jonathan Skuse: I started doing some app work through WingedChariot, making children’s book-apps sometime around the middle of last year, while we were doing that we were working on a JUG-designed game for 6 months which is, as yet, unfinished. We then moved on to working on a big project for another publisher which is still in the works, but has some big windows in the schedule. You popped up as we moved into one of these, so it seemed like fate. We spun PopLeaf off as a separate company towards the end of development of this app because it seemed odd to be a games company that makes things that clearly aren’t games. We’re doing more and more work with book publishers, so it keeps confusion to the minimum. Both companies are essentially still the same two people – PopLeaf is just an alternative “label” if you will.

DF: But in short you’d describe your backgrounds as being games developers?  How did you know Paul Rhodes (digital main man at Walker and Orb Entertainment) who first told me about you?

Berbank Green: Yes, Jon and I have both got 10 years in the games industry working with top publishers and developers. I’d just finished Bonsai Barber at Zoonami working with Martin Hollis (who you’ll know if you’re in the games biz) and before that a Final Fantasy game, Need For Speed and Sims 2 for mobile.

JS: I met Paul when we were meeting various publishers as part of the usual pitching process. We’ve met a whole bunch of people that way since we were in there early with picturebooks on the iPhone. But, yes, we’re definitely still game developers, albeit maybe not the most conventional. Before JUG I was working at Jagex on RuneScape (one of the biggest massively multiplayer games in the world).

DF: Earlier this summer I felt that Canongate had to take on a project that stepped away from the whole straight-text electronic reproduction thing and move into a more interactive, game-y space. Then David Eagleman approached us with this idea for an iPad-only project and had the basic navigation sketched out. Instinctively I felt we had to get it out before Christmas, preferably late November. What interested you in the Eagleman project?

BG: David had some good ideas in his book SUM and we were both interested in working on an unusual, ambitious and creative project. The spec was open enough to allow us to get our design teeth into it and it provided a perfect way to show off our developing technology.

JS:  Basically the fact it was ambitious and not just a “me too” product. Also, in a perverse way, the aggressively positioned release window made it quite attractive, simply because we only had a small window and didn’t have time to get caught up in endless discussions, as has happened with some other publishers. There weren’t meetings with Creative Director 1 then Creative Director 2 and then Digital Director etc. It was just you. We had a spec and we HAD to run with it. Truly agile development.

DF: You guys did a pre-production week on the project. This will be alien to a lot of people in publishing— this going away for a week or two so could you brainstorm before a proper contracted term of work —why is it important?

JS:  Well, from my POV there are maybe 3 main things that needed to be tackled in that week.

a) Designing a working piece of software: while the app was “designed” by David up to a point, there were a whole load of aspects that did not quite work when you considered how a user actually interacts with an iPad. So, in effect we took the essence of what he’d planned and reworked it so that it would be fun to use. We also introduced a bunch of new features, some of which worked and some of which didn’t make it into the final product (such as Interactive Elements).

b) Logistics: So for instance we needed to have a pretty decent renderer built to display 3D models—we also knew that we’d have our work cut out to do all the editorial, core app programming work and get a good renderer built in the time we had available (not to mention needing to find an artist to build the actual models). We crunched the numbers and worked out that we’d need to get external help so we drafted in a graphics coder friend from the games industry to take care of the 3D side of things. Multiply that sort of planning over all the various facets of the project and there’s a lot to get your head around.

c) Editorial: working out how the structure of the text worked in context and how the software could support/embody David’s arguments.

At the end of that week that we had a really clear idea how we were going to tackle the project and were confident we could deliver in time. This is good for all involved —David knew what could/couldn’t be done, Canongate knew we were going to be able to deliver, and we knew that we could get everything done in time and within budget.

BG: There were some thoughts we had about the text itself that we thought could be altered to fit a slightly stronger content-driven experience. So we spent quite a while restructuring it to present it in different ways convivial to the underlying arguments. This served to test the creative landscape of the project, the flexibility of the team as well as open the discussion out to explore the assumptions and ideas behind his argument. We were quite aggressive with our proposed changes and it was a welcome relief that David and Dan were both open to these changes, although ultimately, only a fraction of this was used.

The whole approach we had to this was: how do we make the technology express the ideas of the text as well as we can? Once that approach was established we needed to know what tech we were going to use and how to project manage that to get it done on time and at high quality. The more you know at the beginning of a project, the more organised and methodical you can be with your resources.

Also, because this is not a straight ‘book’, it requires an extensive amount of thought as to how the text is best navigated and experienced. Jon and I spend a lot of time thinking through how best to present the text to begin with and then Jon largely took over that aspect of it as I worked with Dan on the editing feedback as well as sorting out the planning and asset management.

Another thing that fell out of this process was the Milestones (work targets and deadlines) and a clear division of labour. Although the app is driven by David’s text and his original design doc, we deviated from that somewhat to make it more fun to use.

DF: After that initial meeting and presenting your ideas (where it became crystal clear that the right thing was to present this argument as much like a network as we could within an app framework) we introduced David into the conversation and he had clear ideas himself about what he wanted. How did you find working with an author and how has it differed from your previous experiences? Or expressed differently, where do the lines between author/editor/developer lie – I always felt you edited the book as much as me and you said during the process that a games publisher’s word is law whereas in books we have to keep an author happy – it’s his work.

BG: David was a very high-energy, charismatic person to work with and had lots of ideas. He was also quite wedded to his original design doc and it took a few conversations with him to explain why we needed to make the changes we proposed. Some of them he agreed on (mostly navigation and usability issues) and some of them he didn’t (like changes to the structure and content of the argument). Ultimately it is his decision as the author to do that, but we fought our corner in terms of usability. The editing was very interesting, as you say Dan, that was something we did together and I found that incredibly useful. Having two minds collaboratively attack the text from two different positions meant we got a lot of editorial feedback done quickly and that we covered lots of ground, I’d be more than happy to work like that in future, and I’ll also be more realistic about how much of that an author can take on board in such a short time scale.

We had to keep you both happy, but not only that, we had to be sure that the creative and technical portion of our work met our standards. Fortunately David and you often agreed with the changes we implemented and we negotiated reasonable compromises where there was disagreement. In this way it was similar to some game development companies I’ve worked for. Ultimately, each working relationship is different and a big part of being an agile developer (games, apps or otherwise) is learning how to adapt to your client and their needs without losing sight of the goals and needs of your own company. In that respect I think we all did well out of this project.

JS: Working with David often a pleasure, but other times a bit of a roller coaster experience. He was willing to listen to arguments as to why things needed to be one way or another when explained, which is better than can be said of many product visionaries. He also understood that time was against us and that things needed to get changed or even dropped all the time in the process of development. The downside was that his ludicrously busy schedule made it very difficult to get things done when we needed them.

It was odd to have two publisher-type figures on seemingly equal footing that we needed to keep happy. In games you’d be answerable to an in-house producer, and they’d in turn be answerable to the representative from the publisher.  We had to answer to both of you. Yammer helped, and Google Docs, as did weekly calls. Without those we’d have really struggled to remain agile AND keep both our clients happy.

DF: Let’s talk about that role division more specifically and in laymen’s terms about what would happen in an average week, say when David delivered a draft of chapter 1 with suggested images: what work would then go on at your end? I found Yammer a fascinating node for the project and editing on Google Docs too. Both writing and editing are actually traditionally solitary processes and I often thought how what we were doing probably pointed towards a new way of going about ‘book’ creation, on top of the terminology we employed (text/image ‘chunks’) and structural innovations.

JS:  My life was a little less varied than Berbank’s. Coding. Sleep. Repeat. Yammer though, I think, was fantastic. For those not in the know, Yammer is a closed social network, like Facebook etc. but private, which allows teams to communicate, post attachments, share links, images etc. in effect it kept the channels of communication open all the time without the usual email overload.

I think one of the best things I did was get a system built early on whereby all the app’s content could be edited without it sucking up much of my time at all. This meant that Berbank, and then later David and Dan could edit the contents of the app without doing any coding. The format in question isn’t an epub file or anything, but rather a much more simple XML format. All the images, websites, models, text… everything could be edited. What we ended up doing was sharing these content files on DropBox (file sharing system) where anyone could change them at any time, and because DropBox keeps a file history, we can always see who has changed what and when.

From a text design angle, well I must admit to not being 100% happy with the outcome since we lack text size and font settings. HOWEVER, I am delighted to have soft hyphenation in there, which was widely reported as a failing of iBooks. I did the graphic design for the app as well as the most of the coding, which was a boon in terms of reducing the usual disconnect between the designer and tech person, however I’m keenly aware I’m not an expert when it comes to typography so I worried and worried – this resulted in many late nights trawling the internet for articles about screen readability and so on.

DF: Your reasoning behind using swiping and not too much webpage-style scrolling was interesting.

JS: Yes, the original design called for a continually scrolling vertical page, which would have meant that the entire content of the app would be explorable simply by scrolling down and down and down. Having done a little research into this and then observing my own processes when reading was that it’s very easy to fall into a “skimming” form of reading when confronted with a large block of vertically scrolling text. So, for example, it’s very easy to lose track of the line you are currently reading if the text is moving up in a non-discrete fashion since there is little in the way of “waypoints”.

Furthermore, I believe it could reduce the perceived value of the app if the entire thing is one long scrolling block of text. It becomes, in effect, a web page. This is not to mention that the user interface “language” that has been established on the iPad dictates that swiping moves you forward and back in book-like content.

But then the problem was that we had these “chunks” of text, each which was illustrated with an image which varied significantly in length, which meant that it was impossible to ensure that all the text fitted on the screen in both portrait and landscape orientations (it’s really important that the user should be able to read the app in the orientation that suits them). This left us with a very uncomfortable choice: either we make the app fully paginated, whereby a “chunk” could be divided up over a number of screens (keeping the same illustration) or we introduce a small amount of vertical scrolling AND horizontal page “turning”.

My gut instinct was that first option was the only way to go, despite the fact it could mean “pages” of only one line of text, but having tested it (as is often the case) it turned out that the second option produced a much preferable experience. I think this has a lot to do with the fact that the body of text in each “chunk” is sufficiently small that the reader doesn’t get lost when scrolling (since there is less than a full page of possible movement) – it would absolutely not work for a novel.

BG: The process, at its most basic was: David provides a word doc via Yammer of a chapter; Dan and I would then spend 4-8 hours editing it on Google Docs, at the same time sometimes, and then we’d feed those changes into the XML files. Early on in the project, Jon and I spent a lot of time agonising over the navigation of the text, how to separate it out, how to make the transitions as smooth as possible. Jon found an article on the importance of hyphenation and that helped enormously.

Once we’d figured out how to separate the text into chunks (a term we all agreed upon over a conference call, meaning a graphical image + a few hundred words of text) we had to find a way to move between them. The obvious method would be to ‘turn the page’ where a whole page of content rolls onto the screen, but this is quite visually jarring on such a large screen. Simply fading the whole page out and the next one in provided no sense of moving through the text. So we hit on the idea of fading out and in the graphical components and sliding in the text.

After a few broad design meetings that established the basics, we divided work with Jon as the principle programmer and graphic artist (while still providing considerable design input) and I handled the admin, resources and editing (providing less design input, but still discussing various design ideas). It was planned that I would do some IEs (Interactive Elements, referred to earlier) too, but the final text didn’t support the ideas we had in mind (although we did make two of them anyway).

During periods where we were waiting for text we refocused on getting the app as stable and as easy to navigate as possible. Dan and I set up a spreadsheet that tracked all changes to content other than text (video, 3D assets, pictures) and we’d continuously track this as an indicator of content completion. Dan and I also worked together to organise the assets themselves using DropBox which I then added to the source control system we were using (called Subversion). Jon and I then both did extensive testing in the simulator and on device to make sure it all worked and fitted in. We had a number of images we went back and forth on (with David also advising) and this was all aided by the collaborative systems we put in place early in the project.

Although Jon and I had worked on collaborative projects before, this was a first in terms of how much we relied on these free, collaborative systems for structure, organisation and communication.

As you say Dan, writing is usually a very solitary process, and this was very different. As far as being a new way for ‘book’ creation, that’s an excellent point. For projects that have a certain factual/scientific basis, this sort of collaborative real-time writing could be extremely effective with the right team. Where it gets interesting for me is how to credit ideas raised in such a text. There are several times during our editing process where you said something which made me think of something completely different, which I’m sure I wouldn’t have done had you not written those words, in that way, at that moment. For instance, when we brainstormed a whole host of alternative collaborative ecological ideas for saving energy.

DF: I want to ask you a controversial question from my perspective. I felt that my role in the project was very much content editor, ‘project manager’ and a necessary cushion between you guys and David sometimes. I also brought you guys in and coordinated things from a publishing perspective but here’s the question: do you think a book publisher (in the traditional sense) is actually necessary in all this?

BG: That’s a good question. That would very much depend on the project and the intended outcome. In this case it was very important to have a publisher on board. As you say you were effectively a cushion between us and David and I think it was a comfort to David to have you represent him from a development perspective as well as a weight off of our mind for you to be there to talk David through some of our decisions that may not have gone down so well in the first instance. We should mention, David was in America for the duration of this project and we are based in England. More importantly we’d have struggled to suggest the changes we put forward without the weight of your editing experience and credentials.

DF: But looking back, and even though it was interesting and rewarding building the app as the script was being written, we’d definitely do this with a finished text next time, right?!

BG: Yes, we were fairly adamant that we wanted final copy very early on to get this project to a very high standard, and we are making it very clear to publishers we work with now the importance of getting content finalised before beginning a project like this. With content-driven tech, you can’t afford to spend time fire-fighting when the content changes under your feet and as I’ve mentioned, the whole idea was to shape the tech and design to match the text.

So, how do publishers fit in when the text is finalised? Clearly there is a great deal of administrative and marketing power a well set-up publisher can bring to the table, but there are also big hits produced by small teams, so the role of the publisher is a precarious one.

JS: I think there will be an increasingly LARGE potential role for publishers in some ways. If, once more, I draw a comparison with games, we see that their role is to bring “talent” together, do the marketing, deal with platform holders and so on. So, Activision brings in Hans Zimmer to score Call Of Duty: Modern Warfare 2, has Infinity Ward develop, brings in top voice talent, throws the launch party and so on.

The interesting question here is where should the focus lie? In the traditional publishing world it’s almost exclusively the author, but I think that’ll have to change to a certain extent, because producing these apps is such a massively involved creative process that the end product becomes a lot bigger than any one individual. It’s a lot less personal, so the publisher’s brand may well become much more prominent. That’s not to say that will ALWAYS be the case, and clearly I’m biased. But yes, I think some evolved form of the “publisher” will remain centre of the mainstream so long as they can keep up – there’s probably a real opportunity for a publisher to adopt a truly disruptive business/development model and dominate this market, as we’ve seen Zynga (makers of Farmville) do in the games industry. The truth is that Apple will take meetings with Canongate, but they’re not going to chat to PopLeaf. None the less, if publishers don’t adapt, they’ll die. See: the music industry. That’s not to say that creatives can’t publish their own thing of course – it’s going to happen more and more. Indie publishing will undoubtedly thrive, especially when it comes to niche products.

DF: I think the talent pool is a key point. Publishers are built around people who have made a career of finding and developing authors and delivering their work to the world. I think a few start-ups and agencies who can also find talent think they can cut out the publisher – disintermediate. But that attitude really overlooks just what effort and experience is necessary for a successful editorial relationship with an author. I also think anyone who can facilitate a publication is a publisher and that role is evolving along with the digital landscape. I’ve described it before as being like a good, trustworthy bank who can invest in the right project, bring it to fruition and then reinvest the money sensibly. Whether this constitutes a traditional book publisher I’m not so sure. As for other things bar editorial we’re supposedly best placed for sales, marketing and publicity of our specialist product – books – but with digital products I know that traditional book publishers are relatively weak at the necessary marketing i.e. ONLINE.

JS: Totally agree with you Dan… and it’s not just maintaining a relationship with the author. It’s experience in producing a product. You make “stuff”. Shipping a product to a high standard is a skill that transcends platform or media.

BG: But some/many of those qualities aren’t necessarily tied up in what we think of as a publisher (or what I think of as a publisher…). With new digital routes to market, the very act of publishing is changed radically.