Category : Blog

Apple’s upcoming iPhone OS update will include an option for in-app advertising.  The iAd service is just the next step Apple is taking to beat Google in what will surely be a very lucrative mobile advertising market.

Does this represent an opportunity for book publishers and authors?  Absolutely.  Hear me out, even if you’re one of those purists who insists on books existing as they always have, without ads…

Let’s start with the fact that you could always sell two versions of your products: one with ads and one without.  The version without ads is priced higher than the one with the ads.  Test, measure, rinse, repeat.  Why wouldn’t you want the opportunity to study real world data from your customers to see whether ads have an impact on product acceptance and sales?  The results might just surprise you.

Or, how about all those free samples you have floating around?  I’m talking about the excerpts you distribute in the hopes that you’ll convert some number of browsers into buyers.  Your conversion rate is something less than 100%, so why not find other ways to monetize that experience?

This is yet another one of the Kindle platform’s shortcomings.  Amazon never built a model content owners could leverage to drive some additional revenue.  They didn’t offer it with books but I’m even more amazed that they never figured it out for newspapers and magazines, especially since we’re all quite used to seeing ads throughout those products.

In case you haven’t noticed, most customers feel ebook prices should be lower than print prices.  That pricing pressure alone should cause every author and publisher to experiment with services like iAd.  What have you got to lose?

P.S. — If Apple is smart they’ll build iAd into the iBooks app.  You’ll tell them whether or not you want iAd service included every time you provide them with ePub files for your next book.  Hopefully they’ll also let publishers try out that two-pronged approach where the book is available both with and without ads, at two different prices.

We’ve received a lot of comments here in the blog and via email about Android. You obviously are interested in a version of PocketBible for Android and that is exciting. We’re interested in a version of PocketBible for Android, too.

The way we see it there are six important mobile platforms right now:

1. iPhone/iPod Touch/iPad
2. Android
3. Blackberry
4. webOS
5. Windows Phone 7
6. Symbian

We have a product for iPhone. It has rather quickly become our flagship product, given the demise of both the Palm and Windows Mobile operating systems. (Both Palm and Microsoft have abandoned their legacy operating systems in favor of webOS and Windows Phone 7, respectively. Old apps won’t run on these new platforms.)

We have a partnership with BEIKS on the Blackberry platform. It’s a great platform but it tends to be more of an enterprise device rather than a consumer device and as a result the demand for third-party software, especially in our niche, is less than what you might expect based on the size of its market.

We have a partnership with Bits of God Software on webOS. We decided not to do our own development for this platform because its market share is relatively small and it does not support traditional programming languages like C++ and Java that would allow us to leverage our existing code.

Windows Phone 7 is a big TBD. Obviously there are zero devices right now and it has zero market share. We include it in the list only because it’s Microsoft, so we anticipate it will be a player. In the meantime we continue to support and release new content for PocketBible for the old/current Windows Mobile operating system

Symbian has problems we’ve addressed before here in the blog. It’s very difficult to successfully market a Symbian product. We’ve attended more than one Nokia/Symbian developer’s conference. We know what’s involved. The problem is not developing, it’s selling. We don’t have any plan to do a Symbian product.

That leaves Android. I can tell you now that we intend to develop a version of PocketBible for Android. But we think there’s more you need to know to understand where we’re coming from.

Sometimes I think people get the impression that we’re bigger than we are. On the one hand, that’s good, because it implies that we’re providing customer service at a level you expect from a bigger company, but on the other hand it can lead to unfounded expectations.

When it comes to product development, there’s just me and Jeff Wheeler here. We have some talented part-time employees who, while they’re skilled at what they do, only add up to the equivalent of a little over one more person. We use some outside contractors for content development (Bibles and reference books). That’s it. Needless to say, that limits what we can do.

Jeff and I used to work at Parsons Technology. I wrote the original version of QuickVerse and brought it to Parsons in 1988. Jeff and I had previously worked together and I hired him in to work at Parsons 1989. He eventually took over QuickVerse development and was the lead programmer for QuickVerse for Windows.

From about 1994 until 1998 when Jeff and I left, he had 10-12 programmers working for him. Most of those were working on QuickVerse. There was a similarly sized group of editors who created new content (Bibles and reference books) for QuickVerse. I had a small marketing group (two people) and a sales group (three or four people). All told there were about 30-35 people just in the Church Software Division. In addition to those we had access to telemarketing, direct sales, support, production and shipping, human resources, accounting, and other departments which we shared with the rest of the company. At our peak in the late 90’s Parsons had about 1200 total employees and the Church Software Division was about 10%-15% of the company’s annual sales. So you could argue that we supported about 120-180 employees.

You can do a lot with 180 people. If something new comes along, you can put a small team on it and get it done. You can’t do the same with three people.

In some respects this doesn’t bother us. We left Parsons Technology in order to be small. (See this article from Christian Computing Magazine which appeared on an old version of our Web site in 2001.) We’ve been big. We know what that’s like. We choose to be small. We enjoy what we do and wouldn’t have it any other way. But realistically, it affects what we can get done in a given period of time. We understand that.

We actually “started working” on an Android version of PocketBible a while back. But then Apple announced the iPad. We felt it was important to make sure that our existing PocketBible app would work well on the iPad. At first we were assured that would not be a problem (all well-behaved iPhone apps work on the iPad) but when we researched it further we realized we’d need to make some changes to optimize our performance on the iPad. We both dropped what we were doing and started work toward getting an iPad-aware version of PocketBible out the door.

This has proven to be challenging. We realized in order to take advantage of the cool new features of the iPad we’d have to re-architect the PocketBible user interface to better take advantage of the larger screen. At the same time, when we’re done the same code needs to run on the iPhone. So all of this has to be done carefully. (You’re going to love the iPad app by the way.)

So when I say “we intend to develop PocketBible for Android” you need to understand that doesn’t mean it will be done next month. It might not even be started by next month.

Furthermore, when we went from developing for Palm OS and Windows Mobile to developing for iPhone, we were able to bring along a lot of code from our previous projects because the iPhone “understands” the language in which it is written. We cannot run any of our existing code on Android. So we’ll be starting from scratch.

To put this in perspective, it took us about a year to release the first version of PocketBible for iPhone when we started with our existing code. It’s been almost two years now and we’re almost (not quite) done implementing all the features of our Windows Mobile app for the iPhone.

For Android we’re starting from nothing. I can’t say at this point how long it will take to develop PocketBible for Android. It’s probably not the case that it will take the year it took for the iPhone program plus the time to write the code we borrowed from our older programs. But at this point I can’t say.

While we are saying we intend to develop for Android, you also have to understand that we have lots of other requests and ideas on our to-do lists. Our Memorize! users would really like to see that app on the iPhone. Our PrayerPartner users are going to want us to port it to the iPad. So even once we start on Android, it might not be the only thing we’re doing.

This all helps explain why we don’t like to talk about what we may or may not do in the future. If we had told you on the day we started working on Android that we were working on Android, we’d have to tell you shortly after that that we had abandoned our work on Android to work on iPad. And now we’re telling you we “intend” to do an Android version but the schedule is unknowable. This won’t be a problem for those of you who are familiar with software development and understand what all is involved, but for those of you who are unfamiliar with software development you’ll probably get the wrong idea about the schedule — either thinking it will take us longer than it will or that it will be done sooner than is physically possible.

For a small company like ours these are exciting times. Back when Palm OS and Windows Mobile ruled the mobile space, we were riding pretty high. Things have changed quickly, and we’re working on responding to the changes. Thanks for sticking with us. We hope you’ll continue to do so.

Let’s say you’re Jeff Bezos and you’re heading into the office this morning.  It’s the first day back to work since the iPad launch.  We’re talking about the most significant gadget launch since, well, since the iPhone.  Suddenly the feature set of your ereader, the Kindle, looks pretty lame.  No color display.  No wifi connectivity.  Approximately 149,999 fewer apps than what the iPad supports.

What do you do?  My advice: Turn the Kindle for iPad app into the most exciting reader app in the industry.

You might have noticed that Amazon has released several "Kindle for…" apps up to now.  There’s a Windows one, a Mac one, an iPhone one, etc.  They’re all intended to complement the Kindle, not replace it…and that’s the problem with the iPad version.

It only took a couple of hours of iPad use to realize I’ll never touch my Kindle again.  Ever.  All my Kindle books are now on my iPad.  Do I mind that the iPad’s backlit display isn’t as easy on my eyes as the Kindle’s?  No.  I read off that iPad display for about 10 hours on Saturday and my eyes felt the same as they did the day before.

And while I love the Whispersync technology Amazon uses to keep my place across devices, I really don’t see myself reading books across devices now.  I can’t put the iPad down.  I used to read a bit in bed on my iPhone but now I’ll just do the same with my iPad.  The Kindle for iPad app is brain-dead compared to the iBooks one though.  Even the dictionary feature on the Kindle is missing from the app.  Then there’s the glaring issue with no sample support.  That’s right.  I can’t preview Kindle books through the iPad app, so how do they expect me to buy anything from them?!  (UPDATE: I stand corrected.  You can download Kindle samples to the iPad app.)  Amazon has apparently also conceded the newspaper/magazine segments to Apple as there’s no way to read your Kindle subscriptions through the iPad app.

As long as this app is nothing more than a bare-bones reader Amazon is giving me zero incentive to buy ebooks from them.  Why would I make my content investment in a dead-end technology when I could probably get the same title through the iBookstore?

So Jeff, resist the temptation to limit the functionality of the Kindle for iPad app.  Make it as rich as possible.  Make it extensible so that new types of content can be added to it.  Reach out to the community and see what features excite them.  Experiment and innovate!  Don’t let it rot on the vine like the "Experimental" features have on the Kindle.

Kindle sales are already going to take a hit because of the iPad.  You’ll continue selling to people who are convinced the Kindle offers a better reading experience than the iPad.  It doesn’t though.

You can afford to lose the hardware battle but you really don’t want to lose the content battle.  Focus on your reader apps and make them world class, OK?

P.S. — The iPad is great but it’s not without its flaws.  Click here to read the details of my first day with this very promising device.

The inspiration for this post came from my most recent (and probably final) Kindle book edition purchase.  The book is called Kiss It Good-bye and it’s the story of the 1960 Pittsburgh Pirates.  How could a Kindle edition book about a baseball season 50 years ago have anything to do with rich content?

Let me start by saying what I mean by "rich content."  Many in the publishing industry are trying to figure out how to integrate video with text.  A book or article featuring step-by-step or how-to content might benefit from the addition of video, for example.  In fact, video tends to get most of the attention when anyone talks about rich content.  Most people either yawn or note that they’d prefer to not have to navigate around a bunch of video inserted into whatever book they’re reading.  Good point.

When I bought Kiss It Good-bye I started thinking about ways it could offer rich content without being intrusive.  Although none of what I’m about to say could be supported on today’s Kindle platform, it all started there…

If you own a Kindle you’re familiar with the built-in dictionary.  You scroll to the line with the word you want to look up, click a couple of times and the definition appears.  Pretty simple.

Now apply a similar approach on the iPad.  You find a word you want to look up, touch it on the screen and a menu appears, hovering over the book page.  This menu not only has an option to look up the word you’ve selected, but other options as well.  For example, let’s say I highlighted "Pittsburgh Pirates."  The menu options might include look-up’s to the team’s entry in the Wikipedia or the Pirates official website.  That’s just the beginning though.

Now let’s say you get to a chapter where the author discusses the events of "Game 7 from the 1960 World Series".  Selecting that string shows a menu with a variety of options including the game’s box score.  That chapter will undoubtedly talk about the game’s hero, Bill Mazeroski.  Touch his name and the resulting menu would include links to Mazeroski’s career stats as well as a video of his exciting, series-winning home run.

In short, the book would be filled with all sorts of hooks to other content but none of it would interrupt the reading process.  No underlined words indicating links.  Nothing extra shows up till you touch a word or phrase on your screen, but it’s all there waiting for you to discover it.

Up to now I’ve talked about integrating links to content from
websites, but there’s no reason you couldn’t also build it out with
related content from other books, magazines, newspapers, etc.  This
builds upon the "network effect" Bob Pritchett talked about at our
recent TOC conference (and
I blogged about here).

Now the hard part: How do you build in all these connections?  If it’s a manual process it simply won’t scale.  I believe some level of automation is required for this to be successful.

One option is to put the book through something similar to the indexing process, but in this case, every word/phrase in it is run though a tool that pulls back all the top relevant links from the web, other books, etc. Handwork is required to ensure the best links make the final cut, but over time you’re building a database of reusable links.  So every time you refer to the same team, player, etc., you wouldn’t be starting from scratch.  Web links change over time though, of course, so verification would still be a required step.

The key is to make all this content accessible but not intrusive.  Maybe it requires a new authoring tool.  Or perhaps it’s something that could be built into a publishing company’s existing toolchain for editorial and production.  Either way, it’s something I believe could turn static books into richer content products, without interrupting the natural flow of the original work.

With its full-color touch screen and 3G/wifi connectivity, the iPad is the perfect device for this, btw.  Do you see a opportunity for a product like this?