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

Tags:

Comments

Re: Rob's post

Trevor Klein's picture

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

You will need to register to comment on Futurebook.net. Register here This will take less than a minute.
By posting on this website you agree to the Bookseller Comments Policy. comments go live immediately, please be relevant, brief and definitely not abusive.
Enter your FutureBook username.
Enter the password that accompanies your username.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <b> <i> <strong> <br>
  • Lines and paragraphs break automatically.

More information about formatting options

Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.