Category Work

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.

"Magazines to Read" by Long Nguyen. Some rights reserved.

“Magazines to Read” by Long Nguyen. Some rights reserved.

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.

TheHomer

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).

Our development manifesto

Manifesto’s are quite popular in the tech community — obviously there’s the agile manifesto and I’ve written before about the kaizen manifesto and then there’s the Manifesto for Software Craftsmanship. They all try to put forward a way of working, a way of raising professionalism and a way of improving the quality of what you do and build.

If at first you don't succeed - call an airstrike.

Banksy by rocor, some rights reserved.

Anyway when we started work on on the BBC’s Nature site we set out our development manifesto. I thought you might be interested in it:

  1. Peristence — only mint a new URIs if one doesn’t already exist: once minted, never delete it
  2. Linked open data — data and documents describe the real world; things in the real world are identified via HTTP URIs; links describe how those things are related to each other.
  3. The website is the API
  4. RESTful — the Web is stateless, work with this architecture, not against it.
  5. One Web – one canonical URI for each resource (thing), dereferenced to the appropriate representation (HTML, JSON, RDF, etc.).
  6. Fix the data don’t hack the code
  7. Books have pages, the web has links
  8. Do it right or don’t do it at all — don’t hack in quick fixes or ‘tactical solutions’ they are bad for users and bad for the code.
  9. Release early, release often — small, incremental changes are easy to test and proof.

It’s worth noting that we didn’t always live up to these standards — but at least when we broke our rules we did so knowingly and had a chance of fixing them at a later date.

One BBC nature

A few weeks ago we merged Wildlife Finder into the nature site and launched a new blog – and today we’ve taken the final step and brought Earth News into the fold to create a consolidated BBC nature site.

From a certain perspective this doesn’t represent a big change – after all we’re still publishing exclusive natural history news stories, video collections and video clips and information about: animals, plants, habitats (and the ancient earth’s habitats, such as Snowball Earth), adaptations & behaviours, places and ecozones, the geological time periods when they lived, the major mass extinction events, including the one that killed the dinosaurs, in fact lots of information on the history of life on earth and the fossil record. We even have a page about fish – and they don’t really exist!

However, from another perspective this is a really big change. It’s a big change because we’ve (hopefully) made everything so much simpler.

Screen grab of the new BBC nature site - features section

We’ve made it simpler by bringing everything together into one site and removed the various sub brands – if you love nature and natural history everything is now in one place: news stories, video clips from the archive, opinion pieces and more.

Bringing everything together has also allowed us to make a few additional changes which should help us more easily publish the content.

In addition to natural history news we have a features section where we can bring together articles and photo galleries (like this one) and a new blog Wonder Monkey written by Matt Walker. Matt has written a few posts so far including this one on the oddball midge that shouldn’t exist.

I really hope you like it. It represents the culmination of two years of work, during which time we launched and evolved both the site itself and the editorial proposition – there now are c.3,000 clips available online (many of which are available worldwide) about almost 900 animals (both prehistoric and living), 50 plants etc.

And of course wildlife data is for machines too.

However, after two years of development this represents the last major release, for a while at least. The site will continue to grow because we are continuing to create great new content as well as digging out the best bits from the archive – like this video collection looking back at David Attenborough’s Madagascar (starting with Zoo Quest 50 years ago). But there won’t be any major new features for a while, not that that’s a major problem – the site should offer a rich experience with amazing content.

As I said yesterday, I’m very proud of what we’ve produced and if I can marshal my thoughts I’ll try and write a post or two about how we went about building the site and the lessons I learnt on the way, until then enjoy the site.

Follow

Get every new post delivered to your Inbox.

Join 1,337 other followers

%d bloggers like this: