What the "nav.toc" is this?

By Keith McDowell

Am I angry, frustrated, flummoxed and depressed? You bet! And it’s all due to my self-publishing experience at Amazon with their Kindle Direct Publishing (KDP) platform. I’ve been run over by an innovation engine driven by a pack of technology geeks who are directed by some apparently clueless managers lacking good business sense.

Harsh words? Undoubtedly! But you don’t kill the geese – namely, ebook authors – who lay the golden eggs simply to advance technology for profit under the guise of being more “end-user friendly.” Whatever happened to “content-creator friendly” and the important business concept of “self-publishing?”

Don’t get me wrong! I’m a strong proponent of end-user friendly for created electronic content across all devices whether a computer, a tablet, or a smart phone. But does it have to be so “nav.toc” complicated for the content creators, especially those who want to self-publish ebooks? Here’s my story.

Several years ago, I wrote and self-published with Amazon an ebook entitled Go Forth And Innovate! and followed that up last year with a genealogy ebook entitled Together  Forever. Initially, it took me several months in late 2010 to understand what kind of file was required for upload to Amazon and how to markup that file with appropriate HTML tags. I’ll get to the format of JPEG images in a minute.

You have to know that I cut my teeth writing machine language and Fortran II code beginning in 1964 and have produced probably a million lines of code in my lifetime including a very complicated web system that produced over 300 different types of freshman chemistry questions. It ran for over five years from 1997 to 2003 and was widely used by both college and high school students to practice for chemistry tests. Needless to say, I became a Javascript and HTML guru after spending about 600 hours writing approximately 30,000 lines of code. But then, I had to prove to my sons that the old man could still function as a programmer in the Internet age.

So, imagine my surprise in 2010 when I discovered that formatting the code for a Kindle ebook was primitive HTML at best and poorly documented on the Kindle website. Of course, the original Kindle reader itself was the leading edge in the market of ebook readers as a standalone device and one could forgive Amazon management for not seeing the future. Nevertheless, I accepted the situation and was pleased that producing ebook files in native HTML wasn’t very hard to do.

Fast forward to last Friday as I sat before my computer prepared for a login to KDP to begin the process of uploading my latest two ebooks. One is a novel set in the Civil War period that is based on the factual history of some of my ancestors from the Stoner and Morgan families of Rowan County, North Carolina. It’s my attempt to define what they were really like as people. The second book is a massive genealogy tomb on the Stoner family and intended as the non-fiction companion to the novel. It took me two years to produce the content in these books including a fastidious compliance with the primitive HTML rules imposed by the rendering software at Amazon circa 2010 and 2011.

Imagine my horror last Friday when I realized that the new Kindle Previewer which apparently uses something called KindleGen to render the ebook from an HTML file now requires HTML 5 and Cascading Style Sheets unless one wants a crap presentation format for your ebook’s contents. In one step, we go from the primitive to the bleeding edge of technology.

After walking a few miles in my shoes on Friday afternoon, I visited the local bookstore on Saturday and purchased a sufficiently thick and weighty HTML 5 bible to serve as a bookend for my previous collection of HTML and Javascript bibles documenting earlier versions. I’m now past page 100 on my way to page 1017.  Somewhere after page 200 I’ll hopefully learn about the new “nav” element that’s essential for making the table of contents functionality – that’s TOC to the heathens among us – in ebook readers work properly. I certainly want those who purchase my ebooks to “Go To” TOC when their hearts or minds so desire.

Am I right to be mad about this? Well, yes! And let me explain why by giving several examples.

Back in the good ole days of the early to mid 1970s, IBM produced a mainframe computer known as the 360-series. Like many practicing theoretical chemical physicists of that era, I wrote Fortran IV code and ran on those computers using their Job Control Language (JCL). Just for the fun of it one day, when several fellow graduate students and I were all bored with reviewing hexadecimal numbers from our core dumps, we attempted to communicate with each other using only JCL. That didn’t last very long, but here’s the point. Hypothetically, if you wanted to understand how the delimiter “blocksize” worked, you looked it up in manual number 87 which pointed you to two other manuals. After an hour of such navigation through the manuals, guess what? You were back at the original definition of “blocksize” having learned very little. IBM manuals of that era were a beautiful example of a self-referential system. I always suspected that there were precisely 128 manuals in the long row of them since that number equals the number 2 raised to the 7^th power – 7 being a mystical number throughout history.

So what did Amazon do with their giant leap forward for ebooks? They created a Kindle Publishing Guidelines document that is mostly worthless, not really usable, and creates confusion. Of course, there is also a guide for the Previewer that is quite long and then, my favorite, hyperlinks to technical specifications and documents on the Web. Shades of the 128 IBM self-referential manuals! I went to the links about the navigation element and TOC. I can only assume that there is a sinister conspiracy going on between major publishing houses and Amazon to eliminate self-publishing if their best answer for help is to link one to these documents. Even a confirmed computer jock like me can only cry: what the “nav.toc?”

And how about JPEG images? Come on guys! Give us some simple information. I start with an image that has a fixed length-to-width ratio. I open it with Photoshop and increase the image size until either the length or the width hits the maximum permitted by the KindleGen rendering software. I save the image in the web format to reduce size and work to achieve maximum quality. At that point, either the image is worthy of publication or it looks too fuzzy or whatever. End of story. So, please tell me a maximum length and maximum width criterion along with maximum size permitted for the JPEG file and we’re done.

As all competent computer jocks know, less is almost always more. Simplicity is always the correct answer – unless you’re some creative artist who wants a finely tuned ebook. I’m happy for you if that’s the case, but how many people actually use all the bizzillion features in Microsoft Word? I’m absolutely sure that by the time I read all the new Amazon verbiage and get to page 1017 in my new HTML 5 bible, I’ll have constructed a simple template in which to imbed an ebook that will satisfy most circumstances with minimum tinkering required. It’s always that way. But I’ll put a “nav.toc” amount of effort into getting there and reformatting my two ebook files. So why can’t the folks at Amazon provide everyone with that simple bulletproof template to begin with?

I truly feel sorry for the average self-publishing ebook author. For now, you’re screwed. It doesn’t have to be this way. As a society and especially as one that has endured many technology transformations, we know how to do these things right. It’s not a mystery and we don’t have to invoke the mystical “seven” to get it done.

So stay tuned! You’ll soon be able to enjoy reading my salacious novel Never To Return on your iPhone but do you really want to plow through my genealogy ebook on that device?