Publishing to the iPad

Publishing to the iPad

NPG recently launched a new iPad app Nature Journals – an app that allows us to distribute journal content to iPad users. I thought it might be interesting to highlight a few of the design decisions we took and discuss why we took them.

Most publishers when they make an iPad magazine tend to design a skeuomorphic digital facsimile of their printed magazine – they build in lots of interactive features but build it using similar production processes as for print and make it feel like a print magazine. They layout each page (actually they need to layout each page twice one for landscape and one for portrait view) and then produce a big file to be distributed via Apple’s app store.

This approach feels very wrong to me. For starters it doesn’t scale well – every issue needs a bunch of people to layout and produce it; from an end users point of view they get a very big file and I’ve seen nothing to convince me most people want all the extra stuff; and from an engineering point of view the lack of separation of concerns worries me. I just think most iPad Magazines are doing it wrong.

Now to be clear I’m not for a moment suggesting that what we’ve built is perfect – I know its not – but I think, I hope we’re on the right track.

So what did we do?

Our overarching focus was to create a clean, uncluttered user experience. We didn’t want to replicate print nor replicate the Website instead we wanted to take a path that focused on the content at the expense of ‘features’ while giving the reader the essence of the printed journals.

This meant we wanted decent typography, enough branding to connect the user to the journal but no more and the features we did build had to be justified in terms of benefits to a scientist’s understanding of the article. And even then we pushed most of the functionality away from the forefront of the interface so that the reader hopefully isn’t too aware of the app. The best app after all is no app.

In my experience most publishers tend to go the other way (although there are notable exceptions) – most iPad Magazines have a lot of app and a lot of bells and whistles, so many features in fact that many magazines need an instruction manual to help you navigate them! That can’t be right.

As Craig Mod put it – many publishers build a Homer.


When Homer Simpson was asked to design his ideal car, he made The Homer. Given free reign, Homer’s process was additive. He added three horns and a special sound-proof bubble for the children. He layered more atop everything cars had been. More horns, more cup holders.

We didn’t want to build a Homer! We tried to only include features where they really benefit the reader or their community. For example, we built a figure viewer which lets the reader see the figures within the article at any point and tap through to higher resolution images because that’s useful.

You can also bookmark or share an article, download the PDF but these are only there if you need them. The normal reading behaviour assumes you don’t need this stuff and so they are hidden away (until you tap the screen to pull then into focus).

Back to the content…

It’s hard to build good automated pagination unless the content is very simple and homogenous. Beautiful, fast pagination for most content is simply too hard unless you build each page by hand. Nasty, poorly designed and implemented pagination doesn’t help anyone. We therefore decided to go with scrolling within an article and pagination between articles.

Under the hood we wanted to build a system that would scale, could be automated and ensured separation of concerns.

On the server we therefore render EPUB files from the raw XML documents in MarkLogic and bundle those files along with all the images and other assets into a zip file and serve them to the iPad app.

From the readers point of view this means they can download whole issues for offline reading  and the total package is quite small – an issue of Nature is c. 30MB, the Review Journals can be as small as 5MB by way of comparison Wired is c. 250MB.

From our point of view the entire production is automated – we don’t need to have people laying out every page or issue. This also means that as we improve the layout so we can rollout those improvements to all the articles – both new content and the archive (although users would need to re download the content).

No it’s not a generative platform but does it matter?

A lot of people have written a lot about Apple’s new toy. A lot of people are upset it doesn’t live up to the hype and lots of people point out that it’s a closed platform and not really a proper computer; some worry about what all this might mean for children learning how to code and what it means for who controls your computer. And they’re all probably right, or not — but I’m not convinced that’s the point — I think it might provide a great opportunity for Web developers.

The Apple iPadTwo best pieces of analysis, I’ve read, of the iPad and what it might mean for the future of our personal computers come from Jonathan Zittrain and Steve FrankIn the FT, Zitterain points out:

The openness on which Apple had built its original empire had been completely reversed.


The iPhone’s hybrid model of centrally controlled outside software is already moving beyond the smart phone. This is the significance of the iPad. It could have been built either like a small Apple Macintosh – open to any outside software – or as a big iPhone, controlled by Apple. Apple went with the latter. Attach a keyboard to it and it could replace a PC entirely – boasting plenty of new apps, but only as Apple deems them worthy.

But as s Steve Frank explains the significance of the iPad isn’t the iPad it’s what it means for future PCs.

[today’s] computers are general purpose, do-it-all machines. They can do hundreds of thousands of different things, sometimes all at the same time. We buy them for pennies, load them up to the gills with whatever we feel like, and then we pay for it with instability, performance degradation, viruses, and steep learning curves.

But the iPad and the computer’s of tomorrow are:

… task-centric. We are reading email, browsing the web, playing a game, but not all at once. Applications are sandboxed, then moats dug around the sandboxes, and then barbed wire placed around the moats. As a direct result, New World computers do not need virus scanners, their batteries last longer, and they rarely crash, but their users have lost a degree of freedom. New World computers have unprecedented ease of use, and benefit from decades of research into human-computer interaction. They are immediately understandable, fast, stable, and laser-focused.

Steve Jobs claims that Apple took this approach with the iPhone because you don’t want your phone to crash as often as a PC, which is true – I don’t – and that he had allegedly banned Flash from the iPad because “most Mac crashes are due to Flash”. But there’s another, more likely reason, as Michael points out, it could also be:

Apple’s attempting to own / lock in other people’s customer relationship model […] apple wanna own that relationship [because] it’s about owning the gateway to culture. Owning the point of sale is one thing; owning the point of subscription [is] quite another. Subscriptions map to habbits + hobbies + viewpoints.

Michael’s analysis certainly feels right – but that doesn’t mean that Apple will get away with it. If you look at most iPhone applications there’s really no reason why they need to be phone applications – there’s no reason why they couldn’t be web apps. And while that’s true now it will be even more true as HTML5 becomes more widely adopted. This isn’t anything particularly original, indeed Steve Jobs suggested the very same thing in 2007 when asked about the iPhone SDK – he suggested Safari.

The success of the Apple iPod store has proven that Steve’s view wasn’t held by most people – they wanted to build phone applications and people want to download them. I can understand why, from  a developers point of view the app store is a great market place and it allows you to monitise access to your app in a way that people don’t seem to tolerate on the web; and from an end users point of view it’s convenient and fits with most people’s expectations of what an application is.

But what was true for a phone now might not be true when it comes to the iPad, especially with HTML5’s APIs, including geo-location and offline storage capabilities (supported by Safari), tools such as jQTouch and the increasing awareness of web apps such as Google Docs, Latitude and Voice by the public at large.

It’s true we can’t build all apps as web apps — games in particular will need to remain native iPad/iPod apps and I’m sure those publishers wishing to employ DRM will stick with iBook or iTunes but for lots and lots of content and data centric applications the Web is the open platform we can all use without Apple’s permission.