best of toc 3e analysis and ideas about the future of publishing

Tools of Change ing for Publish Content Book: Marketing turist’s u F A Every Boopk Manifesto Is a Startu Tools of Change ing for Publish to tive Guide The Defini r Content an Making You rketing Tool Effective Ma siness The New Bulishing of Pub rsten Todd Satte n of Essays A Collectioeding Edge ing from the Ble of Publish ire & Brian Hugh McGu O’Leary ugall J S McDo Transforming Publishing O’Reilly Tools of Change delivers a deft mix of the practical and visionary to give the publishing industry the tools and guidance needed to succeed—and the inspiration to lead change n WEEKLY NEWSLETTER n INDUSTRY NEWS & COMMENTARY n FREE REPORTS n WEBCASTS n PODCASTS n EVENTS n BOOKS & VIDEOS Look to the future and stay informed oreilly.com/toc ©2013 O’Reilly Media, Inc The O’Reilly logo is a registered trademark of O’Reilly Media, Inc 13124 Best of TOC, 3rd Edition O’Reilly Media, Inc Best of TOC, 3rd Edition by O’Reilly Media, Inc Copyright © 2013 O’Reilly Media All rights reserved Printed in the United States of America Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472 O’Reilly books may be purchased for educational, business, or sales promotional use Online editions are also available for most titles (http://my.safaribooksonline.com) For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com Cover Designer: Karen Montgomery February 2013: Interior Designer: David Futato First Edition Revision History for the First Edition: 2013-2-12 First release See http://oreilly.com/catalog/errata.csp?isbn=9781449364335 for release details Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc Many of the designations used by manufacturers and sellers to distinguish their prod‐ ucts are claimed as trademarks Where those designations appear in this book, and O’Reilly Media, Inc was aware of a trademark claim, the designations have been printed in caps or initial caps While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein ISBN: 978-1-449-36433-5 Table of Contents Introduction Innovation How Agile Methodologies Can Help Publishers What is an agile methodology? How agile methodologies apply to publishing? Taking a Page Out of ESPN’s Playbook Pay for one, access all Building talent franchises Memorable quotes Perceptive Media: Undoing the Limitations of Traditional Media How does Perceptive Media work, and are there privacy concerns? What driving factors are pointing to the success of this kind of storytelling platform? In the early days, Perceptive Media is being applied to broadcast technology What potential applications for Perceptive Media you envision in the publishing industry? Kindle Fire vs iPad: “Good Enough” Will Not Disrupt How disruptive is the Kindle Fire to the low-end tablet market? Is Amazon a threat to Apple? What role you see Apple playing in the future of publishing — and what current trends you identify as driving factors? 10 Don’t Build Social — Thoughts on Reinventing the Wheel 10 Services, APIs, and the Complex Web 11 v Publishing focus and third-party opportunity Startups and Publishers: It Ain’t Easy If you sell a product publishers don’t want, who is to “blame”? Solutions to solve future problems Where to next? The risk of ceding the future to other players In the end, readers will drive the change It’s Time for a Publishing Incubator Roadblocks People have been thinking about this for awhile The publishing incubator The Slow Pace of eBook Innovation Putting a Value on Classic Content Reading Experience and Mobile Design Mobile design? Five convergence points for mobile design & reading system design Serial Fiction: Everything Old Is New Again Why should you be interested in serial fiction? Frequency, engagement, and experimentation It still comes down to great writing 12 13 13 13 14 14 15 15 15 16 17 19 20 22 22 22 25 25 26 27 Revenue Models 29 Getting the Content Out There Isn’t Enough Anymore In what contexts does content aggregation create the most value? How about paywalls — is anyone doing this properly? What is the best way to make this model work? 24Symbols is based on a subscription model Since your launch, have you had to change the model to make it work? Amazon, eBooks, and Advertising New Life for Used eBooks In-Book Purchases Why a Used eBook Ecosystem Makes Sense 29 29 30 30 31 33 35 36 Rich Content 39 In the Case of Interactivity, We’re Still at the Phase of Irrational Enthusiasm vi | Table of Contents 39 Where you draw the line between meaningful and gimmicky interactivity? Are there times when interactivity is detrimental and should be avoided? How have mobile platforms changed the publishing landscape? What kinds of tools authors need to create interactive content, and what new skills might they need to develop? What are some guidelines authors should follow when considering interactive features for content? How should one decide between building an ebook and building an app? Is there a tipping point? Are eBooks Good Enough Already? 39 40 41 41 42 42 43 Data 45 Transforming Data into Narrative Content What does Narrative Science and how are you applying the technology to journalism? How does data affect the structure of a story? What kinds of stories lend themselves well to this type of system and why? What kinds of stories just won’t work — what are the boundaries or limitations? In what ways can publishers benefit from Narrative Science? In what other industries are you finding applications for Narrative Science? Book Marketing Is Broken Big Data Can Fix It What are some key findings from the Bookseer beta? What kinds of data are most important for publishers to track? What does real-time data let publishers do? How would you describe the relationship between sales and social media? Will Retailers Start Playing Big Brother with Our Content? 45 45 46 46 46 47 47 47 48 49 49 50 50 DRM & Lock-in 53 It’s Time for a Unified eBook Format and the End of DRM Platform lock-in The myth of DRM Table of Contents 53 54 54 | vii Lessons from the music industry “Lightweight” DRM Isn’t the Answer Kindle Remorse: Will Consumers Ever Regret eBook Platform Lock-in? Neutralizing Amazon Kindle Serials Is the Next Brick in Amazon’s Walled Garden 55 56 57 58 59 Open 61 Publishing’s “Open” Future Content access via APIs Evolution of DRM Apps, platforms, formats, and HTML5 Let’s open this up together Free and the Medium vs the Message Free as in freedom (and beer) Information and delivery Creating Reader Community with Open APIs Reading is more than a solitary activity The new era of data-driven publishing The consequences of walled gardens Buy Once, Sync Anywhere The problem — a fragmented content ecosystem The proposed solution — an API to share a user’s purchase information What would the access permission API look like? Concept basis of a specification A common data transfer medium The future 61 63 64 65 66 66 67 67 68 68 69 70 71 71 72 73 74 75 76 Marketing 79 The Core of the Author Platform Is Unchanged — It’s the Tools that Are Rapidly Changing What is an “author platform” and how is it different today from, say, 10 years ago? What are some of the key ways authors can connect with readers? In marketing your book Cooking for Geeks, what were some of the most successful tactics you used? What advice would you offer to new authors just starting out? viii | Table of Contents 79 79 80 80 81 The Sorry State of eBook Samples, and Four Ways to Improve Them How Libraries Can Help Publishers with Discovery and Distribution How to De-Risk Book Publishing Selling Ourselves Short on Search and Discovery The Key Features of an Online Community Book Communities The Fundamentals Conclusion 82 84 85 88 89 89 90 92 Direct Sales Channel 93 Direct Sales Uncover Hidden Trends for Publishers Direct Channels and New Tools Bring Freedom and Flexibility Direct Channels Evolving Tools It’s the Brand, Stupid! NY Times eBook Initiative Could Be So Much More 93 95 95 96 97 98 10 Legal 99 Fair Use: A Narrow, Subjective, Complicated Safe Haven for Free Speech How is “fair use” defined and what is its legal purpose? Does the breadth of the fair use guidelines cause confusion? What are some best practices people should follow to stay within the guidelines? What are the most common fair use abuses? What kinds of content aren’t protected by copyright or subject to fair use? How would someone know if something is in the public domain or not? What’s your take on Creative Commons licensing? eBook Lending vs Ownership A Screenshot, a Link, and a Heap of Praise Are Met with a Takedown Notice 99 99 100 100 101 101 101 102 102 103 11 Formats 105 Portable Documents for the Open Web (Part 1) Table of Contents 105 | ix I’ve heard from a couple of people that the IDPF is interested in stand‐ ardising a stripped down, simple, version of EPUB I think that’s an excellent idea I also think it should be the first step in modularising the EPUB spec You’d have the core EPUB features as the core spec epub:switch? Separate spec epub:case? Separate spec epub:trigger? Separate spec Scripting? Put all of that in a separate spec Bindings? Metadata? Media Overlays? CFI? All separate specs with their own groups, editors, and timetable Or you could always aggregate all of the dead-end features into a single trashcan spec that everybody can safely ignore Staying out of CSS Nothing good can ever come from forking CSS and, make no mistake, any attempt on behalf of the IDPF to add ebook-specific features to CSS is going to result in a fork Ebooks already behave too differently from the browser baseline as it is Anything that increases that devia‐ tion is going to increase costs and the complexity of publishing ebooks So I propose that the IDPF give up on its efforts to standardise CSS extensions for EPUB and focus on advising the CSS WG on what ebooks need from CSS Graceful degradation for Fixed Layout Both reflowable EPUB books and fixed layout EPUBs support media queries Both of them support a wider range of CSS design features than you find in EPUB systems There is no easy way of creating a fixed layout EPUB that uses features such as positioning, backgrounds, colours, etc and degrades gracefully in EPUB reading apps that don’t support the fixed layout spec Ebook Problem Areas that Need Standardisation | 149 This is a problem especially for mixed-mode EPUB 3’s that include fixed layout pages in otherwise reflowable books These pages often look incredibly ugly or are simply rendered blank in reading apps that don’t fully support the fixed layout spec, such as the recently released iBooks 3.0 Figuring out some mechanism for graceful degradation in this context would be nice … unless, of course, everybody thinks that mixed-mode EPUB 3’s are a dead end that will never be widely implemented anyway What else? There are a lot of things that should be standardised if we could rea‐ sonably expect them to be supported at all in the ebook industry But those issues should not take priority over normalising and stand‐ ardising existing reading system behaviour InDesign vs CSS By Adam Hyde The explosion in web typesetting has been largely unnoticed by ev‐ eryone except the typography geeks One of the first posts that raised my awareness of this phenomenon was From Print to Web: Creating Print-Quality Typography in the Browser by Joshua Gross It is a great article which is almost a year old but still needs to be read by those that haven’t yet come across it Apart from pointing to some very good Javascript typesetting libraries Joshua does a quick com‐ parison of InDesign features vs what is available in CSS and JS libs (at the time of writing) It’s a very quick run down and shows just how close things are getting In addition Joshua points to strategies for working with baselines using grids formulated by JavaScript and CSS Joshua focuses on Hugrid but also worth mentioning is the JMetronome library and BaselineCSS These approaches are getting increasingly sophisticated and of course they are all Open Source It brings to our attention that rendering engines utilising HTML as a base file format are ready to cash in on some pretty interesting devel‐ opments However it also highlights how rendering engines that sup‐ port only CSS are going to lose out in the medium and long term since they lack JavaScript support JavaScript, as I mentioned before, is the 150 | Chapter 13: Production lingua franca of typesetting JS libs enable us to augment, improve, and innovate on top of what is available directly through the browser Any typesetting engine without JavaScript support is simply going to lose out in the long run Any engine that ignores JavaScript and is propri‐ etary loses out doubly so since it is essentially existing on a technical island and cannot take advantage of the huge innovations happening in this field which are available to everyone else Once again, this points the way for the browser as typesetting engine; HTML as the base file format for web, print, and ebook production; and CSS and Javascript are the dynamic duo lingua franca of typeset‐ ting All that means Open Source and Open Standards are gravitating further and faster towards the core of the print and publishing indus‐ tries If you didn’t think Open Source is a serious proposition it might be a good idea to call time-out, get some JS and CSS wizards in, have a heart-to-heart talk about the direction the industry is heading in • Correction: The latest release of PrinceXML has limited beta Java‐ script support Thanks to Michael Day for pointing this out.* [This and all posts by Adam Hyde are CC-BY-SA.] Math Typesetting By Adam Hyde Typesetting math in HTML was for a long time one of those I can’t believe that hasn’t been solved by now! issues It seemed a bit wrong — wasn’t the Internet more or less invented by math geeks? Did they give up using the web back in 1996 because it didn’t support math? (That would explain the aesthetic of many home pages for math professors.) MathML is the W3C-recommended standard markup for equations — its like HTML tags for math While MathML has a long history and has been established in XML workflows for quite some time, it was only with HTML5 that mathematics finally entered the web as a firstclass citizen This will hopefully lead to some interesting developments as more users explore MathML and actually use it as creatively as they’ve used plain text However the support in browsers has been sketchy Internet Explorer does not support MathML natively, Opera only supports a subset, and Math Typesetting | 151 Konqueror does not support it WebKit’s partial support only recently made it into Chrome 24 and was held back on Safari due to a font bug Firefox wins the math geek trophy hands down with early (since FF 3) and best (though not yet complete) support for MathML What’s the hold up? It seems that equation support is underwhelmingly resourced in the browser development world WebKit’s great improvements this year (including a complete re-write + the effort to get it through Chrome’s code review) have been due to a single volunteer, Dave Barton Frédéric Wang plays the same heroic (and unpaid) role for Firefox The question is: Why is this critical feature being left to part-time voluntary devel‐ opers? Aren’t there enough people and organisations out there that would need math support in the browser (think of all the university math departments just for starters … ) to pay for development? As a result we have no browser that fully supports MathML While you cannot overstate the accomplishments of the volunteer work, it’s im‐ portant to tell the full story Recent cries that Chrome and Safari sup‐ port MathML can give the wrong impression of the potential for MathML when users encounter bad rendering of basic constructs The combination of native MathML support, font support and authoring tools (more on this in a later post) makes mathematical content one of the most complex situations for web typesetting There have been some valiant attempts to fix this lack of equation support with third-party math typesetting code (JavaScript), notably Asciimath by Peter Jipsen with its human-readable syntax and image fallbacks, jqmath by Dave Barton (same as above), and MathQuill However by far the most comprehensive solution is the MathJax li‐ braries (JavaScript) released as Open Source While MathJax is devel‐ oped by a small team (including Frédéric Wang above) they are bigger than most projects, with a growing community and sponsors MathJax renders beautiful equations as HTML-CSS (using webfonts) or as SVG The mark up used can be either MathML, Asciimath or TeX That means authors can write (ugly) mark up like this: J_\alpha(x) = \sum\limits_{m=0}^\infty \frac{(-1)^m}{m! \, \Gamma(m + \alpha + 1)}{\left({\frac{x}{2}}\right)}^{2 m + \alpha} 152 | Chapter 13: Production into an HTML page and it will be rendered into a lovely looking scal‐ able, copy-and-past-able equation You can see it in action here So why is this really interesting to publishing? Well … While EPUB3 specifications support MathML this has not made it very far into ereader devices However MathJax is being uti‐ lised in ereader software that has JavaScript support Since many ebook readers are built upon WebKit (notably Android and iOS apps, in‐ cluding iBooks) this strategy can work reasonably effectively Image rendering of equations in ebook format is another strategy, and pos‐ sibly the only guaranteed strategy at present, however you can’t copy, edit, annotate or scale the equations and you cannot expect proper accessibility with images The only real solution is full equation support in all browsers and ereaders either through native MathML support or through inclusion of libraries like MathJax We can’t anything to help the proprietary reader developments get this functionality other than by lobbying them to support EPUB3 (a worthwhile effort) but since more and more reading devices are using the Open Source WebKit we can influence that directly The publishing industry should really be asking itself why it is leaving such an important issue to under-resourced volunteers and small or‐ ganisations like MathJax to solve Are there no large publishers who need equation support in their electronic books that could step for‐ ward and put some money on the table to assist WebKit support of equations? Couldn’t more publishers be as enlightened as Springer and support the development of MathJax? You don’t even have to be a large publisher to help — any coding or financial support would be ex‐ tremely useful It does seem that this is a case of an important technological issue central to the development of the publishing industry being left to oth‐ ers I have the impression that it is because the industry as a whole doesn’t actually understand what technologies are at the center of their business Bold statement as it is, I just don’t see how such important developments could go otherwise untouched by publishers It could all be helped enormously with relatively small amounts of cash Hire Math Typesetting | 153 a coder and dedicate them to assist these developments Contact Dave Barton or MathJax and ask them how your publishing company can help move this along and back that offer up with cash or coding time It’s actually that simple [Many thanks to Peter Krautzberger for fact checking and technical clar‐ ifications All posts by Adam Hyde are CC-BY-SA.] WYSIWYG vs WYSI By Adam Hyde Since HTML is the new paper and the new path to paper online editing environments are becoming much more important for publishing Dominant until now has been the WYSIWYG editor we all know and … err … love? However the current WYSIWYG paradigm has been inadequate for a long time and we need to update and replace it Pro‐ ducing text with a WYSIWYG editor feels like trying to write a letter while it’s still in the envelope Let’s face it … these kinds of online text editors are not an extension of yourself, they are a cumbersome hin‐ drance to getting a job done Apart from huge user experience issues the WYSIWYG editor has some big technical issues Starting with the fact that The WYSIWYG editor is not ‘part of the page’ it is instead its own internally nested world In essence it is an emulator that, through Javascript, reprodu‐ ces HTML As a walled/emulated garden it is hard to operate on the objects in the garden using standard Javascript libraries and CSS All interactions must be mediated by the editor The ‘walled garden’ has little to with the rest of the page — it offers a window through which you can edit text, but it does not offer you the ability to act on other objects on the page or have other objects act on it Thankfully a new era of editors is here and maturing fast Still in search of a clearly embraced category name they are sometimes called inline editors or HTML5 editors This new generation takes a large step for‐ ward because they enable the user to act on the elements in the page directly through the HTML5 contenteditable attribute That allows ‘the page’ to be the editing environment which in turn opens up the pos‐ sibility for the content to be represented in a variety of forms/views By changing the CSS of the page, for example, we can have the same 154 | Chapter 13: Production editable content shown as multi-column (useful for newspaper lay‐ out), as a ‘Google docs type’ clean editing interface, in a semantic view for highlighting paragraphs and other structural elements (important for academics) as well as other possibilities… Additionally it is possible to apply other javascript libraries to the page including annotation softwares like AnnotateIt or typographical li‐ braries like kern.js This opens up an enormous amount of possibilities for any use case to be extended by custom or existing third-party Java‐ script libraries It is also possible to consider creating CSS snippets and apply them dynamically using the editor This in effect turns the editor into a de‐ sign interface which will open the path for in-browser design of various media including, importantly, ebooks and paper books There are various attempts at the HTML5 editor, which might also be called a WYSI (What you see is) editor The most successful are Mer‐ cury, Aloha and the recent fork of Aloha called WYSIWHAT Each of these are treading their own path but things are really opening up As an example and with reference to the last post I made about Math in browsers, the WYSIWHAT group is making some giant strides in equation editing Their equation plugin which was first built by Mihai Billy Balaceanu at the September WYSIWHAT hack meet in Berlin has since been improved and extended by the Connexions team and the good people at OERPUB (including the talented trio of Phil Schatz, Kathi Fletcher and Marvin Reimer) The plugin was made by including MathJax in the page and allowing the editor to interact with that This was not easily possible with previous WYSIWYG editors The progress on the equation front is looking very good but what this shows more than anything is that by using WYSI editors the entire page is available for interaction by the user or Javascript Anything you can think of that Javascript can you can bring to the editing envi‐ ronment, and that is quite a lot … [Coda: if you are brave and have Chrome 23 installed try visiting BookJS.net, follow the instructions and then visit this demo (it enables content editing of a book and dynamic CSS editing via contenteditable) All posts by Adam Hyde are CC-BY-SA.] WYSIWYG vs WYSI | 155 A Kindle Developer’s 2013 Wishlist By Sanders Kleinfeld 2012 was a good year for Kindle developers With the unveiling of the first-generation Fire tablet in late 2011 and the release of the KF8 Mobi format in early 2012, designing beautiful ebooks for the Kindle plat‐ form became a reality KF8 introduced a fixed-layout specification for Kindle Fire, which opened the door to graphically rich titles — chil‐ dren’s books, graphic novels — in Mobi format KF8 also greatly in‐ creased CSS2 compliance for standard reflowable ebooks, implement‐ ed a handful of CSS3 features (text shadow, rounded borders), and added support for embedded fonts The subsequent rollout of KF8 to Kindle eInk readers running firmware 3.4 (including the new Kindle Paperwhite) and KF8’s support for @media queries to enable fallback styling for non-KF8 devices helped to increase rendering parity within the diverse Kindle ecosystem But while 2012 marks a huge leap forward toward the incorporation of modern Web standards into the Kindle platform, there is still much room for improvement in terms of multimedia/interactivity, content rendering, and ease of ebook development Here is my humble wish list of improvements for the Kindle platform for 2013: Add support for embedded audio/video to Kindle Fire When KF8 was introduced in early 2012, support for audio/video was not included in the format — even though MP3 audio and MP4 video were already supported in Kindle for iOS Nearly 12 months later, the Kindle Publisher Guidelines still read, “Currently, only Kindle for IOS [sic] supports audio and/or video content Kindle e Ink devices and Kindle Fire not support Kindle Editions with Audio/Video.” Given that support for streaming multimedia content via Amazon In‐ stant Video is such a highly touted feature of Kindle Fire, it’s rather surprising that Amazon has not been more assiduously pursuing sup‐ port for embedded multimedia for Kindle Fire ebooks As a result of this discrepancy — Kindle Fire supports KF8 but not audio/video, and Kindle for iOS supports audio/video but not KF8 — there is no single Kindle platform that supports all the ebook features that Amazon offers Those Kindle readers who opt to buy a Fire over an iPad are penalized by not being able to view embedded video in ebooks, and those who opt to instead read their ebooks on Kindle for iOS are pe‐ 156 | Chapter 13: Production nalized with a lower-quality reading experience, as embedded fonts and many key CSS features will not be supported This should be rec‐ tified ASAP Here’s hoping that by this time next year, embedded au‐ dio/video is supported on every Kindle tablet device, and that KF8 is supported on Kindle for iOS Add KF8 support for MathML High-quality typesetting of mathematical equations is a challenge in most digital formats, and Kindle is no exception Because Kindle’s KF8 format does not support MathML (a XML vocabulary for markup of math content that is part of the HTML5 specification and supported to varying degrees in different desktop and mobile Web browsers), the only viable typesetting option for including complex equations, ma‐ trices, etc., in ebooks is to embed the math content as images However this approach is far from ideal, because when implemented as images, mathematical equations are not searchable or resizable by readers Optimizing image size can also be challenging See the Kindle Paper‐ white screenshot below featuring two equation images scaled to the same size, which results in the longer equation (bottom) being more heavily “shrunk” than the shorter equation (top) A Kindle Developer’s 2013 Wishlist | 157 Figure 13-6 Two probability equation images rendered on Kindle Pa‐ perwhite, the bottom equation shrunk more than the top equation Adding MathML support to KF8 would remove the burden for equa‐ tion sizing and resolution from publishers and developers, and place it on the ereader’s rendering engine, where it belongs As Adam Hyde notes in his TOC post on math typesetting, the current state of MathML support in browsers and on the Web is rather woeful, forcing reliance on third-party libraries like MathJAX to correct and normal‐ ize rendering But this presents a huge opportunity for ereader vendors 158 | Chapter 13: Production like Amazon Adding robust MathML support may provide a com‐ petitive advantage in the likely-to-grow ebook marketplace for math and science textbooks iBooks already provides limited MathML sup‐ port via its WebKit engine; your move Amazon! Add a Monospace Default Font to Kindle Paperwhite The Kindle Paperwhite ereader contains six system fonts: Baskerville, Caecilia, Caecilia Condensed, Futura, Helvetica, and Palatino None of these is a monospace font Monospace fonts are critically important for technical-book publishers, because elements such as code listings and ASCII art must be formatted such that every character is of equal width, in order for them to render properly Because Paperwhite supports the KF8 format, Mobi developers can embed their own monospace font if their content requires it (O’Reilly embeds the Ubuntu Mono font family in its Mobis) However, by de‐ fault, Kindle Paperwhite has Publisher fonts turned off, so readers must navigate to the Kindle font menu themselves and enable the Publisher Font option — which they may not know they need to Compare the rendering of the code block below on Kindle Paperwhite with Publisher Fonts turned on (left) and Publisher Fonts turned off (right): A Kindle Developer’s 2013 Wishlist | 159 Figure 13-7 The same code listing displayed on Kindle Paperwhite, with Publisher Fonts turned on (left) and Publisher Fonts turned off (right) Kindle customers shouldn’t have to be educated to enable Publisher Fonts to ensure monospace content is displayed properly, and pub‐ lishers shouldn’t be required to embed additional fonts (which bloat Mobi file size) to enable monospace functionality Ereader vendors should provide a rich set of system fonts, optimized for their rendering engine, that meet the needs of publishers of fiction, technical reference books, or anything in between Both legacy eInk Kindle devices and the Kindle Fire have monospace system fonts; please extend this sup‐ port to Paperwhite as well Add more granularity to @media query support One of the best CSS features added to KF8 was support for two specific @media queries: @amzn-kf8 and @amzn-mobi These two queries al‐ low Kindle developers to segregate their CSS so that styling that takes advantage of KF8 features (in an @amzn-kf8 block) is ignored on leg‐ acy Mobi7 Kindle ereaders, and fallback styling (in an @amzn-mobi block) will be used instead on the legacy devices This @media query support was a boon when Kindle Fire was the only device in the Kindle family that was KF8-enabled, because you could use @amzn-kf8 to specify not only KF8-specific features, but also four160 | Chapter 13: Production color-specific styling for Fire tablets that would be ignored on the black-and-white devices However, now that eInk readers like Kindle Paperwhite also support KF8, they also use the CSS specified under @amzn-kf8, which means it is not possible to target CSS for the tablet readers and provide graceful degradation for eInk See the screenshots below, which show the same syntax-highlighted code example sideby-side on Kindle Fire (left) and Kindle Paperwhite (right) Figure 13-8 Rendering of syntax-highlighted code listing on the fourcolor Kindle Fire tablet (left) and the eInk Kindle Paperwhite (right) I’d love to see support added for @media queries such as @amznkindlefire, @amzn-kindlepaperwhite, and so on, so that Kindle de‐ velopers are better able to tailor Mobi content to the unique capabilities of each ereader (This would be an equally welcome feature for other ereader platforms that encompass both eInk and tablet devices — e.g., NOOK, Kobo.) Add a “View Source” option to Kindle Previewer Kindle Previewer is an excellent emulator that allows you to quickly review how a Mobi file will display on all major Kindle platforms (see screenshot below) A Kindle Developer’s 2013 Wishlist | 161 Figure 13-9 Kindle Previewer for Mac in Paperwhite Mode But one thing you can’t in Previewer is inspect the underlying HTML/CSS source code to debug any rendering oddities that may be 162 | Chapter 13: Production present There are tools available, such as mobiunpack, which you can use to crack open a Mobi file and see the source, but they are neither especially convenient nor user-friendly Having “View Source” func‐ tionality built into Kindle Previewer would be a huge timesaver What features are on your 2013 Kindle developer wishlist? Hit the comments and share your requests I’d love to have put “EPUB support on Kindle” at the top of my wishlist, but sadly I don’t see that being a realistic request A Kindle Developer’s 2013 Wishlist | 163 ... the future and stay informed oreilly.com /toc ©2013 O’Reilly Media, Inc The O’Reilly logo is a registered trademark of O’Reilly Media, Inc 13124 Best of TOC, 3rd Edition O’Reilly Media, Inc Best. .. new piece of software when the core concept needs proof from the user to evolve — or where there needs to be a very direct and engaged relationship between the producers and users of a particular... adaptability through‐ out the life-cycle of the project At the end of the day, it’s about getting something out there that we can test and learn from How agile methodologies apply to publishing? Kristen