Category: Digital Publishing

Photo Credit: Nigel Goldsmith

Last week the Medical Research Council released it’s new annual report in various digital formats. Tribehut (that’s me yeeeah) planned, designed and built the ebook versions.

I have been banging on about making ebooks for some time and this caught the attention of Matt Jukes. Ever the ‘digital’ experimentalist, Matt asked if I would be interested in making the digital versions of their annual report ‘Advancing Medicine, changing lives’. I jumped at the opportunity.

With budgets being squeezed and a general ban on many print outputs, the public sector has been forced to turn to ‘digital’ outputs. For those of us who love ‘digital’ now is the time to stand up and to demonstrate that digital might actually be good.

I felt this project could act as a perfect demonstration of just how good digital can be and I wasn’t planning on dropping the ball.

Planning and design

One of the key aspects of a ensuring a successful project workflow is to get one defining voice on the client side, in this case Matt, and to get the content at the very beginning of the project. Assumptions about content will not only waste time but lead you down the wrong path as you simply cannot make judgements without seeing all the pieces.  Thankfully the team at the MRC had already produced the PDF version so this wasn’t an issue. I was sent the PDF along with a short brief which gave me enough to assess the project requirements and commit to the project. Note – ensure that the ‘final’ content is really that, I have been burnt before with being sent an old ‘final’ version which stops a project dead.

The original beautiful design was created with ‘print’ very firmly in mind. From the PDF (I call this the blueprint), I discussed with Matt the sticking points in regard to any potential limitations, constraints and show-stoppers in relation to the technologies we’d be employing. Those decisions not only helped to manage expectations but also enabled me to make appropriate design choices.

For example, most ereaders and reading apps tend to over-ride many of the designers choices, such as font choice. So my suggestion was to leave the font choice to the reader and/or device. Also, the PDF version has some graphical flourishes in the margins which visually link articles across a page spread, but this is lost in the ebook – the viewport (what you can see at any given time) is not fixed as it is with print. For better or worse, an ebook is primary about text and so we agreed to keep the pretty graphics for chapter starts and within sub-sections where they are context specific.

Regarding what devices we needed to target, we had no previous data, so I couldn’t be sure what devices the audience had. Thus the ebook needed to work across as many devices, apps and configurations as is reasonably possible. Furthermore, being an annual report it required a minimum 1 year shelf life. Rather than making an assumption that everybody would be using either the Apple iPad or an Amazon Kindle I planned to make it work very well across the board. This means building a well constructed epub and Kindle mobi file with a sprinkling of technical features that are unique to the iPad or Kindle. Luckily ereaders ignore what they don’t support so there wasn’t too much to worry about regarding this.

I am a fan of rapidly building something as soon as possible, test it and then refine.
At this point both sides were ready and excited to move to the code phase.

Coding

Until Matt and the team could ‘see and use’ the ebook it would be difficult to complete the project so I pre-warned them that the previews were just that (we ended up with 25 iterations with 13 being the first MRC saw).

At this point I requested all of the PDF assets, which included all source imagery and colour palettes for the build.

I needed a final EPUB2 file and an accompanying Kindle mobi file. I chose to stick with EPUB2 over the newer EPUB3 as it isn’t widely supported yet and also I didn’t have any use for the specific EPUB3 features. No reason to reduce compatibility for the sake of being an early adopter – showing off experimental features was too high risk in this scenario.

For this build I used an HTML editor called Coda (but you could use anything as long as it has find+replace with REGex support as a bonus).

I took all of the text from the PDF and dumped each section of content into a plain html panel within Coda.  I then re-built all of the sections, adding tags etc until I was happy that I had all of my content with placeholders for the images. Some of this can be automated to reduce heavy coding BUT be aware that automation may disappear your content…so I just used a few regex commands to mass add things like paragraph tags.

Next I built a global template epub page with 1 sentence of text and ensured that the template worked.

From the working template I added each section and then added the other required files for an epub such as the mimetype, xml and content.opf which includes links to all the assets used and metadata.

An epub file has a strict bunch of required files so pay attention at this point of the build.

The kindle file is built using the Amazon conversion tool “KindleGen” from the EPUB file. It has a few of its own quirks so I made sure I had read the documentation.

At this point I had Baldur Bjarnason kindly look over my files to sanity check my decisions. He found and squashed a few bugs so was well worth an extra pair of eyes.

Testing and refining

At this point I would like to stress the huge value in documenting your changes in a simple changelog. It is too easy to forget what changes you made 3 versions earlier and things break because of this. I kept brief notes in one simple text file with all code changes included and rationale. This was also useful for when Matt and the team made change requests so we could all see who, when and what got changed.

I used a bunch of test devices, which I recently wrote about to ensure the EPUB worked as widely as possible. During this phase changes included:

• the cover image was simplified to work at small preview thumbnail sizes.
• all chapters got pretty graphics from Vin Kumar, MRC designer.
• graphic file sizes were optimised, particularly to help mobile readers.
• section page breaks were forced for the Apple iPad to stop sections starting in odd places.
• hyphenation was adjusted as the defaults were hideous.
• validate, validate, validate,

With each change came improvement to the final reading experience.

The KindleGen app comes with a previewer so that you can simulate your test file in any of the kindle hardware versions without buying older devices. Sweet!

Which shows you an accurate preview

Decisions or compromise

In the end we managed to reach a great place for the final EPUB. Yet not all reading experiences will be equal. The iPad and the Kindle both have fantastic results (even the images were adjusted to work in low contrast for kindle).

As some reading apps like to overly control the reading experience, details like the colour section headings aren’t included in the nexus 7 apps Akido which likes to make all text 1 colour, over-riding my choices. However these things are beyond our control so all we can do is include them and let the reader app chose to include or ignore them. Maybe some day the app will update with these features included. A great example of this was towards the end of testing, the Adobe Digital Editions app upgraded to v2, making all the previously black headings appear as intended – the colour of the section it belonged to.

Our ‘digital’ world is always evolving so even these compromises are really just decision points. If everything was static or we didn’t have much choice I would be even more upset, so I sleep happy.

Launch

When I pushed the final two files to Matt I got the jitters as I was very excited to let the world see our hard work.

I hope that this project will encourage others to consider the ebook format along side PDF outputs and that this post has shed some light on the process.

I would like to say that I got to work with some truly great people on this project and would like to thank Matt Jukes, Vin Kumar, Matt Durant, Baldur Bjarnason, Nigel Goldsmith, Roberta Perli and Stephen Gray for feedback and use of devices.

Matt has written about his experience of the project too, so do let us know what you think.

Below is what an EPUB looks like under the cover.

If you enjoyed this post then check out my 100 things about digital publishing series.

Follow me on twitter @zakmensah

I have just finished up a consultancy project building an ebook that i’ll talk about soon. The photo above shows the kit that I used to test the ebook at various stages. I produced two files in the process: EPUB for most devices including the iPad and a Mobi file for the Kindle hardware and app version.

• Laptop with various reading software – Adobe Digital Editions v2.0, Kindle app, ibis reader, Kindle previewer (lets me test all versions of the hardware on the computer and saves buying hardware).
• iPad with the Kindle app and ibooks (i used 3 iPads v2+3)
• Google nexus7 with the Kindle app, Aldiko reader (lame) and Moon+reader (also lame), ibis reader
• Kindle Paperwhite
• Nook Simple Touch
• Kindle 2nd Gen – it was kicking around so why not?!
• Kindle previewer (allows you to test in all versions including the Kindle Fire)
• Kindle Touch
• Sony PRS-350 (thanks Stephen) – great to see how e-ink handles colour graphics
• iPhone 4 with the Kindle app, ibooks and also ibis reader
• HTC One X with Kindle app and ibis reader

For each device, the ebook displays and behaves differently so it is essential to test on the devices that you think will be used. Mr Andy Clarke said it best:

Designers need use only a subset of devices, because what matters most is that we develop an affinity for how our designs work on any type of device when we hold it our hands. To be clear, how a menu feels when used on a smartphone is a very different issue from whether it technically works on a particular make or model of smartphone. That’s why designers don’t necessarily need to buy a myriad of smartphones and tablets, just those they need to develop an affinity for.
Andy Clarke, Encouraging Better Client Participation In Responsive Design Projects

Sound simple right?! I got the list partly from what I have been using anyway and then from The mobile read wiki which has popular community input.

I will write more about ebook building, testing and frustrations in future posts.

By the way, my favourite reader is the now in limbo ibis reader which I read on my mobile phone or nexus7.