Part 1 of this self-publishing case study covered planning an ebook project. In part 2 we looked at marketing an ebook project, and here, in part 3, you’ll learn how I set about creating a Kindle ebook – Berlie Doherty’s novel Rose Doran Dreams.
This self-publishing case study isn’t intended as a definitive guide to ‘creating an ebook’ or ‘marketing an ebook’. After all, there are countless websites, books and courses devoted to both of these things, many of them created by people who do this sort of thing day in, day out.
The intention is rather to give you – the would-be self-publisher – a general overview of how WE created this ONE PARTICULAR EBOOK.
Hopefully you’ll still learn something from it, even if only how not to tackle a certain aspect of the process.
Let’s get going!
Creating a Kindle ebook – the stages
Realising Rose Doran Dreams as a Kindle ebook involved three stages. These ran concurrently, but to provide a clearer overview in this case study, I’ve grouped them into related areas:
- Finalising and formatting the text
- Designing the ebook cover
- Creating an EPUB ebook and from that, a Kindle ebook
A novel wouldn’t be much of a novel without text.
During the period in which I would be preparing the ebook, Berlie’s advance readers would need to be reading the text. That way, if any of them were disposed towards leaving a review on the Amazon store, they would be able to do so shortly after the book’s release date. They wouldn’t have to wait until the book was available, and then read it. This would send a positive signal to Amazon’s algorithms, who may then in turn be inclined to increase Rose Doran Dreams’ visibility on the platform.
Berlie had forewarned me she’d had difficulty with some of the paragraph formatting, which was fine, as I could take care of it. Other than that, the text submitted to me would be the final, final text, free of errors.
Some typesetters and people who create ebooks only want to receive perfect text, and charge extra for any formatting that may be required. But I’m happy to deal with formatting. From experience, writers may be good at writing, but it doesn’t automatically follow that they’re good at formatting, let alone have an appreciation for, and understanding of, typography. Formatting is therefore already included in my prices.
However, for one reason or another, things didn’t quite work out like that.
Over the coming days and weeks, the occasional typo would make itself known to me, Berlie or the advance readers, and Berlie and the advance readers would be requesting stylistic changes.
Interestingly, many of the advance readers, if not most of them, spotted typos and general mistakes. Although some errors were found by more than one person, most people seemed to find completely different ones. This shows both the benefits and drawbacks of the ‘beta reader’ approach. The herd as a whole was able to detect the majority of problems, but individually, none of the readers found anything like all of them.
Key lesson for me
Don’t start a book project if the text hasn’t been checked thoroughly by at least one person other than the author.
Some self-published authors see editing/proofreading (which are two different things, by the way!) as almost optional extras. But the truth is: even the very best writer, in terms of thinking up stories and developing characters and plots etc, isn’t necessarily the very best person for grammar, checking spellings and facts or for spelling words consistently (including capitalisation and hyphenation).
So if you’re about to self-publish a book, please, please, get your manuscript checked by someone who isn’t you. If you’ve been working on it more or less daily for however many months, it really would benefit from the input of at least one fresh pair of eyes!
Creating the master text file
The first task was to create a master text file.
Time was short, as the advance readers needed the book’s text, and I had not yet started creating the ebook. I therefore needed to get the text to the point where it could be split into two ‘branches’ – one for the advance readers’ PDF and one that I would transform into an EPUB, and from that, into the Kindle format for sale on the Amazon store.
We could have theoretically password-protected the PDF for the advance readers, but decided against it. They were hopefully honest advance readers, and as they would be doing us a favour, we wanted to make the process as easy for them as possible. Plus: if someone was inclined to circulate a PDF illegally, there are ways to circumvent the password protection.
The importance of stylesheets
When creating ebooks, it’s crucial that every single bit of the text has a stylesheet applied to it. Otherwise, things will go wrong.
In my experience, hardly any authors or journalists seem to use stylesheets, or at least not consistently. I’ve no idea why this is, as half an hour spent learning how to use stylesheets would save them hours/days/weeks of time over the course of their careers!
Berlie’s text for Rose Doran Dreams was generally OK in this respect. Most of the text had stylesheets applied. But absolutely all text has to be controlled by stylesheets. And I still had to go through the whole thing anyway, to deal with double spaces, ensure ellipses were ellipses and take care of all the other typographical niceties.
(Some people find this sort of thing incredibly boring, but with music blasting out as I work, I find it easy to get into the rhythm (ha!) of things.)
As Berlie had warned me of formatting problems, I also kept a lookout for those. The main problems were that the first lines of paragraphs had different depths of inset, and that changes of scene within chapters had different amounts of line spacing between them. (This is where the consistent use of stylesheets would have helped enormously!)
Working through the text, I created my own stylesheets for each formatting instance that cropped up, and then made sure the correct stylesheets were applied everywhere they needed to be.
This was the easiest book text formatting project I’ve worked on for a long time. As Rose Doran Dreams is a novel, it mainly comprises body text, divided into chapters and sections. It contains hardly any photos, no drawings, tables, graphs or charts of any kind, and only minimal formatting deviating from the main body text. This non-standard formatting is almost exclusively found in the front matter and back matter (the copyright notice, acknowledgments and endorsements from other authors etc).
Anyway, Berlie now had a PDF file to send to her advance readers.
It was now just a case of designing the cover (although in reality, as mentioned at the beginning, these processes overlapped).
Designing the cover
I’m sure many book cover designers will actually read the books they are designing covers for. (Possibly excluding the people who design dictionary covers!) And in most cases, I have also read the books I’ve designed covers for; in some cases, inside out, character by character.
But this time was different. I’m not part of the book’s target audience, and I’d already spent long enough on the book, converting sets of dots into ellipses and similar operations, that I’d seen enough of the text to more or less know what was happening and what it’s about.
As a result of this, and by asking Berlie relevant questions, I felt as if I knew as much about Rose Doran Dreams that someone could know without actually having read it.
This would turn out to be a mistake.
Anyway, I got to work on the cover.
Publishers have artists and photographers at their disposal, so there’s virtually no limit to what can be done for a cover design. But as this was a self-published project, with a budget to match, we only had stock photography at our disposal.
In one sense, it was clear what should be on the cover. The book’s title mentions the protagonist by name, so it would have to be ‘Rose’! Plus: products with faces on tend to sell better than products which don’t have faces on. So there was no place for abstract art here.
I asked Berlie if Rose is described anywhere in the book. After all, if the protagonist is a pink-haired, heavily tattooed and pierced wheelchair user, the cover would have to reflect that. In the event, Rose turned out to be young, attractive and brown-haired. But Berlie didn’t explicitly say that the book was set in the past, and I’d not really picked up on that fact myself. That was another mistake.
It was clear from the outset that we would use paid-for stock photos. Why’s that, when there are sites offering free stock photos?
On the one hand, with free stock photo sites like Unsplash, Pixabay, Pexels and the rest, you can never really be totally sure that the person ‘making their work available for others to use and enjoy’ really is the copyright holder.
And although the photos available from paid-for stock photography sites have also been used many, many times before, they have possibly been used a bit less than the free ones. Most people looking for things on the internet are skinflints, who aren’t prepared to pay for anything.
So I set to work searching paid-for stock photo sites for suitable photos of ‘Rose’ that were within our budget. This yielded a handful of potential options, some of which were more suitable than others. For instance, some were cropped too closely, limiting my options for positioning her on the book cover, or the backgrounds weren’t totally suitable in some respect.
I also scoured myfonts.com, my go-to website for typefaces, looking for something suitable for the title on the cover. The author name didn’t need to be in expressive text – in fact, we wanted it to be clear and readable, helping people familiar with Berlie’s name recognise that she was also the author of this work. I knew of just the thing; a versatile typeface I already owned and have used for other projects.
The creative process and approval
The actual creative work – designing the ebook cover – could now begin. Albeit with a watermarked, low resolution preview stock photo: I wasn’t going to buy the high resolution stock photo until Berlie had approved the design in writing!
Amazon’s recommended cover dimensions are currently 1600 x 2560 pixels, but this is really narrow, and many books don’t stick rigidly to this recommendation. I decided to go for 2000 x 3000 instead. Although the size and resolution are more or less in line with Amazon’s recommendations, the extra width gives us more room, including for the book’s title. Look in your chosen categories to see what dimensions your ‘competitors’ use. Is a certain size ratio expected? Use that as a guide.
Anyway, once I was happy with the design and had ‘sat’ on it for a few days, so I could see what it looked like after a period of time away from it, I sent it to Berlie. She was immediately delighted with it, but I also gave her a few days to get used to it, in case she had any comments or suggestions.
A few days later, she approved the mockup cover design in writing, so I bought the stock photo and recreated the cover design using the high resolution, watermark-free stock photo.
This too was approved.
Except not quite.
Notice how this cover design is different to Rose Doran Dreams’ actual cover, as shown at the top of the page?! More about this further down.
My standard book/ebook creation workflow
The majority of book projects I’ve worked on have involved a printed book.
Printed books offer more typographical control than is possible with ebooks, which work more like a website. Although an ebook’s essential functioning is the same for everyone, what readers see depends on their device type and size, as well as their preference settings, for instance for font and text size. So if people want to read their ebooks in the Comic Sans typeface, there’s unfortunately nothing I can do to stop them!
I therefore normally use InDesign® for laying out and typesetting the printed book, and then create the ebook on the basis of my InDesign® file. Depending on the nature and content of the book, I either make a copy of the print file and adapt it to create the ebook, or I paste the content into a new ‘base’ ebook InDesign® file. Whichever method I choose, I then export the resulting file for further processing in Sigil, BBEdit or both.
As most of the book projects I’ve been involved in have been fairly complex, containing images, tables, graphs and loads of special formatting, I tend to use Sigil more than BBEdit for this processing. This is because in Sigil, I can actually see what the results look like. But BBEdit is handy, and quicker, if I’m just shuffling code around, especially if this is just basic XHTML or CSS that I know isn’t going to mess anything up.
Simplified workflow for Rose Doran Dreams
On the face of it, this book would be an easy one: it has a typical novel length of around 80,000 words, without much in the way of special formatting. There was no need to work on it in InDesign®, as we had already ruled out there being a print version of Rose Doran Dreams.
Instead, I could just export to EPUB straight from the Pages master text file, and then probably do all the ebook tweaking in BBEdit, maybe only using Sigil to get the sizing of the two photos right.
Why am I talking about EPUBs when Rose Doran Dreams would be an Amazon Kindle ebook? The EPUB would serve as the basis for conversion to the Kindle format. Plus, it’s quite possible that some reviewers would rather receive an EPUB than a PDF.
Enforced change of plan
After exporting from Pages to EPUB, I double-clicked the resulting EPUB in order to open it in Books, just to get a first glimpse of how things looked and what formatting would need to be improved.
Nothing much happened.
I waited, and waited…
When the EPUB did eventually open, every paragraph appeared on its own page! You can imagine how many paragraphs an 80,000 word novel includes. That was the reason the file had taken so long to open!
Something in the stylesheets and/or export settings presumably wasn’t right. It’s entirely possible that the same source file had existed in one form or another for the best part of 30 years, being modified now and again. If so, it’s no big surprise that weirdness had somehow crept in.
Although I’m the sort of person who likes to get to the bottom of such problems, in many cases losing sight of the woods in order to focus with laser-like accuracy on the trees, there wasn’t enough time available.
Instead, I tried something I’d never done before. I exported the Pages master text to Word format, opened it in LibreOffice, and having checked that it looked OK and that the stylesheets had all converted properly, I exported from LibreOffice to EPUB.
This time, the file opened properly and looked more or less as expected.
Creating an ebook could hardly be easier. All you need to do is click ‘Export’ from Pages, InDesign®, LibreOffice and probably others (but not Microsoft Word, as far as I know). But creating a good ebook requires a bit more work. EPUBs that have just been exported from other software are fairly basic, and their code tends to be bloated. We wanted Rose Doran Dreams to not only look as good as possible, but also for the code to be lean and mean, so we could minimise Amazon’s bandwidth and therefore the delivery charge that is deduced from Berlie’s commission.
Although not strictly necessary, I like to name the files that constitute the ebook according to my own conventions. Although the names of content.opf and toc.xhtml are set in stone, you’re free to change the others as you wish, provided you ensure all the references to them in content.opf and toc.xhtml are correct and point to the right places.
Why did I want to do this? All programs that export EPUBs have their own way of naming things. Although these are usually in some kind of numerical order, it’s not always immediately obvious where to find particular chapters, as this default numbering also includes the front and back matter, which isn’t numbered in the actual ebook.
If, in ten years’ time, Berlie requested some text changes ready for a special 10th anniversary edition, I’d want to be able to jump to the relevant chapters immediately. Chapter 1 of the book should correspond with a file called ch1.xhtml and so on, and similar for the copyright, reviews and author bio pages etc.
I also wanted to slim down the CSS code. Every unnecessary declaration eats a tiny amount of Amazon’s bandwidth, and therefore gnaws at the money Berlie receives from sales.
Another enforced change of plan
As mentioned above, I’d intended to do virtually all processing of the EPUB in BBEdit.
However, for some reason, there was a problem with BBEdit’s text wrapping function not working in some chapters. The function to turn text wrapping on was greyed out and unselectable.
This meant that in affected chapters, each paragraph ran from left to write in one long line. Longer than the application window, and longer than my monitor. That was no good!
There didn’t seem to be any rhyme or reason to this. It wasn’t necessarily the longer chapters that were affected; it appeared to be totally random. I briefly tried troubleshooting the problem, but as time was tight, I decided it would just be quicker to do everything in Sigil this time, after all.
Editing the EPUB file
After naming the constituent files according to my own conventions and making sure they were properly linked, it was now time to look at the CSS code.
The CSS code generated by some applications is leaner than that generated by others.
It makes no sense to define every paragraph anew. Especially in a novel, where virtually all paragraphs have exactly the same formatting.
It’s not the intention of this article to describe the exact process (maybe something for another day!), but I shave a bit off the file size by defining a standard paragraph, then adding and defining my own classes for anything that deviates from the standard. For example, although the first line of most paragraphs is indented, the first line of the first paragraph in a chapter or section of a chapter isn’t, so I needed to override the left-hand indent for these.
I also wanted to ensure that things such as italicised words, words in bold, chapter headings and indented sections for quoted text all looked as I wanted them to. Ditto the front matter and back matter sections, where more in the way of formatting was required.
Plus, I also wanted to minimise the chance of widows and orphans appearing, as well as prevent hyphenation of chapter titles or other important elements, such as the names of the authors who had provided endorsements. However, e-readers interpret these CSS rules differently, meaning it’s not always possible to prevent such things occurring. Ebooks (and websites, which work on a similar principle) don’t offer anywhere near as much typographical control as printed books do.
A time-saving lesson for me
In EPUBs, there’s no need for a physical table of contents in the book, as readers can navigate everywhere using the navigation in their reader or software. For this reason, I didn’t include one. But I’d temporarily forgotten that Kindles require a physical table of contents. It wasn’t a massive problem to add it later, which is what I did, but including one in the EPUB would have saved me a bit of time.
Once I’d finished copying and pasting and searching and replacing bits of code in Sigil, I had a finished EPUB, which I then validated for compliance with the EPUB standard. My initial file contained some validation errors (oops!), but these were easy to fix.
How can you validate EPUBs?
The W3C’s official EPUBCheck tool can be found here. This is a command line tool (wait, come back!). Luckily, the same page lists some third party implementations of the same tool, but with a graphical interface. I used this one (scroll down that page a bit for the English text). There are also websites which provide online validation. These may be worth considering, but it depends how confidential your ebook project is.
Berlie now had an EPUB file to examine, check and hopefully approve.
Converting the EPUB to Kindle format
Luckily, she did, so with the EPUB approved, it was now time to create a Kindle ebook!
The first step was to make a copy of my EPUB file, in a separate folder, and with the file named accordingly.
This is the file I would be editing, in order to convert it to Kindle format. So I now had three copies of the book text to keep up to date: the master text, the EPUB (for reviewers) and the EPUB that would be converted to Kindle format.
It was absolutely crucial not to get these two EPUBs muddled up, hence the separate folders.
Kindle is Amazon’s proprietary format, as opposed to the open EPUB standard, and as such, it does a few things slightly differently. The cover was already broadly within Amazon’s specifications, as I’d ensured this when creating the initial EPUB. But I still needed to edit the constituent files, mainly the content.opf file:
- To make sure the cover worked correctly and didn’t appear twice
- To make sure the table of contents worked properly
- To define the starting point and other landmarks in the ebook, to ensure the navigation worked properly
- To ensure the meta data was present and complied with Amazon’s requirements (which are different to those of the EPUB standard)
- And to tweak the CSS to deal with a few peculiarities that differ from the standard
I then opened this second EPUB in Amazon Kindle Previewer, in order to convert it to Kindle format.
I was pleasantly surprised how much this software has improved since I last used it. It used to be really ugly and clunky, but now it looks a lot better and is a lot more pleasurable to use, even though it still feels a bit like ‘unfinished software’ in one or two respects. (Why can’t you paste text into the ‘file name’ field of the ‘Save as’ dialogue box? Surely a company with Amazon’s resources can get something like this right?)
Amazon Kindle Previewer shows how your ebook, converted to Kindle format, looks on various devices:
- Tablets (the modern Kindle Fire devices, plus iPads and other tablets)
- And the older, monochrome Kindles
Styling ordered lists
A visual aspect I wasn’t too pleased with related to the physical table of contents that is required by Kindle.
A table of contents in an ebook comprises an html ordered list, like this:
- Some chapter or another
- Another chapter
- And another
This is just like the list function in word processing software. The numbers are created automatically as you add extra items.
When I created the physical table of contents for the ebook, I’d visualised the text as being centred, as the chapters were just called ONE, TWO and THREE etc.
But because of how these HTML lists work, centring the items in the table of contents would have resulted in the numbers remaining at the left hand side, with only the text being centred. This looks terrible.
Although it’s possible to use CSS to hide the numbers, and also to ‘trick’ devices into centring the elements, this method is not 100% reliable across all devices.
When I was previewing my work in Amazon Kindle Previewer, my ‘fix’ worked for some devices, but not others, where the items were all higgledy-piggledy.
This was also clearly no good.
The items in the table of contents would have to be left-aligned.
Which gave us our next problem:
When previewing the physical table of contents on larger, landscape screens, the words looked lost, tucked away right at the left-hand side. This wouldn’t have been quite as pronounced with descriptive chapter names, but I wasn’t expecting Berlie to want to come up with 44 of them.
In the end, we prepended CHAPTER to them, to give us CHAPTER ONE etc, which improved things a bit, even if the names weren’t massively longer.
I also implemented this change in the master text file and in the main EPUB. Because Berlie would be sending the PDF and/or EPUB to other authors, journalists and other media (see part 2), I wanted all formats to be consistent.
Inconsistent initial capitals
Something else which only became apparent at this stage was how Kindle devices displayed the initial capitals (drop caps) at the start of chapters. When styling the ebook, I’d set the initial capitals to be three lines high, which had worked as expected in the EPUB. But in the Kindle version, certain ones were four lines high.
Upon inspection, these were the chapters which started with a quoted section, and therefore an opening quotation mark, but also a chapter which began with the letter J.
Some more CSS tweaking was required, which I also implemented in the main EPUB.
Validated Kindle file
Anyway, after some internet searching and some cursing and swearing (pretty much my life; day in, day out!), I had now created a functioning Kindle ebook that had passed the internal validation test.
The final step was to export a KPF file that could be uploaded to KDP.
Amazon KDP also accepts manuscripts uploaded in Word, EPUB and a number of other formats, which I imagine is what most people do. But I prefer to do the conversion myself, so I can be as sure as possible that what leaves my computer is what readers will see on their devices or software.
Cover design feedback – back to the drawing board
While all this was going on, the advance readers were doing their stuff. And as far as I am aware, their feedback was positive. Apart from in one respect:
It apparently didn’t match the book. It looked too much like the cover of a love story for teenage girls.
How embarrassing. This makes me look like a designer who went away and designed the wrong thing. Doubly embarrassing, as on my book design page, that’s exactly what I say I don’t do.
I‘m sure Berlie must have plucked up all her courage to tell me the cover wasn’t right, and that she wanted to change it.
“But you were delighted with it, and have already approved it in writing.”
“The book changed quite a bit as I was working on it. It got a lot darker.”
Key lesson for me
Don’t ever design a book cover unless the book is actually 100% finished! By designing the cover while Berlie was still working on the text, I thought I was saving time and speeding the project along. But it turned out I wasn’t.
Because I now had to design a new cover, this would eat into the time we had intended the ebook to be on presale for (see part 2). We couldn’t delay the actual release date too much, due to Berlie’s new children’s book being published later in the year. What we had envisaged as a three-month presales period could only ever be about a month and a half at the most. And we decided on just one month, to make the dates easier to remember. Rose Doran Dreams’ period of visibility in the Amazon store’s ‘shop window’ would therefore be shorter than we had intended.
Of course, we both wanted the cover to be the best it could possibly be, but Berlie had approved it in writing. But with my fee renegotiated, we went back to the drawing board. We?
Yes, as at this time I was massively busy with other projects, so to save time, I asked Berlie to help by finding some potentially suitable stock photos.
Of the ones she sent, some could be immediately discarded: either they were cropped too closely, or already had effects applied to them, tying my hands. What do I mean by that? Some stock photos already feature all sorts of effects and digital trickery, and look absolutely stunning. But you can’t remove or modify those effects: you have to use the photo pretty much as it is. Which people do. And so they turn up all over the place.
Don’t use any stock photography 1:1. Do something different with it. No, I don’t mean just create a mirror image of it! Perhaps use just a small section of it, modify the colours or apply some other kind of processing of your own. Use it as the basis for your own creativity (checking the licence terms first, of course!).
I ran the remaining images through a Google reverse image search, to see how often, and where, they’d been used. As pretty much expected, they’d mostly all already appeared somewhere else. The ones that had been created to be used as book covers had already been used as book covers, so no surprise there! Others were for sale as framed prints etc.
This left us with only a small handful of good stock photos that hadn’t been used as other book covers and which didn’t restrict us too much in terms of the processing that had been applied to them. Having selected one, it was time for another mockup, again using the free, watermarked, low resolution preview image.
The original image looked totally different to how I used it on the cover of Rose Doran Dreams. It was the sort of image that crops up in fantasy/spiritual circles, and which could probably be accurately described as kitsch. Although it wasn’t to my personal taste, the photography and retouching were absolutely amazing, and the model stunningly attractive.
Now it was my turn to fiddle around with software, in order to transform it into what I had in mind. I also used the same typefaces as on the previous, approved then unapproved cover.
Luckily, Berlie was as delighted with this version as she was the previous one, if not more so. So after having received written approval from her, I bought the high resolution, watermark-free photo and recreated my design. The new cover then had to be inserted into the master text, advance readers’ PDF, reviewers’ EPUB and the EPUB for conversion to Kindle format. In turn, this also had to be converted again, to create a brand new, final Kindle file for uploading.
We were done!
At least, I was.
It would now be Berlie’s job to make sure that as many websites, blogs and media people as possible knew about – and ideally, featured – Rose Doran Dreams.
For anyone who thinks they may enjoy a psychological fairy tale, the Rose Doran Dreams Kindle ebook is on sale here, as well as in some of the other Amazon stores in other countries.
Rose Doran Dreams: ebook case study – summary
So, many thousands of words later, we’re done.
Has this lengthy, meandering but by necessity still not totally exhaustive series of posts helped you in any way? Let me know in the comments below.