
Last week we launched NOW Magazine's first iPad app. It's been a long time in the making. I've been working on it since the announcement of the first iPad. At that time, NOW's publisher, Michael Hollett, came to us and asked us to make sure people would be able to get NOW on the iPad as soon as it launched. What came next was months of research and then a few months of evaluation and then many more months of design and development to get us to where we are today. I'm going to share the process from concept to delivery, it's going to be long and detailed but I'll do my best to break things up into digestable chunks.
Initial R&D
With the initial announcements one of the apps Apple touted was iBooks. This seemed like an obvious place to start in terms of delivering a reading experience. This led us into an exploration of the ePub format, a limited by widely distributed way to deliver content to e-readers. At the same time we also started monitoring what our options were for systems that would integrate with NOW's InDesign/Woodwing publishing workflow.
A trip to New York to attend Woodwing's digital publishing world tour confirmed some of my fears about the publishing system integration. Woodwing built their own iPad App front-end that can display a format published from their system. Several challenges immediately presented themselves to us. One was the cost. We'd have to upgrade all our systems, we'd have to pay an initial set-up fee, as well as per issue delivery fees. Managable, but not ideal. The real show stopper was that digital publications, while able to re-purpose content in the system still required new layouts – one for each orientation – that would require more manual labour in InDesign and Woodwing to put together.
At the same time I was also participating in Adobe's Digital Publishing Suite beta and getting a feel for Adobe's own solution. After some sleuthing I'd found out that this is what Conde Naste was using to create the beautiful digital editions of Wired that Apple had been showing off. Seemed promising. At least until I discovered that the problems were the same. This solution would require far more human resources to build each issue than what we would be able to afford. Plus at that time we had no idea what the end cost from Adobe would be. As it turns out the cost would have been prohibitive for NOW so I'm glad I early on steered away from this.
What was clear at this point was that there was simply no way we would have a native app edition of NOW ready for the iPad's launch. Also because it was something so new that would require a significant investment to be part of I started to push back against buying into a 3rd party solution too early. Instead we focused on the ePub edition of NOW as that had the added benefit of being e-reader friendly.
ePub
The epub format is one that's been around for awhile, used by devices like Sony's e-reader. It's also supported by iBooks and other reader applications across numerous devices. Essentially epub is a barebones format based on html with a few special book-like additions – think table of contents definitions. It's also extremely particular about validation. Any little thing can cause the whole experience to come crashing down.

Regardless, the simplicity of the spec, it's basis in html and the support from iBooks all made it seem like the obvious launch target for us. Our production team started out by taking a look at how we might publish epub's from our InDesign system. While they came up with a workable solution that involved much manual label and some crafty applescript the end result left much to be desired in terms of workflow efficiency.
Next step was to tackle this from the web team's perspective. We used our web cms to spit out the content and built a workflow using Coldfusion to do all the heavy lifting and assembling of the content into an epub. This is what we settled on, with some iteration to get our web content cleaned enough, the workflow worked out fairly well.
Try out our ePub edition.
Not Sexy Enough
As you can imagine, epub really isn't all that sexy, especially on a device that's all about slick, bling filled experiences. Following the iPad's launch we continued to monitor various options for publishing. Many of these included systems that would generate images of your print content and put them into a basic page flip app. We also followed what Wired, Popular Science and various major news outlets were doing. The approaches varied wildly from trying to mimic print as closely as possible to abstract interactive experiences that were more experimental than practical.
Ultimately we ended up with a few criteria that we used to evaluate solutions that were presented to us:
- required a minimal amount of human labour to publish each week
- no weekly/per issue costs
- must allow for some degree of interactivity within the content
- must be text based so that text could be searched, copy and pasted, etc.
- need a format that could be re-used for other device platforms
- must provide a way to integrate into either our print or web advertising platforms
- should work offline
- should look great, allow us to meet our branding needs and perform quickly – must be sexy

DIY
As is often the case at NOW, we're never quite happy with the off the shelf solutions. We've got a small team that is worked to the max and can't afford the time to integrate new major systems into their weekly workflow. What we do have is myself and Adam acting as our in-house dev shop. Ultimately we decided to build our own solution that would meet the criteria listed above.
To do this we needed to build the following:
- an iOS app that would act as the delivery platform for the issues/content
- a format to publish the issues/content
- a back-end system for the iOS app to talk to in order to get new content
- additions to our web-cms / epub publishing workflow to publish to this new format
For the format, we knew we wanted to go the HTML route in order to make the content portable and to allow easy conversion of our web content. We ended up using a text plist to define the contents and metadata of an issue, then zipped that up with the html and images for each story. This allowed us to pass along valuable extra info, such as source url's to allow online sharing.
Not having any iOS skills in-house we decided to contract out development of the iOS app to Relish Interactive who we've worked with in the past on our last website re-design. We let Relish do the design work on the app with some feedback from our art department to help keep things on brand. The resulting designs are slick and versatile providing a nice alternate view of NOW's content that was distinct to the tablet experience.
I built in some additions to our app api (I'd built a framework already for supporting data requests from our iPhone Restaurant and Concert apps) that would allow the iPad app to get information about the latest issues, check versions to reduce bandwidth usage and to actually download the zip files for each issue.
Adam went to work on updating the publishing workflow he'd created for epub's to handle all the new things required for the tablet edition.
The End?
The resulting app has been a great success. We've seen tremendous download numbers, hit #25 on the Canadian app store, were put on the New & Noteworthy and What's Hot lists in the app store and even have a featured app spot right now. User and advertiser response was been extremely positive.

We're very happy with the end product. Though the thing I'm most excited about is the possibility to take this further. Within the existing app we want to start pushing what we are doing with the html content. Some early tests with a lightbox effect using jquery proved to be extremely slow. But that's not stopping us. We've got a number of interesting ideas to make the content more dynamic. We've also been toying around with ideas for special tablet exclusive content and different ways to package up some of our online only content.
Even more importantly, the format we created will allow us to re-use it for other device platforms. Our first target will be Android. We've started to experiment with Flex 4.5 as the platform for building this next-gen of device application with. We're going in this direction because Flex/AIR will allow us to hit a number of different platforms using our existing in-house development skills. If this doesn't pan out then we'll take a look at some other options.
UI Design Gotcha's
We ran into a few UI problems as we worked on the app. The touch controls for the app called for a tap anywhere in the main window of the story view to expand the menu overlays. This was fantastic at first and consistent with other e-reading apps we'd looked at. The problem with this first became apparent when we wanted to add tap actions to images and ads. We couldn't do it. We ended up have to make the app check to see if the user was tapping on something in the app that needed to be interactive or just in a general area of the window.

This solution has worked for now but still has problems. While touching ads triggers the clickthrough to load an in-app browser window, we can't do much else. For example, we'd like to build some in-page ui elements using javascript to change the content within the layout, but we have no means to allow the user to activate these controls.
For full screen ads our solution was to enforce a universal button to touch for the clickthrough. Not ideal for numerous reasons. At some point we'll be exploring how to deal with these issues in a future version.
Conclusion
The end result of this project is an application that we are very proud of. The folks at Relish Interactive did a fantastic job and we are quite happy with our internal tools for publishing the issues. Check out the app and let me know what you think. If you're interested in more technical details I'd be happy to do a follow-up post in response to particular questions.
