Are Ebooks Getting Too Complicated For DIY?

I’m a tad out of sorts this morning. Irked, annoyed, disgruntled… Pick one.

Partly it is because of anxiety. I used Paul Salvette’s guide to create my very first complete ebook (one that doesn’t have to go through a third-party conversion process). Now the author is waiting for it to be published on Amazon. I hate the waiting…

Partly it’s because my son gave me a Kindle Fire for my birthday. Oh, wow, is that thing cool. It’s not something I’d have bought for myself. I’m not a gadget person and it takes me forever to warm up to anything new. But wow, the Fire is very cool. The first thing I did was load the book I just finished onto the Fire to see how it looked. It looks gorgeous. It also looks a lot different than on Larry the Kindle.

I looked at other ebooks in my library. I have books put out by big publishers and indie books, and books that were professionally formatted and books that were DIY. Quality is all over the board. Some of the books that look just fine on Larry look amateurish and not-quite-right on the Fire. It’s because many of the books were produced before the Fire existed. The older formatting platform doesn’t translate so well. The standards are different.

The ebooks are readable. I’m not going to pitch a bitch just because a book I purchased last year won’t let me adjust fonts on the Fire. Nor am I going to ping DIY publishers who’ve formatted a Word file according to Amazon’s guidelines and ended up with an amateurish looking ebook.

I’m irked and annoyed at the devices and the platforms and distributors. Quite frankly, this shit has gotten way too complicated.

However, as I’ve written about before, a large proportion of ebooks published are rubbish. Not in terms of the content (although that’s probably also the case) but in terms of the quality of the file. Ereader platform vendors cannot support the full range of CSS that EPUB2 and EPUB3 require because a substantial number of their catalogue would become unreadable.

Platform vendors are in a position where they couldn’t support standards completely even if they wanted to.

No kidding. For instance, while I was building my most recent project, this is what I had to do. Build the file. Launch the file in my web browser. See how it looks. Figure out why something doesn’t look the way I wanted it to look (All the while knowing that what appears in my browser is only an approximation of what will appear on the ereader). Fix and fiddle, then validate the file to make sure it meets EPUB standards. Check how it looks in Calibre (I don’t have a device that reads EPUB). Again, I know that what I see on my computer screen is not necessarily what a reader will see on a Nook or iPad or whatever. Then, I convert the file into MOBI format and load it onto my Kindle. Do more tweaking. Tweaking and fiddling means having to go through validation again. It means more converting and loading and inspecting. And I haven’t even gone through the Kindle Previewer yet. I want to know how my ebook looks on as many devices as possible. I change font sizes and line spacing and the size of the reading window. It’s time-consuming, it’s frustrating, but the worst part is that even though I’m checking and double-checking with everything I have on hand, it’s still not enough. There is no guarantee that an ebook that renders perfectly on Larry the Kindle (and now the Fire) is going to render properly on other Kindle styles or versions, the Nook, the iPad, the iPhone, an Android, a Sony, a whatever.

As the cat sez:

This is, in a nutshell, a disservice to readers. READERS. Do you hear me Amazon? Barnes & Noble? Kobo? Smashwords? Apple? While you guys indulge in device wars and competing formats while creating compatibility issues, are you thinking about readers at all? You know, the people paying the bills? It’s all well and good to roll out the welcome mat to publishers big and small, traditional and indie, and invite all comers to list their ebooks with you. You get your percentage of sales. When your guidelines and standards are such that it is very, very easy for anybody to make a crappy looking ebook, naturally people are going to follow your guidelines to the letter and end up with crappy looking ebooks.

That’s not right. It’s not fair to readers.

It’s difficult making an ebook that renders properly across all devices. For the self-publisher who has neither the time nor the inclination to learn all ins and outs of formatting to meet different standards, it’s damned near impossible.

That’s unfair to the do-it-yourselfer. It’s unfair to their readers.

What’s the solution? I do not know. I’m not a programmer or a tech-type. I have no idea what goes into creating these devices or how they work. I just want ebooks that respect the material and are a pleasure to read. That is not too much to ask. All this screwing around with fancier devices and increasingly complicated and narrow platforms is making it too damned hard.

I’m a believer! I agree it doesn’t help to release new and improved e-readers, engage in an e-reader war, if you can’t provide a quality reading experience. It’s like cutting off your nose to spite your face.

It really is, Julia. This nonsense can very much hurt do-it-yourselfers. As device-delight wears off, readers will get pickier and start demanding higher quality. If producers aren’t able to meet quality demands, returns will increase and sales will go down.

Did you see the WhisperCast announcement from Amazon today? They just gave us a big chunk of the solution for the testing issue. WhisperCast is designed to allow organizations to blast content out to devices they own (or devices that their students or employees use).

Right now, you can only send content to devices purchased from a single Amazon account, but soon you can let people “join” your organization. Anyway, it appears that this will be a great way to blast a prepublication Kindle file to all the various Kindles to see how it looks. No need to sideload, worry about the stupid conversion that happens with the email to Kindle thing, etc. I’m currently testing this out with the Kindle Fires that I bought for my sons. Sadly, I can’t get it to work with my own Kindle Keyboard because I bought it at Best Buy.

Anyway, as soon as I prove that this works effectively, I am seriously thinking about setting up a full-fledged test lab. Hmmm… I don’t think it is a violation of the terms of service if I’m sending content to devices that I own and charge folks for the service of examining the files. I think I have another service to offer…

I had the same thought when I read that, William. Of course, I only have two devices right now. I’ll soon have three. What I really need is a Nook and an Android and a smart phone and an iPad and and and and… It’s insanity, I tell you. And quite frankly, I do not trust either Calibre or the Kindle Previewer. Keep me posted about your testing service.

While I agree that we, as writers and formatters, have no control over how the various devices render e-books, we can do our utmost to format our work to the standard. Sadly, we must rely on the device developers to implement those standards fully. The ePub 3 standard looks like it will be truly wonderful, but, again, the device developers must do their part. These developers would do a great service to all the formatters out there if they would share the degree to which they’ve implemented the standards in a clear, easy-to-find manner.

If this all makes sense, that is.

(Please forgive any typos; I’m just 7 days post-surgery for carpal tunnel surgery and it’s still hard to type one-handed [for the most part].)

But, to answer your journal title’s question: No, e-books are not getting too complicated for DIY publishing. Follow the standards; they’ll get you through. The real issue is in getting the plethora of e-readers to render to the standards! In my opinion. ;)

Jon,
Which standards would those be? There are no standards worthy of the name in the ebook industry. Standards are only standards when conforming implementations exist. EPUB 3 is a joke. It delegates critical behavior to other standards (like HTML 5) but doesn’t even tell you which version to use. I don’t think device makers could build a conforming implementation if they tried, but none of them are even trying. EPUB 2 is slightly better, but only because it is less ambitious. There is no way to create an EPUB 2 book that tests all parts of the standard and works across the major platforms.

The Amazon world is even worse. I personally own 6 different devices that implement KF8 in different ways (Kindle 3rd Gen, Kindle 4th Gen, Kindle Fire, Kindle for PC, Kindle iPhone, Kindle iPad). If you want have real fun, try to build a fixed layout ebook that works across those platforms. But even the simple stuff behaves differently in the most unexpected ways.

No, following standards is useless. We are all stuck in the build, deploy, and test on a dozen or more different platforms. It is insane.

You must forgive my ignorance. I’m relatively new to the e-book formatting game. My understanding of the way things work, from what I can glean from your note, is woefully underdeveloped.

I knew that Amazon went one direction with its e-readers while most other companies embraced the ePub format. I am frankly stunned to find that Amazon implerments KF8 rendering in such varying degrees of accuracy or commonality. It makes me even less interested in Amazon’s e-reader products.

However, your example of having “real fun” by trying to create a fixed layout e-book seems like trying to use the e-book platform for something it’s not designed to do. The beauty of e-books is that they feature reflowable text. Yes, this makes it very difficult to present tabular data, for example, but, to me, this is making the e-book behave against its nature.

My understanding of the e-reader renderers is that they are based upon the renderers used for web browsers. For years, it was necessary for website developers to include special workarounds for Internet Explorer-based misconceptions of how HTML and/or CSS should be rendered. But, outside of a few gotchas, mainly for older versions of IE, things rendered correctly across many different platforms and renderers. Why should things have taken a step back for e-rendering devices?

And I must humbly disagree with you that it is useless to follow standards. Following standards is what will get an e-book developer as close as possible to having one main source file that can be used to generate specific formats.

Hi, Jon and William. I think you guys are talking about two different things. Jon, you mean the standard for the finished product–consistent, readable, laid out in a linear fashion–while William is talking about the standards for production.

Right now the lack of standards for production are missing, making it difficult for anyone to reach the standard of quality for a finished book.

Example, last night I loaded a short story onto the Fire. The font was Helvetica. I personally cannot stand reading a sans serif font for any length of time. But when I tried to change the font, nothing happened. It remained Helvetica. I loaded it onto Larry. The font was fine–the default serif font that Kindle eink is using now. The story format met the standard as far as layout was concerned, but something happened during production. Ebook production standards allow for font and font size changes from the default. All the devices handle them differently.

Ideally, it should be that a producer does A, then B, then C, adhering to a standard of production, and voila! An ebook that renders well across all devices. Only that doesn’t happen. What happens is that it renders well on SOME devices, while other devices are stuck with Helvetica font or squished text or mashed paragraphs or gaping paragraphs or no page breaks and on and on. THERE IS NO WAY FOR THE PRODUCER TO KNOW. (Unless they have access to every single reading device out there).

And that’s where my frustration lies. I set out on this journey of learning to format ebooks with the goal in mind that even I, non-techie, can produce a beautiful ebook without having to be a computer programmer. True DIY with no special skills or training or expensive programs. I keep learning the hard way that might not be an achievable goal.

I kind of wonder if the problem or part of the problem is that the developers aren’t book readers–or at least, sensitive book readers. So instead of opening up the potential and possibilities, the general attitude is, make it plain and generic and leave the fancy stuff for game developers.

Can you imagine the outcry if manufacturers of DVD players said to customers, “Oh yeah, our Sony dvd player gives you the best sound quality for your movies as long as your movie is formatted specifically for our Sony players. Otherwise, you might not hear the C notes on the sound tracks. And you can’t play anything formatted for Mitsubishi.”

Jaye, that has always happened with cutting edge technologies. There was the huge battle between Beta and VHS. Between VHS and DVD. Between DVD and Divx. Between rotary dialing and tone dialing. Between telegraph and Pony Express. ;)

It is my hope that, eventually, there will be a faithful implementation of an e-book rendering standard.

My rotary phone still works – even though it has only two wires to the connector – on our regular four-wire touchtone house phone service. I was amazed – and pleased. That thing is STURDY – bought it back in 1980 or so when the phone company had to let people buy their own phones – Sears, $25. White.

So: plain vanilla should continue to work – but then where’s the beauty?

I find a huge variation in the readability of PRINT books, even those that are text-only. And they were ‘professionally designed’ and typeset and laid out. Huge differences in font, size, spacing, white space around the page, and even weight (pale grey lines are very hard to read).

No standards whatsoever.

Websites and blogs are just as bad: I have taken to selecting the Basic Page Style (Firefox – plain rendering) on more and more sites – can’t read ‘em. And that’s after you remove the flashy stuff with Flash blockers and Ad blockers.

It would be nice if ereaders let me choose how I want to SEE the text. I don’t have one yet – but Kindle for Mac has shown me so many styles already my head spins.

In printed books the reader has no choices (except cracking the darn spine so you can see the text in the gutter). In ebooks we ought to have some.

I think the reason that eBook standards are so poor is that the Amazons and Apples of the world don’t really take this stuff very seriously. For web design on the open source side, there are tremendous resources like the Mozilla Developer Network, and for programming in open source languages like Python, there are sites like Stack Overflow where people can share knowledge. Even non open source platforms like Twitter and Facebook have pretty good API features and support for geeks who want to integrate these sites in to apps. Unfortunately for eReading software, there is very little support or technical documentation for developers. The EPUB3 specification has its ups and downs: the good is that it will enable interactivity through JavaScript support, and the bad is that the metadata standard is overly complex and contradicts itself at times. Although, the big boys are making almost no effort to adopt any of the useful parts of the EPUB3 specification. So, that’s all EPUB3 is right now…a specification, and it’s not being implemented anywhere where people sell eBooks.

Jaye is right that this stinks for readers and authors. If eReading software was more open source, or at least documented, then programmers could create apps to generate functional eBooks that looked acceptable on the various platforms. Independent authors could use that software to create simple eBooks, and more complex eBooks would probably need to get into the actually nitty gritty of HTML/CSS/XML. For websites, this is the current paradigm: casual users can use WYSIWYG programs like WordPress to make a decent website, and if they want to get complicated they can delve down into the actual code. For eBooks you have the option of creating a crummy eBook by running a word document through a “magical” conversion program that rarely works (especially for the Table of Contents) or you have to really get into the hardcore HTML/CSS/XML side of the equation, preferably with an understanding of regular expressions and writing script in a high level programming language. There really isn’t very good middle ground.

Oh yeah, and the lack of conforming standards, as William mentioned, doesn’t help things either.

I’ve just reread your entry here, and I must admit that I’m very confused by Mr. BJarnason’s assertion that e-reader developers cannot improve their support for ePub 2 and/CSS because “a substantial number of their catalogue would become unreadable.”

I call bullshit!

That’s like saying roads can’t be improved because older cars would burst into flames the moment they touched them.

How would a better implementation of a rendering engine render older files unreadable? How? How is this even logical? Newer browsers do not break old websites. It’s the same analogy.

I’m going to have to read Mr. Bjarnason’s article in total now. Something is not right here.

Actually Baldur is exactly right. In the trad pub workflow, ebooks are an afterthought. They put out books that are so broken that the device makers break the rules of the standards to make those books readable. That is why building to standards doesn’t work.

Hi, Marie. Validation means the file will work on ereaders, that is uses the proper coding and that it has a proper toc.ncx (internal table of contents) that will work with various ereaders for navigation.