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