Amazon Look Inside Fail
This is a guest post from alumni EPUB Secrets editor Kevin Callahan. He recently discovered a Look Inside-bug and wants to share it with you. And to talk about therapuetic powers of ice cream.
Where am I? In everyday life, it’s nice to know where the nearest soft-serve ice cream store is. In an ebook, it’s great to have a handy list of landmarks (preface, introduction, start of content, index) and a clickable list of print-page-corresponding links.
It’s not hard to implement those accessibility features. To create landmarks, assign an epub:type to each element. You can do this in InDesign or in the HTML itself. Here’s the markup:
(Don’t forget: use the semantically meaningful <section> instead of the blank <div>, and close it with </section>. For more semantic insight, check out Laura Brady’s post, Producing Accessible Ebooks: http://epubsecrets.com/producing-accessible-ebooks.php.)
To create a Page List, use this handy InDesign script (http://www.bradytypesetting.com/rorohikoscripts) from Rorohiko.
One File, Two Tables?
1. Navigation Table of Contents
Both Landmarks and Page List belong in the toc.xhtml, which can be generated by InDesign. Landmarks can be included by InDesign if you assign epub:type in Object Export Options. You’ll have to add Page List manually after export, after running the Rorohiko scripts.
The toc.xhtml is used by reading systems for the navigation table of contents, which is accessed in any number of ways, depending on the reading system.
Landmarks and Page List don’t actually show up yet in many reading systems (Adobe Digital Editions is an exception; see below for an example), but they will make your ebooks accessible far into the future.
2. Inside-the-Book Table of Contents
I used to make that InDesign–exported toc.xhtml do double duty by inserting it into my EPUB as the inside-the-book listing (which is required by Amazon, by the way). Just add it to the spine (in the content.opf) and style using CSS.
For inside-the-book usage, just hide the Landmarks and Page List. (Who wants a long list of links to a 400-page book cluttering up the frontmatter?) Add a ‘hidden’ attribute to the markup, like so:
With the corresponding CSS:
This blocks display of the Landmarks and Page List, and so they don’t show up in the inside-the-book contents listing.
That is, they don’t show up in normal places. Kindle’s Look Inside feature on the Amazon website is another story. There, ‘hidden’ is meaningless. In fact, it means: “don’t hide!”
It’s Not Hidden!
A client recently told me about me a Look Inside that featured the title page followed by 15–20 screens (depending on font size) of Page List. I’m not a marketing pro, but I have a feeling that’s not a great sales tool. Take a look at this screengrab from ADE showing the beginning of a page list, and you’ll see what I mean (I couldn’t get the client to take a picture of the Amazon store screen for me, so I have to approximate).
Each one of those page numbers is a live link to the print-corresponding location in the ebook. It’s great for book clubs and classrooms (go to page 10, everyone!). But, do you want that taking up your Look Inside real estate? Probably not.
After asking the folks on #eprdctn (https://twitter.com/hashtag/eprdctn), I deduced that Look Inside is archaic, even pre–stone-age. I’ve known for a while to counsel clients to not pay attention to ebook design on Look Inside; the book itself will be beautiful. But this basic fail is really unfortunate. Hidden doesn’t mean hide anymore!
Luckily, I’ve been making ebooks for millennia, so I’m adept at workarounds.
Quick Solution
Here’s what I did: I duped the toc.xhtml and named it toc-in.xhtml. I added the dupe to the content.opf, in the manifest, the spine, and the Landmarks listing itself. Then I stripped out the “hidden” elements, the Landmarks and the Page List, from toc-in.xhtml. That’s it. Here are screen grabs from various sections in the content.opf:
Manifest:
Spine:
Landmarks:
It’s sad, though. I enjoyed the idea of double-dutying the toc.xhtml. Who needs excess files in an EPUB? But I guess that’s just something to look forward to.
Notes to Self
After this little drama, I stored these helpful tips in my mind:
- Don’t think that that your job is done once you deliver a final file to a client. Follow up. Go to the ebook-store and see how it’s displayed. Look into the Look Inside. See what needs fixing.
- Don’t assume. If it works here and there and over there, even in ADE and Nook, it may not work in Amazon’s Look Inside.
- Don’t forget: Just because something displays properly today doesn’t mean it will tomorrow or in two weeks.
- Keep your phone’s Location Services turned on so you can quickly find the nearest soft-serve ice cream store and slurp away your sorrows.
I have no explanation, but I checked some look insides for our titles, and they don’t reveal the hidden page list on our ebooks, despite using the single TOC like you mentioned initially doing. Not sure what’s different.
I’m looking up titles that I’ve recently worked on and it’s really hit and miss. On some, Look Inside completely ignores my stylesheet and others it doesn’t. Doesn’t seem very consistant. Good to know, but I probably wont be doing any work arounds for this.
What’s EPUB specs’ case at all for redundantly adding epub:type to elements that are already listed as landmark in the Nav Doc? For instance, why adding it to a section element, like you suggest, if the link to such section in the landmarks section of the Nav Doc already has the attribute? What does such redundancy accomplish even in the best of cases?
(previously asked at Twitter’s #eprdctn http://twitter.com/elmimmo_/status/888321864891854849 without causing much resonance )
[…] Kindle Look-Inside Fail http://epubsecrets.com/amazon-look-inside-fail.php […]
That means nobody is able to publish a specific know-how book on amazon? lol….
i hate it to buy a 700 site book just to search and read 2 phrases…