eBook publishing diary – part #1: The story so far

Screwproof - doing deals that won't f*ck up

new book… out now?

The story so far…

We join our intrepid hero (me, obviously) as he is about to self-publish his first ebook “Screwproof – doing deals that won’t f*ck-up”. But before we get onto the publishing process, here’s a recap of the writing process thus far. Needless to say, it’s not a simple as it looks, in some respects simpler, in others, way more complex. For a start, calling it “self-publishing” is a bit of a red herring. Yes, you are using self service tools to publish, but they are all different, require a good deal of effort and have a learning curve. The end result is hard to get right, but the term “self-publish” makes it sound a bit like “save as” and it’s not. It’s more like building a website, hosting it, setting up the server yourself and so on. It’s not simple, but it’s not hard.

That said, writing the book is the easy bit…

Writing the book:

No kidding, this really was the easy bit. Don’t let that put you off. It was also the longest bit and in many respects the most painful bit because you’re confronted with all the emotions and complexity of turning your ideas into a story. The difference between wanting to write a book, and actually writing it, is a bit like the difference between feeling horny and actually going out, meeting someone, forming a relationship and eventually, having sex with them. I wrote it between November 2012 and June 2013. It took a while as it had to fit around other projects. But when it was done, I sent it out to a few selected buddies to read and give me their feedback. The general response was the book was way too long, featured way too many examples and was too wordy.

 

Rewriting the book

After a couple of months of editing, I redrafted the whole thing between September and November 2013. The net result was something half the length, much easier to read, with a much clearer proposition. The readers like it much better. Then the hard bit started, self-editing. Although it was definitely working harder, not smarter, this task also enabled me to work on my own writing process. Like with the rest of the self publishing process, doing it wrong is a great way to learn about how to do it right next time.

My first attempt was a brain dump. Some of it worked well, some of it was mushy. For a non-fiction book, I think this showed me how I could work smarter. There’s two challenges with that kind of writing, one is getting down the really juicy content, the other is making it flow with a narrative and a tone of voice that gives the book its flavour. Those things don’t have to happen at the same time, in fact, arguably they can’t. My problem was, trying to do both at once had created a monster. In the rewrite, I could identify the core content items and wrap them in a narrative, and filter out the redundant side points. They can be re-used in the follow-up book (which is another story…)

 

Pre-production #1: Corrections

Wanting to get under the skin of the end to end process, I opted to edit the whole thing myself. Which was a mistake. Endlessly reading your own words is fairly pointless, you develop error blindness and lose the capacity to follow the narrative. I would’t recommend it. After about a month of burning my eyeballs with my own word salad, I decided it was edited. It wasn’t. However, as with the process of writing, I realised in retrospect I could have done this basic level editing smarter as well.

The fix is simple – firstly, edit yourself as you go along for errors, it’s easier to proof a couple of pages then a whole chapter, so a regular coffee-edit session at the end of each writing day would fix a lot of the fat fingered mistakes. For the bigger editorial issues, having a set of golden rules that define the limits of where your writing will go at the outset is essential. For me that would be no real names / no real places / no more than two case studies per chapter / one example per point made is enough.

 

Pre-production #2: Proofing/editing

I sent out final proofs to my readers, they loved the book, some returned lists of errors, others didn’t spot them. Then one guy (who became my editor, a publishing professional) sent me a document with all the errors, advice on how to anonymise elements of the book to keep me out of libel court, notes on the formatting etc. Pure gold. It took me about two days to fix the whole thing, and rewrite the sections where I’d been a little too honest about using people’s real names or describing real scenarios.

Keeping the meaning of a real world example but disguising the actual people and places is harder than you think it might be. However you can do it if you remember this advice from Bill, my editor (paraphrased)

you need to get to a point where your lawyer could argue that in order to press a libel case, the person claiming libel can only be recognised by the act of claiming libel in the first place.  If asserting they are the person you have written about underpins their cause for taking legal action, it also means if they hadn’t said “that is me” nobody would have known who you were talking about.  That’s a legal argument that ends  libel actions before they even get to court.”

I invented names for the companies I had mentioned (“Evilcorp” and “Nastycorp”) blended multiple people into one, and vice versa. I shaped the scenarios to take the same point (from two or more companies I’d experienced that kind of problem with) and create a new example. Same point, real problem, real solution, but no real people or companies mentioned. It’s all talking about real events, but the specific events I talk about don’t have to be real, if you see what I mean.

To put that another way, yes, I got screwed by someone (person x) at a company (company a) that had very aggressive practices, and encouraged their staff to screw over independent contractors. The same thing happened with person y at company b, too. In my book, that becomes one event, a person called “Sanders” who works for a company called “Nastycorp”. That way I can explore the issues without naming names, but you can’t explore the issues without any names at all, otherwise the example lacks a practical, honest perspective and sounds like pure theory – and it’s not a pure theory kind of book.

 

Production #1: ebook authoring

I authored the whole thing into xhtml (using Guido Henkel’s excellent guide) and Textmate. It is a great way to ‘get under the hood’ of the layout mechanics of an ebook. I began testing on multiple devices (Kindle Paperwhite, iPhone Kindle App, iPad Kindle app) which showed me how limited your layout options are, and how trying to do anything fancy with headings, sub-headings or page breaks is basically pointless because font sizes, pagination, breaks etc. are so disrupted by the device and the user preferences that you can’t make the damn thing flexible enough to display properly unless it’s really simple.

You could try to force someone’s device to behave a certain way, by fixing fonts and sizes, but that never works. The whole point of e-readers is the user defined experience, removing that alienates the reader from their device – it puts up a barrier. I found the whole process was a lot like web design in the mid-1990s, it had to be one set of code that worked across multiple platforms and browsers, so I had some experience of the problem and intuitively leaned towards a simple solution. When you come to compile your book, though, it makes a huge difference to have authored the xhtml yourself and understand how you’ve structured it. Search, replace, adjustments, table of contents… it all relies on a sound working knowledge of your own code.

 

Production #2: Cover design

Designed the cover. Then redesigned it. And again. Reached a point where I had no idea whether I was going in the right direction, so I used the Jelly app on my iPhone to ping out a couple of options and get some crowd-sourced feedback. The feedback was very useful. As far as colours went, it was 50:50, but the layouts and legibility issues gave me a clear winner. So I reworked the cover again. It was useful and now I’ll work with that design in mind for all my covers. 1) Banner and teaser copy at the top – to draw readers eyes down the cover 2) Title in the centre panel 3) banner and teaser 2 at the footer 4) Adjust all the type so it’s legible at a thumbnail size – which favours high contrast, light text on dark background.

 

Production #3: Compiling into formats

Firstly, for .epub & .mobi you’re best off using Calibre. It’s easy to use, produces nice clean code, very useful. However it’s dreadful for making PDFs. For the PDF, I used my text editor, Scrivener. Much simpler and more flexible. Although Calibre is great, it takes some working out – especially with little tweaks like margins and levels of detail for the table of contents. On that front, having well formed xhtml styles is essential in your ebook code, because Calibre reads the tags to work out how to build the table of contents, so it they’re inconsistent, the TOC won’t work properly. Mine was refreshingly reliable because I’d slaved over the code earlier on. Well worth the effort. I tested the final versions, everything was working as intended.

 

The story continues…

At this point, you think the hard part is over. In terms of time and effort, there’s not much left to do… just publish it and get on with marketing it. Yeah. Er… no. Having all your ducks in a row is one thing, getting them to fly south for the winter and survive the hunters, hawks, storms and fatigue to get to their feeding grounds is quite another.

Tomorrow, I’ll be posting the next instalment – getting it onto Kindle, Smashwords and working how how to sell my PDF version. That’s a whole new chapter.

Part #2: 10 tips for publishing day