Since 2003, the Cool Tools website has posted more than 2,000 reviews of tried and true stuff. In collaboration with Cool Tools, we’ve put together their first ebook compilation: Cool Tools in the Kitchen by Kevin Kelly and Steven Leckart. From Steven’s preface:
Broadly defined, a Cool Tool can be any book, gadget, software, video, map, hardware, material, or website that has proven utility. The reviews there are not the kind of comparative reviews you’ll find in magazines and other websites, which give pros and cons for each item. Rather, our reviews are outright rave recommendations submitted by readers who swear by the items, telling you why you should use them as well. Think of this book as a very knowledgeable best friend recommending the coolest stuff in no uncertain terms.
Unlike most O’Reilly Media ebooks, this book is available in only one format: ePUB (but like all O’Reilly Media ebooks, it’s DRM-free). That’s because the ePUB format has some unique strengths and capabilities, and we planned this project with Kevin from the beginning as an exploration of how far we could take ePUB to bring the Cool Tools experience to an ebook.
I asked Nellie McKesson, O’Reilly Media Production Specialist and ePub wrangler, to give us some background on how this book came to be.
It was really a team effort getting the final product where it is, and involved a lot of back and forth. The files were sent to [O’Reilly Media’s Director of Content and Publishing Operations] Adam Witwer in Word, who had them retagged to match our standard conventions. Then he ran the files through our usual conversion to DocBook and then epub.
Adam took the first stab at building in some customizations by hand, mostly trying to mirror the Cool Tools website. [Cool Tools Research Librarian] Camille Cloutier, along with authors Steven and Kevin, came back to us with a list of ideas and changes, at which point Adam handed the project over to me.
For my part, it helped immensely that we picked one target reader: iBooks. There’s a huge amount of diversity in the different things that can be done on different readers, but iBooks is generally the most versatile. I thus had a lot more freedom to work, and also didn’t have to deal with the extensive amount of testing and QA that would have been needed to build-in broader compatibility.
Building for iBooks still has its quirks, though. First, there isn’t a desktop app to test in. I actually used Adobe Digital Editions as my test environment, and then periodically loaded it first onto Adam’s iPad, and then my own when he got sick of me sending him files to load and sprang for another iPad for me to use. There isn’t a good way to get around iBooks’ data cache, which meant that every time I wanted to QA a new iteration, I had to delete iBooks from my iPad entirely and reinstall, then reload the newest epub file.
As for the specific design, it’s hard for me to say how I finally got to the end result. I went through a lot of iterations, trying to find something that fit the authors’ and editor’s vision, and also satisfied my design sense. I actually got the idea for the tabbed chapter openers one day before my first draft was due, and raced to implement (I think I actually ended up being a little late because of that). It was only then that I really felt happy with what I had made, like I was on the right path.
For the tabs I applied a fixed width and a background color to the containing element, and used the webkit-border-radius property to round the corners. Instead of using a bottom border, I added a horizontal rule under the chapter title, and gave it a negative top margin so that it overlapped the bottom edge of the bounding box. I actually was thinking of the Kindle when I did this, since the Kindle doesn’t support borders, but it does support <hr>s. I actually did a test conversion to Mobi a couple days ago, to see what would happen, and the chapter titles were one of my only customizations that looked halfway decent, because of the <hr>’s. If we wanted to release a decent-looking Kindle version, I’d have to make a whole other epub first, and strip out or change a lot of stuff, and then reconvert. As I said before, if we had gone in with the intention of making a cross-compatible product, then I’d have been more careful, but it wouldn’t have looked quite as nice.
I picked up a little trick from Liz Castro’s blog to get the chapter opener grids to work. iBooks doesn’t like size restrictions applied directly to images, so I put each image within a div tag. The div is sized to 30% width, and the image is sized to 100%—basically saying, fit the image to the full width of its container, so the image ends up at 30% of the page size too. I then gave gave those divs a “display” value of “inline-block” in the css. This lets them all run together, instead of each one breaking onto its own line.
For the unique chapter colors, I was careful to build as much into the base style as possible and use real cascades. I tagged each chapter <body> tag with a custom class for the chapter, and then just added custom CSS for the things that needed to change—background colors, etc. This isn’t revolutionary or “magic”, but it’s important and if I knew just a little bit less about CSS, I could have easily done it wrong—built an entirely new definition for each chapter class, which would have added a lot of unnecessary clutter to the code. For example, here are a few lines from the CSS for the chapter titles:
/* title and copyright page */ .chapter-title { text-align: center; color: #fff; -webkit-border-radius: 5px; -moz-border-radius: 5px; padding: 9px 5px 5px 5px; margin-bottom: 0px; max-width: 75%; } .ch01 .chapter-title { background-color: #EE0000; border: 1px solid #EE0000; } .ch02 .chapter-title { background-color: #91219E; border: 1px solid #91219E; }Interestingly, pagebreaks were still a bit of a battle. Reading on the web is a lot like reading on a big scroll—the page is as long as the content; eReaders are still more like print books, in that they still have a fixed page size, but the reader can change how much stuff they want on that page (by adjusting font, font size, margins, etc). In order to maintain this capability, there are going to be some presentations where the content breaks oddly. I came to grips with this idea a while ago, and it seems completely natural to me. I come from a print production background, and there are things that in a print book would drive me crazy, but in an eReader I barely even notice–widows, orphans, bad line breaks, etc.—and I’m not totally sure how to interpret this shift in myself.
Big thanks to Nellie, Adam, Camille, Steven, and Kevin for making this happen!
ADVERTISEMENT
