This is a guest post submitted by Craig Button (@TheProdSon)

Introduction, Quick Summary
Since most of you have no idea who I am, I suppose I should introduce myself. First and foremost I am a believer and follower of Jesus Christ. After that I’m a geek. I’ve owned just about every type of computer ever made and today work on both Mac and PCs depending on what I’m doing. I use both Pages and MS Word, prefer Excel to Numbers, and either PowerPoint or Keynote depending on what I’m doing. I’m a health care provider by profession, an educator by avocation, I’ve been clergy, (church offices on weekdays weren’t what I was expecting) and am now a grad student. I’m always looking for ways to package and present information.
I was excited when Apple announced iBook 2.0 and iBooks Author. I’m in the process of producing a couple of books/ebooks and was looking for something that would make it easier. I was hoping that iBA was going to be it.
After spending a few days playing with it (and I have to be honest and admit it was playing, not a focused systematic study/evaluation of the program) There are some conclusions that I’ve come to regarding iBooks Author which might not match your needs, but hopefully shines some light towards its strengths and weaknesses at this juncture of the application.
Summarizing the Positives and Negatives
There will be projects I’ll use iBA for. However, I won’t be using it for everyday kind of work. Not because, I don’t like it, or it’s a bad program, or even because of the EULA that says you can only sell product from iBA thought Apple. I’m accustomed to a bit more control and flexibility when creating publications, and iBA doesn’t quite meet those spot on – though its not far off.
Positives about iBA: It works, it looks good, it’s easy and it produces what it says it’s going to.
Negatives about iBA: it produces HUGE files. A test file went from 800K .txt file to 27MB (~1000K = 1MB) with a couple of pictures added. The second, and in my case the biggest thing against iBA, is it only produces a product that can be viewed on iOS devices. That means not on the Kindle, not on a Nook, not on an Android phone, not on anything unless it has been made by Apple. I’m a Mac fan boy. But, I’m about communication. Therefore, limiting my target audience isn’t good for me. My first product is to be a textbook on Critical Care for Emergency Room nurses. The second book will be first aid and health for photographers. Both topics I’m pretty passionate about (hence my issues with file sizes and limited devices).
It’s About Workflow
It’s about workflow. The term workflow is one that you hear in the digital photography world. It is the term that defines the flow of data from the camera to the final print. I think the term works well for the ePub/ebook industry as well.
My Workflow: I use a program called Scrivener. This is a Mac application, (Windows and Linux also available) that I use to produce the text of my work. It’s a combination text editor and research organizer. This is probably were 80+% of my work is done. I do all my writing within Scrivener. It also produces ePub files which can be read by nearly all computing platforms. It does have some drawbacks, with one of them being that its not easy to place tables and graphics into the output. From there, I use Adobe InDesign for layout that needs formatting and graphics. I don’t own this program; I rent it as needed since I only use it maybe 1-2 months out of the year. Using InDesign I produce a ePub, witch is a zip file that includes all the information needed for the ebook reader to read your file. It only takes a little modification for it to work on any of the readers.
How could iBA fit into this workflow? Well in my next publication, it might work for me. These books I’m publishing on health care and first aid directed at travel photographers whom are likely to have iOS devices. But, in using iBooks with plans on selling it, I’m sure the iPad market will be a bit too limiting. I will however give it a try. iBA is very easy, and I’m hoping it will allow me to easily produce the product I want. However, for anything that is text-based, or contains just a few graphics, the files produced by iBA are way to big and to limiting.
The workflow I have fits my use case, and allows me the broadest target audience. While I’m a geek, and still have a copy of the original PageMaker running on a Mac Classic, I’d like to have more control than what iBA offers. On the other hand, for someone who has never produced an ebook, iBA might be the perfect tool.
Conclusions
After writing the first few paragraphs, and sleeping on it, I came up with a few other thoughts. The first is that I’ve been through this kind of transition before. I remember when PageMaker first came out and people had lots of different fonts to use. I remember when Photoshop first came out and it was affordable to anyone to buy. People produced some horrendous publications and photos. And you’ve all probably sat through some pretty long, boring PowerPoint presentations. Just because the tools are there, doesn’t mean that everyone should use them.
I’m a Tim Taylor, not a Bob Villa, when it comes to using those hammers and screwdrivers. Like any task which needs to be done, it deserves to be done right. Use the right tool, have the right people use the tool, and spread the word.
For more information and to download (free), see the iBooks Author page on the Apple website. Note: content created with iBooks Author can only be read on devices with iBooks2 on the iOS device.
Craig is @TheProdSon on Twitter.
When I am at a coffeeshop, I usually have my mobile to the side of me and my iPad in front of me -occasionally with my wireless keyboard. At times, at least when I’m typing on the keyboard, I’m stopped to ask if I like my iPad, or how I get along with the keyboard. On one particular day, a woman asked me my opinions on the iPad as she was considering one. It just so happened that less than an hour before she asked me that, Amazon announced its new slate of 








Noticing Things with Bible Formats
Friday, November 19th, 2010A Short History of Files
Years ago, I got involved with the Palm Bible+ project as the webmaster and a user. As one of the few free Bible applications (at that time), Bible+ used to get all kinds of requests for Bibles in various languages. This was usually easy to do with a bit of programming on the part of the user, but you usually ended up with a Bible that would only work with that application.
In a similar fashion, there was the eSword application and Bibles created for it. This application were also free to distribute and worked across several desktop PC platforms. In the years since initially running into the eSword project, there’s been several updates to the file format, including the use of the STEP format, and the creating of a Windows Mobile client to also read these texts.
On the other side of the Bible+ project was the move to DRM texts. The original developer of the Palm Bible Reader made steps to create a version of the Bible reader that would accept copyrighted texts. The Bible+ project grew out of this, yet it was clear at this point that there would need to be two methods for handling Biblical text/media.
The Dollar Items
Of course, not everything can be for free, and as we’ve chatted about here several times, the issue of Bible formatting is a sensitive one for those publishers and developers involved.
There is a clear line though towards Bible formats and what becomes needed to be paid for. For example, there has always been numerous versions of the Bible available for free – but, it had not been until recently (past three years) that you’d be able to find some of the more modern translations available for free. These were (rightly) tied to an application, and coded to work specifically with that body of text.
This works well when you are talking about the audience of readers whom are invested into reading the text – those people who are new to the faith, or who only see the Bible for a casual reading/reference work will place a different value to it, and therefore look at the cost of it to them differently.
Not everything can be free, and not everything will fly off the shelves priced too far away. There’s got to be some kind of answer to this issue, and maybe it is near the actual formats that are used in various Bible applications.
What I Noticed
When looking at the Mobile Bibles page, I noticed a few things. The Bible+ Project was originally just for one platform, and the Bibles created for it can now be read in PalmOS Classic, Symbian, BlackBerry OS, and Maemo/MeeGo. Bibles made for the eSword environment also are supported on several platforms (Windows/Mac/Linux, Maemo, Maemo/MeeGo, and some previous Windows Mobile devices).
And that’s the free stuff. When you get to the paid Bibles, there’s compatiability for everything from Java-based handsets, to iOS (iPad, iPhone), Android, Symbian, and BlackBerry mobile devices.
A newer approach is being taken on by Logos, with the Biblia API project. Here, its not so much the actual reading environment that is being pressed, but you are given content, and have the ability (through license agreement) to use that content in a manner that works best for you. So here, you are using both new and old texts, free and paid texts, in a connected space, over a browser, or a customized (for the platform) application. So far, other companies aren’t going this route, but I do postulate that this would be the eventual end of much of the content that we deal with Biblically when consistent connectivity (QoS) isn’t in question.
In effect, everything is covered by two approaches to Bible formats:
I think that we still need to get to a point of seeing one commonly used Bible format, with the sharing, purchasing, etc. components handled by device/user tokens. And we might get there. Looking at just what is available now, and how the needs of those looking for Bibles are being addressed, it looks like we might essentially get there – but with users needing to pay as much attention to the reading platform, as much as they do the text itself.
At least that’s what it looks like on our Mobile Bibles page. I’ll probably tweak this page even more later when more of these associations are noticed. Besides making it easier for you to find a reader, it might help you make better decisions about how to manage your digital Biblical assets before the next major change hits several more software/development companies in this space.
And to think, I’m not even touching (yet) audio Bibles
Tags: Android, Bible, bible software, bibles, BlackBerry, eSword, file formats, files, Future Trends Series, hardware, iOS, iPad, iPhone, Java, Maemo, MeeGo, mobile platforms, mobility, open source, PalmOS, publishing, software, webOS
Posted in Commentary, Devices and Software, Future Trends | 5 Comments »