App vs iBook
Somethin' Else has just launched two digital book products for Royal Botanic Gardens, Kew. While both are exclusive to the iPad, they were made in very different ways. One, The Plant Hunters, was created using Apple's iBooks Author software. The other, David Nash at Kew, was built as a native iOS application.
Since launching we've been reflecting on the different content design considerations when approaching digital publishing for the App Store vs the iBookstore.
Why produce enhanced books in two different ways? In short, because we felt it would ultimately lead to a better experience for readers. Once we knew what we wanted to accomplish editorially, the technical decisions were easier to make.
While native apps give the most freedom in terms of functionality (you can do anything you want, within reason), there is a much larger cost and time overhead if you're creating the book from scratch (e.g. coding how page transitions work, how content behaves on each page, etc). The visual design is also more flexible, but unless you've built special tools for them your designer will need to find their way around XCode (Apple's development environment) which can be a steep and frustrating learning curve.
iBooks Author, on the other hand, does a brilliant job of simplifying the design and production stages – all of the hard work in building an infrastructure for how pages and content behave is done for you. This simplification does mean that design choices are sometimes limited and can constrain the visual outcome of a project. You can spend a lot of time trying to find ways to work around a particular unexpected restriction.
In terms of interactive functionality, iBooks' widgets are also not to be sniffed at. As well as the in-built widgets (which are quite powerful, especially the ability to import from Keynote), there's the potential to code bespoke interactive features in HTML5, so if it can be accomplished in a browser there's a reasonable chance you can do something similar in iBooks. The main downside is that you don't quite get the same high performance as from a native app, with noticeable loading times on pages with a lot of assets. Additionally you don't have access to some of the deeper hardware of the iPad (e.g. gyroscope, camera, location data).
David Nash at Kew was most suited to being a native app as the content doesn't need to be experienced in a linear way, meaning users can choose their own path through individual atomised pieces. We added filters so items on a particular theme can be highlighted, favourites so that they could be pinned for later reference, and a map locating everything that related to an exhibit at Kew back to the real world. The freedom of producing an app meant that we could implement each of these features in exactly the way we wanted to make something that could be enjoyed at home or used at the exhibition itself.
The Plant Hunters, on the other hand, is much more of a linear experience, told as a story which started with the earliest examples of botanic exploration and finishes in the modern day. We wanted to keep the form of the book, but add interactive features, such as 'pull-out' bits of archive content and video. Widgets were perfect for this, and we coded some to fit our exact needs. There wasn't a need to build a whole new reading interface from the ground up as a native app - using the existing iBooks interface made total sense.
By Trevor Klein, head of development and Tom Green, senior producer at Somethin' Else
Platinum Sponsors
Gold Sponsors
Bronze Sponsors
Podcast
Recent blog posts
- Ten challenges to innovation in publishing
- Publishers should embrace entrepreneurial authors
- Dreams of interoperability
- The Story behind The Story by Bobette Buster
- Pottermore's winning digital strategy
- Tools done changing?
- Publishing is Booming But it's Still Gloom on the High Street
- Authors and book rights – some more truths
- “TOC was a great ride…”
- Bright lights, big web
Recent comments
- I have a strong feeling that
2 weeks 3 days ago - Paid-For Showrooming Is Madness
3 weeks 3 days ago - Showrooming
3 weeks 5 days ago - You are asking the wrong
4 weeks 1 day ago - E-Lending
4 weeks 2 days ago - Frameworks and Lotteries
4 weeks 4 days ago - Eisler's point has been misunderstood
4 weeks 4 days ago - Publish and be damned?
4 weeks 4 days ago - Great post, Chris! But you're
6 weeks 2 days ago - Numbers Game
6 weeks 4 days ago
Comments
Re: Rob's post
Rob - totally agree that building an app from scratch is a gamble, but I'm not convinced that it's inherently any more or less risky than building a game. Far more games fail than succeed, losing their creators' money; the app store is littered with them.
All we can do is try to de-risk ventures as much as possible, putting together a strong editorial proposition with the right technical implementation and a justified business case.
An Obj-C option for iBooks Author wouldn't hurt though!
App vs iBook
Each really has it's place. However, building an app from scratch is a huge gamble, cost and time wise. It's easy to risk huge sums on a game, because it's almost gaurenteed to be repayed, but App Books are still in the process of proving themselves.
It would have been nice if Apple had gone a different direction with iBooks Author: they could have a plugin or library for XCode, so that developers could create a custom native code iBook along the lines of an App. An iBook written entirely in native Objective C, that would have been a killer option.
Rob Zel
AppOpus.com
Post new comment