An Alternative to Smashwords? Draft2Digital

I am not overly thrilled with Smashwords right now. After the big announcement about EPUB, the reality has been less than… well, let us just say, I am not impressed. One, the formatting requirements are the exact same ones they use with Word files–that means generic looking books–and there is STILL NO WAY to test or even preview the converted books before they are published. As much as I get frustrated with the Kindle Previewer, it’s still a valuable tool and its error reports make sense. (Smashwords’ error reports tend to make sense only in alternate universes). When I heard about Draft2Digital, I was quite interested.

While I’ve heard from some people who’ve had good results with D2D, I haven’t tried it myself.

Paul Salvette at BB ebooks has done the legwork for us. He and his crew of wonder-formatters took part in some beta testing and have written up a useful report. Here’s an excerpt:

First Impressions with Draft2Digital

Uploading your manuscript to the newly established website, Draft2Digital seems like a perfect solution for DIY eBook conversion. Thanks to Joanna’s tutorial how to use Calibre on TeleRead, automatic conversion has gained momentum in the business when indie authors are striving to publish as cost-effectively as possible. Although we have already discussed automatic conversion before (it’s not very good quality), many of our clients have urged us to try out the closed beta test on D2D. Fortunately, an email from Draft2Digital sent yesterday notified us of the open beta of which anybody can test the service without getting the beta code. We wasted no time this morning to get our hands on their hotly anticipated conversion service. Our initial doubt prevails: how much can you trust the fast quality of artificial intelligence, especially when it comes to formulating the immortality of your eBook?

…

(Big Plus)

Hooray, It’s Pay Day!

According to the latest email, customized payment methods have been very convenient for international authors who can receive payment directly into their bank accounts or via PayPal. Look under ‘Payment’ in the Draft2Digital FAQ, authors can sign a big relief to be paid by check, PayPal, or Direct Deposit. Please note for non-’Merican authors you will need to get an ITIN so that the IRS can tax you.

Paul and his crew went through the process with… results. BB ebooks is a pro outfit, and Paul is one of the best in the biz when it comes to producing ebooks. His standards are very high. He did find some problems.

Problems Ensue with Automatic Conversion to EPUB

We tried to one of Paul’s other books that was well formatted in Word, including with a hyperlinked Table of Contents. Unfortunately, it looks as though the formatting is completely blown out when their automated conversion is used. All paragraph styles are first-line indent—which is okay for body content, but not for front matter and back matter. Additionally all first paragraphs in Chapters are first-line indent, which screams Amateur Hour. Below is how it looked:

Pop over to the site and read the entire article. Lots of illustrations and good explanations for what is happening.

My takeaway from this and from what I’ve heard and from what little bopping around I’ve done on the D2D site is that they have a lot of potential. Their terms are good, their payout schedule is excellent, and they are responsive to customer complaints and concerns.

So go read BB ebook’s article, then check out D2D. It might be suitable for you.

Boast Post: A New Way To Make Ebooks

A new way for me anyway. Not long ago I got my hands on Paul Salvette’s book, The eBook Design and Development Guide (link in the sidebar). I talked it up because it explained in plain English (mostly) the hows and whys of building a better ebook. Even though it intimidated me, I knew I had to try his method.

Well…

(Pardon my not using screenshots. I haven’t figured out how to capture screenshots off the Kindle Fire yet. The instructions I’ve seen require a little more… Anyhow.)

As per my usual knuckleheadtude, I picked for my maiden voyage a three-book omnibus. Go bold or go home, right? By the time I figured out I should have chosen an easier project, it was too late and I had no choice except to keep going forward.

This method is NOT for beginners. You need at least some experience with html and text editors. If, however, you are like me, knowing just enough to be dangerous and curious about how ebooks and ereading devices work, going through the steps to build an ebook this way will teach you plenty. I now have a much better understanding about what happens to files when they go through conversion and why some things work better than others and why some things fail.

The biggest difference between what I was doing before and what I did with this book is that before I was formatting the ebook and producing files that could be read on ereaders, but they were not complete ebooks. To make them complete they had to be run through a conversion program. What was missing on my end was a navigation guide and a toc.ncx. Ebooks, I’ve learned, have two tables of contents. The one the formatter creates while formatting and the toc.ncx which is the internal table of contents which is generated during conversion. Conversion also produces a navigation guide which is what makes, for instance, jumping from chapter to chapter possible. Why are there two tables of contents? I do not know. All I know is, I didn’t know how to make them before and I left it up to the conversion programs to do it for me. With this new (to me) method, I built my own navigation guide and toc.ncx. Now, if someone asks me to format a book that they intend to sell on their own site rather than through a distributor, I know how to do it.

What I appreciate most about Paul’s guide (other than being written in language I could understand or figure out–which often takes staring at the screen until, like magic-dot pictures, the answer slowly appears) is that he takes the time to explain what is happening and how things can go right or wrong depending upon which device the book will be read on. That’s valuable information, especially for a non-programmer. I spend a lot of time over on the w3schools.com site seeking answers to my problems, but what’s over there is geared for programmers and people who have skills and experiences that are foreign territory for me. Which means I do a lot of, “hmn, let’s try this and see what happens,” and sometimes I get the desired results and sometimes I don’t. When I can’t get the results I want, it’s a bear figuring out why. I also learned I’ve been making some parts of my formatting tasks overly complicated and much too hard.

As a bonus, on his website, BB eBooks, Paul has an area for developers with templates and guides. It’s a terrific resource.

If you’re like me, you know how to format an ebook, know some html, are comfortable working in a text editor and now you’re ready to kick it up a notch, the guide will take you through the process step-by-step. I recommend you read the entire book first so you get the overall picture of what it is you’re about to attempt. I took a lot of notes and used my whiteboard to help me keep track of such things as bookmarking navigation points and naming files. Since this method involves splitting up the main file into many smaller files, you will need to find a solid, simple way to name the files and keep track of them.

One area where I had serious trouble was in making the zip file. I could not get the recommended program to synch with my computer. That’s not the guide’s fault (I need to get my son over here to figure out why my computer disallows changing directories). So I cheated and copied my files into a .zip folder then changed the .zip designation to .epub. I don’t know if you’re supposed to do that, but it worked. I’m not comfortable with it because my computer sends me nasty grams when I do, but it did work.

Because I was building a book for the Kindle, I had to disregard some of the advice about line spacing. In the most recent update that Amazon did for Kindle devices, they changed the default font and apparently the line spacing and paragraph spacing defaults, too. I’ve noticed in some of the recent stories I’ve downloaded the text appears double-spaced and changing the line spacing on my Kindle takes it down, at the most, to a space and a half between lines. Plus, where before some extra leading between paragraphs made them look better, now the extra leading puts a noticeable gap between paragraphs. I don’t think that is happening on Nooks or other EPUB readers. It didn’t appear to be a problem on Calibre. So pay attention to line spacing when you’re building a book for the Kindle. Things have changed.

I also refrained from reducing the font size anywhere in the book because I don’t know if Amazon fixed the bug that squishes the font in older Kindles. Until I’m sure of that, no font reductions for Kindle.

Some of the touches I did for this book included moving the copyright page and table of contents to the back of the book so potential buyers can get a larger sample. Plus, because it’s a three-book omnibus, I placed a header at the beginning of each chapter with the title of individual book. Just to keep readers reminded of which book they are reading.

I love the way the book turned out. Despite being intimidated by the process, I learned some skills, gained a whole lot of understanding and ended up with a very nice looking ebook that is easy for readers to navigate. (I also learned some new cuss words, but I won’t go into that…)

Thank you, Paul.

If you want to check out my latest masterpiece, and some pretty good stories, too, it’s available now on Amazon.

 

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.

It doesn’t help that I read Baldur Bjarnason’s latest post at Futurebook. This part worsened my mood:

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.

Oh My God, I’m a Nerd!

Long time readers of this blog have watched my progression from building ebooks in Word to the present day as I’m handcoding html. You’ve heard me whine about the quality of ebooks and the difficulty of producing a book that renders perfectly on every device, every time. I’ve used different programs, different methods–and for the longest time I utterly resisted learning html because 1) I knew nothing about it; and 2) I resented the idea that one had to be some kind of mad genius-computer nerd in order to make a decent ebook.

Well. I was wrong. It doesn’t matter that I knew nothing about html. If one is motivated, one can learn. Plus, one doesn’t need to be a mad genius (or even a slightly bent genius) in order to learn basic coding–which is really all one needs in order to make a beautiful ebook.

One does have to be, however, a bit of a nerd. I realized this the other day when I announced to the old man, “Ha! Regex isn’t so hard and toggling the extended command means I can wrap paragraphs and find extra spaces as easily in the editor as I can in Word. Bwahahaha!”

Do you understand what I just said? Don’t worry. The old man didn’t either. A month ago I wouldn’t have understood it. Suffice to say, I’m learning a whole new language and it is finally making sense to me even though that means my family now looks at me the same way the dog does when I’m talking to him (he’s waiting for me to say the magic words–”walkies” or “cookies”).

But, I haven’t done all this alone. Every time one of you guys, blog readers, makes a comment about a new way of doing something or talks about a new program, I have to check it out. And I learn things. When I’m working, I have a screen open to the W3Schools website so I can quickly get questions answered. I’m always bopping around the ‘net, seeing how others have solved problems and seeing if they’ve learned something new. I don’t always (okay fine, most of the time) understand what others are talking about. The real experts have been doing computer programming for decades and they speak “html” with casual fluency while I’m over here speaking very loudly and very slowly and adding vowels to the ends of every word in an effort to make myself understood (I said-o no comprehendo, capiche-o, amigo?).

Needless to say, when I do find a reference source that a) tells me what I need to know; b) shows me what I’m doing wrong and how to fix it; and c) is written in a way that I can actually understand, I glom onto it.

All that build-up and confession leads to sharing a new treasure: The eBook Design and Development Guide by Paul Salvette. Paul follows this blog and comments occasionally. He also has an ebook formatting service. He gave me a head’s up about the book. There were two major factors in my decision to buy it. First it was written in comprehensive English (most of these types of guides offend my writerly sensibilities) and second (this is really important!) it’s nicely formatted (it’s astonishing how many how-to-format-your-ebook guides are so wretchedly formatted as to be unreadable).

This is not a beginner’s guide. Two months ago I wouldn’t have understood much beyond “and” and “the.” With my usual la-di-dah methods of clicking madly until something works, I learned enough of the basics of html on my own to create some very nice ebooks. Armed with those basics, I’m able to understand quite a bit of what Paul is talking about. It helps that he truly cares about how ebooks look and that they work properly on ereading devices, no matter what those devices might be. It also helps that the book is readable, with an engaging style, and only occasionally lapsing into nerd-speak that leaves me smiling, nodding and waiting for him to say “walkies” and “cookies.”

I read it in one sitting, bookmarking countless passages and taking notes with my analogue word processor. I figured out some areas where I am working way too hard to accomplish simple tasks, and making some mistakes which I had to work even harder to overcome and compensate for. Of course I had to run to the computer and try some new things.  I formatted two ebooks using his guidelines and had so much fun, I reformatted another book that happened to be more complicated just to see if I could. I could. I did! I understand a bit more about how ebooks work and some of the differences between the different platforms and why versions of html coding work better on some platforms than with others.

The book is easy to navigate (a most useful table of contents written in plain English) and it includes templates for xhtml address thingies and resets and style sheets. Handy-dandy and easy to use.

Paul, being a generous fellow, generously (foolishly) opened himself up to answering whatever stupid questions I might throw his way. He might be sorry about the offer, but I won’t be. One book doesn’t make me an expert and it sure doesn’t catch me up on twenty years of experience, but it does go a long way toward helping me reach my goal of producing beautiful ebooks.

Highly recommended for nerds-in-training.