Yesterday, Amazon released information that with the introduction of the Kindle Fire tablet they will also switch to a new eBook format. Anyone who will check out the quick overview will certainly be pleased and also notice that with the upcoming KF8 eBook format, Amazon seems to have addressed virtually all the shortcomings I have raised in my blog post 10 Things Amazon should correct in the Kindle that I posted a while ago.

And yet, I am not happy. Why is that?

One would think with these issues out of the way, the Kindle should finally catapult itself to the top of the eBook capabilities, right? Well, yes and no. The problem lies in the details, the fineprint, so to speak. The big problem with the introduction of the KF8 format is that Amazon is doing a pretty hack job with this, I am very sorry to say, because, according to Amazon’s announcement and FAQ, none of the older Kindles will be able to support this format.

Why is this a problem? Well, as a professional eBook formatter, the question for me is, how am I supposed to deal with this? Instead of creating the foundation for one rock solid Kindle platform that has powerful capabilities, Amazon is now going down the road of platform fragmentation. Already we had issues that the Kindle 2 and Kindle 3 had capabilities the Kindle 1 did not possess. It was a big problem because things such as tables were unusable, despite the fact that the capabilities were built into the K2 and K3. Since authors have to make sure they cover the largest possible market share, however, using tables made no sense, as the Kindle 1 did not support them and rendered them in a useless, garbled fashion.

With KF8, things will get even uglier. We now have three different sets of capabilities. The Kindle 1 at the bottom end, the Kindle 2 and Kindle 3, and then the new Kindle 4 and Kindle Fire. This is not a smart move on Amazon’s behalf and reeks of either laziness or engineering ineptitude.

From a programming standpoint none of the features introduced in KF8 are in any way supercharged capabilities that require special hardware. Let’s face it. eBook reader software is, in effect, nothing more than a specialized web browser. It is not rocket science! Therefore, Amazon’s decision is hard to comprehend. Web browser implementations have been written a thousand times — I wrote one myself 10 years ago for use in a computer game. There are reference implementations out there that they could have used for free, all things that should have made it possible to retain a unified platform. So, why could’t the software engineers at Amazon make sure they introduce these capabilities in all devices through firmware upgrades?

It is a very short-sighted decision in my opinion, that not only shortchanges the end users, but causes a lot of problems on Amazon’s end as well.

They will now have to begin offering and delivering different versions of the same books – one formatted according to the old, outdated MOBI file specifications, and another one formatted according to the new KF8 guidelines for this to make any sense. How does that make sense?

So, not only will they now have to deal with publishers having to create and upload multiple versions of the same book. This comes at an additional expenses to authors and publishers, as they have maintain two versions of the book. But it also comes at the expense of Amazon, as they have to modify their existing pipeline to accommodate these multiple versions.

To make matters worse, they will have to educate people which format to use for which device, and they will have to prepare – and possibly ramp up support staff, to answer all the customer questions stemming from this sort of confusion.

As I said, I do not think this was a very smart move and it is not in Amazon’s best interest.

Writing and updating the firmware for all existing Kindle platforms would have been a clean way into the future, without all the hassle that comes with platform fragmentation. I know what I am talking about – I’ve been programming for 30 years and I’ve been working in the mobile field for many years, where device fragmentation has gone rampant and costs publishers and cell phone carriers hundreds of millions of dollars every month just to support the insanity.

I know, that for me, KF8 is a step backwards, no matter how attractive it looks at first glance. For the most part it is useless out of the gate because if it doesn’t work on all Kindle devices, it has no value to me and I suspect most of my clients.


Addendum:

An important point was raised in the comments to this post that deserves a few additional words, I think.

Amazon promises that KindleGen 2, the tool they provide to allow authoring KF8 files “will convert your content so that it works on all Kindle devices and apps.”

If you think, this means that all problems are solved with this, you can smoke that notion in a pipe. There is a big difference between could and should.

Just because KindleGen 2 promises to convert your books, doesn’t mean you should, because the output quality will be dubious at best. Of course, if you are part of the I-don’t-care-just-make-it-easy, Smashwords-adoring crowd, yes, that might work for you, but if you take pride in your ebook’s layout and formatting, this is not going to fly.

Let me illustrate this with a very simple example. Say, you have an image and you add the float property to it, to have it embedded in your text with the words flowing nicely around it.

When converting such a file, all KindleGen can really do is ignore the float property — which, coincidentally, all the devices do already. As result, on a Kindle 2 you will now have the image sitting on the left side of the screen with nothing surrounding it. Perhaps the first line of the text that was supposed to float around it will sit firmly at the bottom, creating a huge, ugly gap. Surely not what you had in mind.

If you had properly formatted a version for MOBI devices, instead, you would perhaps have centered the image in this case and spaced it out a little more. That is where KindleGen’s auto-conversion will fail you miserably, because it cannot make decisions like that for you. Things will, undoubtedly get even nastier when your formatting is more complex than this one very basic example, and I would not be surprised if certain elements would even disappear entirely.

Let’s face it, there are certain things the old devices simply can’t do if Amazon refuses to upgrade their firmware across the entire line of products. Just having some devices that support it and others that don’t is hackneyed at best.

As a publisher you will have to look at the lowest common denominator for your product, and that is the long-abandoned Kindle 1, that has seen little love from Amazon in recent years.

Sure, this is not a big problem if you have a novel without graphics or a special page layout. Fair enough, in that case you are really not affected by these changes at all. You will continue to build MOBI files exactly the way you did and ignore the new capabilities, because MOBI offers exactly the kind of functionality you need. Nothing wrong with that.

When books become a little more complex, that is when the problems begin and they will very quickly become exacerbated.

The bottom line — and the main point of my post — is that the way Amazon is approaching this is creating tiers of devices, each tier with different implementational limitations. And that, my friends, is a very real problem.