Google Book Search: It's All About the Index

Mac Slocum
June 30, 2008 | Permalink | Comments (0) | Listen

Adam Hodgkin says the grand design of Google Book Search is aimed at creating a massive index, not an all-encompassing, locked-down reading system. From Exact Editions:

Some of Google's critics suppose that the aim of the GBS [Google Book Search] project is to capture, corale [sic] and deliver to readers the whole of the world's literature in a readable format. But perhaps the business goal has all along been to produce a complete searchable index of literature, not the monopolistic reading medium. [Bold text included in original post.]

Google's initiatives have always focused on the creation and expansion of digital content platforms rather than individual content products. The public's mistaken focus on Google products -- rather than Google platforms -- was noted in Wired's recent story about Google's mobile project, Android:

Those hoping for a new gadget to rival the iPhone finally understood that Google had something radically different in mind. Apple's device was an end in itself -- a self-contained, jewel-like masterpiece locked in a sleek protective shell. Android was a means, a seed intended to grow an entire new wireless family tree. Google was never in the hardware business. There would be no gPhone -- instead, there would be hundreds of gPhones.

I can understand where the confusion comes from: The creation of a gargantuan reading service seems to be in Google's wheelhouse because they're one of the few companies that can actually attempt such a project. But as we learned with Android, Google isn't a product-centric company -- all those individual tools and services plug into bigger platforms. Development of a searchable full-text book index that can be distributed across all sorts of devices is more in line with Google's history and its focus.

Related Stories:

• Calling Google a Publisher Underestimates its Platform
• Google Taking Long View on Book Search
• A Glimpse into Google's Book Scanning
• Google Opens Book Search with API
• Amazon Ups the Ante on Platform Lock-In

Calling Google a Publisher Underestimates its Platform

Mac Slocum
June 19, 2008 | Permalink | Comments (0) | Listen

Google has never positioned itself as a publisher, but a recent News.com piece looking at Google's role in Web advertising says the company's 2006 YouTube acquisition moved Google into the publishing space:

Google itself is a publisher, at least in one sense: it offers countless videos through [its] YouTube service. So Google has more incentive than just its DoubleClick division to improve display advertising.

YouTube is certainly content-centric, but Google didn't pay $1.65 billion for all those videos. It shelled out big bucks for YouTube's audience and, more importantly, its platform.

Publishers tend to see the world through singular products -- books, newspapers, magazines, Web sites -- but platform companies, like Google, see these same products as an aggregated stream of general content that needs to be delivered. If you control the delivery mechanism, you can mine it for revenue -- something Google has already done through its AdSense and AdWords programs, which piggyback on Google's search tools to deliver contextual advertising. Now that Google has monetized and claimed the Web search market, the company is expanding its platform into harder-to-crack content spheres: books, TV, and radio. This is why Google Book Search isn't just an archive. It's a content pipe that plugs into Google's overall architecture.

Google clearly recognizes that its platform is only effective if it serves up useful material, as illustrated in this passage from the same News.com piece:

People are consuming more and more media on the Internet but paying less and less, [Google Chief Exec Eric] Schmidt said. "That's bad for Google. We are critically dependent on high-quality content," he said.

Publishers are experts at producing the content Google needs, but incorrectly labeling Google a publisher -- and, ostensibly, a competitor -- obscures the essential relationship between Google and actual publishers.

So, in an effort to keep publishers on target in the platform discussion, here are a few top-level items to consider:

Identify the platforms -- Platform companies are focused on distribution, both through their own Web properties and via underlying delivery technologies. They may own popular Web sites that generate revenue through some forms of content (e.g. YouTube), but their real interest lies in aggregating and disseminating material. Google is the big platform provider, but Facebook and Amazon are both making moves into the platform arena. Even if you ultimately dismiss a particular company, it's still important to competitively -- and correctly -- identify its platform moves.

Consider how your content can be delivered through available platforms -- Look at user patterns. Ask yourself: How do people use these platforms to find and consume content? How are other companies effectively delivering their material? The newspaper industry offers an important case study for this point: It initially relied on subscription models for its Web content, but in recent years many papers have removed subscription restrictions so each article can be discovered -- and mined for ad revenue -- through Google and other search platforms. The industry is finally working with user behavior, not against it.

Look for revenue streams -- We've recently harped on the importance of tie-backs and analytics in digital experiments, and those same warnings apply here as well. If you're going to distribute your material through a platform, you need to have revenue streams in mind. This could take the form of advertising, affiliate relationships, trialware, or links/call-outs to upsell products. It could also be part of a larger branding campaign.

Add open formats to the production process -- Google is a massive platform player, but the Internet's open and distributed infrastructure allows other companies to develop their own platforms. Publishers looking for platform-friendly positioning can take advantage of future platforms -- including those not yet envisioned -- by incorporating open formats (XML, HTML, RSS, EPUB, etc.) into their production processes. There's no reason to gamble on proprietary formats and exclusivity because the big platforms, and the smart platform companies, will use methods that have already been adopted by the widest possible audience. And if a closed format does reach critical mass (iTunes and AAC, for example), commonly used open formats will be incorporated into conversion tools and projects.

These general points require deeper contextualization for particular companies and initiatives, and the business threats presented by large platform companies need to be rationally examined and acknowledged (particularly, centralization and lock-in). Nonetheless, publishers need to recognize that misrepresentations are where the real threat lies. Incorrect platform assumptions limit the significant opportunities.

Related Stories:

• Long Tail evidence from Safari and Google Book Search
• Treating Ebooks Like Software
• The Pitfalls of Publishing's E-Reader Guessing Game
• Amazon Ups the Ante on Platform Lock-In

Q&A; with Susan Danziger, CEO of DailyLit

Mac Slocum
June 18, 2008 | Permalink | Comments (0) | Listen

DailyLit is a digital service that delivers short, scheduled book installments to subscribers by email and RSS. The company offers free and pay-per-read titles in plain text, which makes them accessible through nearly all email clients, browsers or mobile devices. In the following Q&A;, DailyLit CEO Susan Danziger discusses the company's philosophy, process, and upcoming services.

How many titles do you offer through DailyLit? How many do you hope to have by the end of 2008?

We currently have over 950 titles (450 or so which are available on a pay-per-read basis), and by the end of this year, we're targeting several thousand pay-per-read titles.

Releasing titles in plain text seems like a simple way to avoid the formatting needs and device restrictions that come with proprietary ebook formats. Was this your intention, or was plain text just an easier way to get started?

It was definitely our intention to allow the installments to come in on any device, which is an important part of how we designed the experience. We started with plain text because it was the easiest to implement, and we will be launching HTML shortly as well.

Do most DailyLit users read installments on mobile devices?

10%-20% of our readers currently read their installments on mobile devices, but as the reading quality on mobile devices improves (the iPhone is a great start), we're confident that more and more people will be reading their installments on these devices.

Can readers purchase print editions or ebooks through the site/service?

At this point, only DailyLit editions are available. We're starting to allow publishers and others to sponsor certain titles, which would allow a link to purchase other editions. With this sponsorship model, instead of readers paying for the title, sponsors would pay for them instead.

How will the sponsorship model work? Also, in regards to "other editions," are you only referring to printed editions, or does this include different ebook formats as well?

DailyLit readers would have access to free DailyLit versions of the books under the sponsorship model. Sponsors of titles would be able to include links that would lead to their sites (or other sites that sponsors indicate). "Other editions" could be printed editions or other digital formats.

How many DailyLit users receive updates via email? How many via RSS?

About 90% of our readers receive installments via e-mail; 10% via RSS.

How much time goes into prepping books for delivery? Is production handled in-house?

The production time depends on the format in which the book is delivered. If the book is delivered in PDF, the production time can be up to eight weeks. We prefer it if books are delivered in EPUB or XHTML, which greatly reduces the production time, not to mention cost. Production is handled in-house for certain titles, but for most titles we use an outside production house.

How are installments defined? Is it by word count? Average reading time?

Installments are usually around 1,000 words, which is under five minutes of reading. If a chapter is about to end, we'll adjust the length of the installments accordingly. Certain books, such as books of quotes, have much shorter installments. Under the "Manage Your Subscriptions" feature, folks can personally adjust the length of each installment (to 2 times or 4 times the length), so an avid reader can read more.

Are fiction titles the easiest to serialize, or does any chapter-based book work?

Fiction titles are probably easier to serialize since they're more straight forward. With non-fiction titles, we need to account for footnotes and other ancillary materials. That said, we're featuring titles from all different genres, from science fiction, such as books by Cory Doctorow, to such non-fiction best-sellers as Skinny Bitch. We also feature language books, such as titles from Berlitz, business books, as well as romance titles from Harlequin.

What types of books don't lend themselves to serialization?

Reference books that readers do not want to read cover to cover don't work in serialized form. Apart from that, since DailyLit is intended for those readers too busy to read (or who want to sneak in an extra book during the day), any other kind of book works well. After all, folks are avidly reading War and Peace, Moby Dick, The Art of War and Pride and Prejudice, and none of these books were originally intended to be serialized.

Who sets the pricing for titles?

Since we've structured this as a licensing deal with publishers, DailyLit sets the price.

Are you licensing a specific version of a book (i.e. "text-only" or a particular ebook format)?

We characterize it as "digital serialization rights" so it's a combination of serialization (typically understood as a license) and a digital rendition of the book. Depending on rights available for the title, we might license text only or with illustrations/photographs.

How have publishers responded to DailyLit?

We've had a great response from publishers. On the whole, they've been really excited about this new format, which combines marketing and potential incremental revenue. We've also been developing innovative technology -- several initiatives will be rolled out shortly -- which will help the publishers market their titles and expand their reader base.

What sorts of tools will you be releasing?

One such tool is public subscriptions, which will allow publishers, authors or third parties to serialize a book publicly on their site. Each day on that site, folks will be able to view a new installment of a book. This is a way to build community on their site and would be an alternative to giving away free PDFs of books. We'll also offer readers the opportunity to receive a personal e-mail or RSS subscription to that title if they don't want to return to the site each day, but for that they [consumers] would need to pay. As such, it's a neat viral marketing tool as well as having potential for incremental revenue.

Do you use digital rights management (DRM) on titles?

We put the reader's experience first, which means that there are no attachments or files that need to be opened with a special device or software. With respect to illustrations or photographs, we are able to track where they go and, in the event of a hot link, we can disable use of an illustration associated with a particular subscription.

Have you run into any piracy issues? Is this a concern?

We haven't run into any piracy issues. Since books are divided into hundreds of installments, there is less concern that individual installments are copied or forwarded. In fact, any installments forwarded by readers have been viewed by publishers and authors as a way to virally market their titles.

In addition to books, you feature Wikipedia tours, language lessons and SAT prep. Are other non-book projects in the works? Where do you see DailyLit expanding?

We're in the process of adding newly created titles for DailyLit, including allowing authors and publishers to create content that work well in the serialized format. We're also developing lots of interesting technology to help market books and expand the current reach to additional readers. For instance, we recently launched via Twitter a group read or virtual book club so that folks can read books according to the same schedule. Folks can sign up now to participate.

Related Stories:

• Ebook Format Primer
• Treating Ebooks Like Software
• What Would Your Ideal E-Reader Look Like?
• Ergonomics and Ebook Success

Release Early, Release Often: Agile Software Development in Publishing

Liza Daly
June 12, 2008 | Permalink | Comments (0) | Listen

"How do Web startups release three or four new versions of a product in the time it takes publishers to launch just one new feature on their online platforms?"

This question framed "The Agile IT Organization," a lively and well-informed discussion at the recent Society for Scholarly Publishing annual conference in Boston. As a software engineer, I've used both agile and traditional product development methodologies and I was interested to hear the perspectives of other programmers as well as publishers who've gone through the process.

Geoffrey Bilder of CrossRef provided an introduction to agile development practices, which are concisely summarized in plain English by a core set of principles.

Summarizing even further, agile development means:

1. Minimal up-front specification. A project has high-level goals (e.g. "make our back catalog searchable and available for print-on-demand purchase"), but is not fully described before development begins.
2. Frequent, short-cycle releases. A project is broken up into mini-projects, each with a small set of features that take only a few weeks to implement. Every release ("iteration") has a specification, development and testing phase. This means that every couple of weeks the software is fully usable, although it may have very few features at the start.
3. Change to the product design is accommodated and even expected. Market conditions, corporate re-organization or user demands may mean that new features are added or old ones are re-worked. Changes are treated as just another iteration.

The panel at SSP focused on two approaches: internal, IT-driven products, and those developed by a third-party vendor. Larry Belmont, manager of online development at the American Institute of Physics, gave an excellent presentation on the in-house approach. His organization ran its first agile project with a timeline measured in days rather than weeks or months.

Leigh Dodds, CTO of Ingenta, provided the vendor perspective, and described the principles of a formal type of agile development known as Scrum.

The panel was, to their credit, enthusiastic about the approach, but agile development requires commitment and is not right for every organization or project. Some caveats that need to be emphasized:

• Short development cycles come with a price: you will be asked to review and comment on small pieces of the larger project, and be involved on an almost daily basis. Many publishers need vendors they can treat like plumbers: "I want a new sink put here, it should look like this, call me when it's done." If someone in your organization isn't prepared to think very hard every day about copper pipe fittings, agile isn't right for you.
• Project managers must be empowered to make decisions. Whether the project is in-house or vendor-driven, every day the PM will be asked to make calls without appealing to higher powers. When editorial buy-in is required, or when the product needs a larger review, consider a hybrid approach: appoint a single decision-maker with deep editorial knowledge to work on evaluating, testing and approving each iteration, but use a more traditional alpha/beta/gold release process for the wider group.
• Product features may change, but time and budget should be invariant. Hard deadlines might seem to be antithetical to the free-wheeling, change-friendly agile approach, but in my experience they're critical. They focus the entire team: key decision-makers cannot spend weeks in committee, IT personnel don't fear the "death march" project with no end in sight, and it's more difficult to introduce budget overruns that cause friction with management and vendors. If an agile project does run out of time, you will still have a launchable product that's been thoroughly tested and reviewed all the way down the line, not something just out of beta with weeks of QA ahead. Many agile methodologies use the hard deadline, or timebox, as the primary method of structuring the project.

"Release early, release often" can sound a lot like "throw whatever we've got out the door." This is one reason why the iterative approach has been so embraced by Web startups: each small release has been thoroughly tested and evaluated, and there's never a moment where the software doesn't work. It's possible to to go live with a project that might not be "finished" according to the original master plan, but might otherwise be caught up in insurmountable technical hurdles or tied up in editorial review.

If publishers are going to be ready for an "iPod moment," this kind of flexibility and responsiveness is critical.

Related Stories:

• Targeting Small Companies with Small Products
• Publishing Industry Not Prepared for "iPod Moment"
• Tutorial: Add AB Meta Tagging to Your Blog
• Ebook Format Primer

Open Question: What is the Best Use for Print on Demand?

Mac Slocum
June 11, 2008 | Permalink | Comments (5) | Listen

PublicAffairs Books recently used POD services from Lightning Source to manage demand for Scott McClellan's What Happened: Inside the Bush White House and Washington's Culture of Deception.

From a Lightning Source press release (pdf):

PublicAffairs' experience with this title demonstrates how POD can be used to supplement offset printings in specific cases in which demand exceeds supply for a short term. In this instance, the POD copies of the book will supplement large scale conventional offset reprints, which are underway.

PublicAffairs used POD as an insurance policy, and panelists in a Digital Custom Publishing session at BEA also noted POD's use in short runs, niche titles and its importance as a Long Tail tool.

But do insurance policies, niche books and Long Tail plays represent the extent of POD's opportunities? What options do you see for POD? How have you used it in your own organization? How will POD evolve? Please share your thoughts in the comments area.

Treating Ebooks Like Software

Mac Slocum
June 5, 2008 | Permalink | Comments (3) | Listen

Peter Kent, DNAML's senior vice president for U.S. operations, brings a software-centric perspective to ebooks. In the following Q&A;, Kent discusses the merits of in-book transactions, affiliate marketing, and other digital initiatives that can benefit book publishers.

Q: In your presentation at last month's IDPF Digital Book '08 you discussed treating ebooks like software. Do you feel the software model is directly related to ebooks, or are there specific aspects of the software model ("try before you buy" trialware, download ebooks through multiple outlets, etc.) that are more in line with ebook/publishing goals?

Not sure of the distinction you're making here. I think that there's much about software distribution that applies to ebooks, and why not? Ebooks are, of course, pieces of software. In particular, providing ebooks in a trialware format makes a lot of sense, and is a proven model. That's why Amazon let's people view a portion of a book, that's why Barnes & Noble likes having people in their stores hanging out reading. And of course, download through multiple outlets makes a lot of sense, too. Why wouldn't you distribute your products as widely as possible? If trialware works -- and it does -- then you naturally want as many people as possible to get the books in their hands. The large, established publishers are going to have a shock when they see the new book-distribution world. It's no longer a gentleman's game in which everyone hands over their books to a bookstore, and then they all compete on the same level. In the future the more aggressive publishers are going to go out and find book buyers even before the buyers have thought about buying!

Q: Do publishers focus too much on the "book" aspect of ebooks? Would a shift toward a file/software perspective open things up?

Some do. The more advanced publishers understand what's going on, but I do think there's still a bias toward the old method of distributing books: give your books to a retailer who puts the books on shelves. Certainly up until recently most publishers have had the idea in their mind that in order to sell ebooks they have to create the ebooks and then give them to Amazon and other retailers to sell. Little thought has gone into new methods of distribution. What may save the publishers is that new distributors will come on the scene: distributors who understand the new landscape and go out and push the books.

Q: Are ebooks available through sites like Download.com, Tucows.com and other software-specific hubs? If not, should they be?

You can already find ebooks in many software download sites, though most do not yet have specific ebook categories. ZDNet's download site doesn't have an ebook category, for instance, though it does have an ebook "tag." Download.com has a music category and a games category, why wouldn't they have a book category? Of course they will eventually, as more and more books become available. But one thing holding back the creation of ebook categories is that only free books, or trialware books, will fit. Once books from major publishers are commonly sold as trialware, you'll see the download sites pay more attention.

Q: What about ebook availability through P2P sites/mechanisms, such as BitTorrent?

Trialware books are perfect for this form of distribution.

Q: In your conversations with publishers and others in the industry, do you feel most people understand the basics of internal ebook transactions and affiliate tagging? How do you describe these concepts to newcomers?

Most publishers haven't the slightest idea about this. When I ask publishers "do you know what affiliate marketing is?" I typically get a response such as "um, well ...". So if they don't understand what affiliate marketing is, they certainly don't understand affiliate tagging. This isn't true of all publishers; Harlequin, for instance, is really good at online marketing, and certainly understands affiliate-marketing well.

So, how do I explain these things? Well, by internal transactions, I mean that each ebook is its own shopping-cart system. You reach a point inside the book that you cannot get past without paying. You enter your credit card information into the book itself (though the actual form is retrieved from a server so, for instance, the book price can be changed at any time), and when you submit your card and it's approved, the server automatically unlocks the book, so you can continue reading.

As for affiliate tagging, this is the ability to add a code to each book you distribute -- one code for each specific distribution channel -- so the publisher or distributor knows where that book came from. If you distribute through Web Site A, 10,000 people download the book, and 500 buy it, you know that those 500 people came from Web Site A. If you put the book in a magazine insert, 100,000 people buy the magazine, 10,000 copy the book to their computers, and 500 buy it, then you know that those 500 customers came from that particular magazine insert. Thus you can pay the right company the required affiliate commissions.

So these two components, along with the ability to partially lock a book, allow you to create trialware books -- try-before-you-buy books -- that can be distributed widely, through many different channels.

Q: Is there an opportunity for competing publishers to generate affiliate revenue by selling other publishers' books?

Absolutely! Books can be bundled within books -- certainly our DNL format allows this -- so a publisher might bundle several locked books at the end of the book. Those books might belong to the publisher or, in appropriate cases, from another publisher. In particular, of course, small publishers could benefit from these sorts of relationships with other publishers.

Q: What is the upside of "try before you buy" in ebooks?

A try-before-you-buy book with built-in transaction processing, and built-in affiliate tagging, opens up a whole new world of distribution options. All of a sudden, the book can go anywhere. Sell computer books? Talk with computer manufacturers about putting your books on the desktop of every new computer sold, and talk to software manufacturers about bundling the books in their software downloads. Sell photography books? Put them on the software CDs inside digital-camera packaging. Sell wine books? Give away try-before-you-buy books on wine Web sites. Science fiction novels? Give books away on fan sites. Those three things -- try-before-you-buy, internal transaction processing, and affiliate tagging -- free books from ecommerce Web sites, and provide almost limitless marketing opportunities.

Q: What viral/social aspects does your company include in ebooks? (Email to a friend, etc.)

We include Email-to-a-Friend, of course. If you try a book, like it, and buy it, that book is now unlocked. But if you email it to a friend or colleague, when it lands on the recipient's computer it's now locked. Word of mouth is hugely important in book sales; it always has been. Email-to-a-Friend is essentially a modern-day word-of-mouth feature. We also allow people to share notes. Members of a book club could highlight areas of the books, add notes, then email the highlights and notes to each other. Members can import these things, and see who said what based on the name at the top of the notes.

Q: Are ebook giveaways useful?

Of course. Companies such as Harlequin use giveaways to build interest. I think, though, that these giveaways will get more sophisticated, as publishers learn more about try-before-you-buy books. For instance, if you're giving away a book, you're hoping that the reader will come to your site and buy another one at some point. But why not create a giveaway book, a single file, that includes a book for sale at the end of the free book? Or several books from which the reader can choose?

Q: Do you recommend user tracking and registration? How in-depth should this tracking/registration be?

Of course you want as much information as possible; we're in business, after all, so we need to create relationships with buyers. Amazon does this. I like to point out to publishers that someone owns the relationship, it's just not them. If you sell photography books and someone buys one of your books through Amazon today, tomorrow Amazon will start promoting other photography books to this buyer. Some of these books will be yours, perhaps, but most won't! So Amazon's tracking, and Amazon's benefiting. Publishers are going to learn to do the same for themselves, and some already are.

Related Stories:

• This Way to the Egress, er, Ebooks
• Author Notes Risks and Opportunities in Free Ebooks
• Open Question: When Will Digital Books Overtake Print Books?
• Commentary on Penguin's Missed Ebook Opportunity

Publisher Offers Tips for Embedding Web Links in Ebooks

Mac Slocum
June 4, 2008 | Permalink | Comments (4) | Listen

Morris Rosenthal, owner of Foner Books and author of the Laptop Repair Workbook, is blurring the line between books and Web content by embedding clickable hyperlinks within the margins of his PDF-based ebooks. Rosenthal discusses his linking process in the following Q&A.;

Q: What inspired you to insert links into your ebooks?

I was forced into large margins for the Laptop Repair Workbook due to the flowcharts that make up the meat of the book, and I'm not sure it would have occurred to me to include the links if I hadn't been staring at all that white space.

Q: Do you recommend inline links or links in the margins? Is one form or the other easier, from a production standpoint?

For a large size book, 8.25 X 11 or 8 x 11, I think links in the margins make the most sense because they can do double duty as design elements. Since the ebook is printable and since most people will be printing on letter size paper, I kept the design nearly identical to the soon-to-be released paperback version. Inline links would be much easier from a production standpoint, but they would tend to interrupt the reader, making people stop and think "should I click on this?" In the margins, they are clearly labeled as supplementary illustrations of procedures. And since the printed book requires full URLs to be shown, it would make the text pretty ugly to show them inline. For the ebook, I could have hyperlinked words without showing the URL, but again, the ebook is printable, and seeing that some words are underlined in blue doesn't get anybody anywhere.

Q: How much time did it take to create separate Web pages and insert links into the Laptop Repair Workbook?

Around half of the Web pages were created before I even started on the book. But in general, a photo illustrated page takes anywhere from a few hours to a day to create. A test procedure takes longer, as there's quite a bit of experimentation behind any given test.

Inserting the 25 or so links, once I settled on the large-margin format, only took a couple hours. I used the text box tool in Word.

Q: Are you able to track visitors from the links?

No. I suppose it would be possible to add an extra anchor argument that would separate the PDF visitors from direct traffic and bookmarkers, but I haven't done it. I wouldn't be surprised if there are more sophisticated ways to identify visitors through links, and it certainly would have been possible to link to duplicate pages that are excluded from spidering, but I didn't see a reason.

Q: Do you think embedded links help thwart or offset piracy?

I don't think anything short of full DRM helps to thwart piracy, and then, it's really a question of thwarting casual vs professional pirates. The embedded links may help offset some unauthorized distribution in two ways:

First, anybody who clicks on the links will find out that there's a book for sale, and that might be the first time it hits them that the file they downloaded from site X or received as an attachment from a friend is really a published book that they haven't paid for.

Second, if the links aren't carved out of the PDF, they should help the search engines keep track of who the originator is, if the PDF should end up hosted for a while on a university domain or other authoritative site. When I published ebooks a few years ago through Lightning Source, I went with full DRM primarily to impress upon the customer that the ebooks were a commercial product protected by copyright law. This time around, I've gone with no DRM beyond my embedded copyright notice, but I do send customers through a click licensing agreement.

I should mention that shortly after the New York Times quoted me and mentioned the ebook in an article on laptop repair, I saw signs in Google that some people had been checking filesharing networks for it, as the queries sometimes result in an indexable page. While I take my copyright rights seriously and have the Federal court experience to prove it, I know that the majority of my potential customers will only find out about the ebook through visiting my site, and I'm sure most of those who are willing to pay for an ebook will get it from me. I don't think that most people go trawling through pirate sites when they're looking for a book, but maybe I'm out of touch. I did get some grief from customers during my full DRM years, and while I'm not a knee-jerk "customer is always right" type, I understand that customers have a valid point of view that a publisher ignores at his peril.

Q: What's the upside to embedded links?

For the reader, there are multiple upsides. I'm able to illustrate troubleshooting and repair procedures on my Web site with color photos, updating them at will, without having to charge an arm and a leg for the book ($24.95 paperback, $13.95 ebook). While I could have embedded quite a few photographs in the ebook, most of them would have been irrelevant for any given reader with a different laptop model, different problem, or information that they already knew. When all of those illustrations appear in a book, the customer is paying for them one way or another, and many publishers (especially of textbooks) load up on color pictures just as an excuse to up the price. In this case, it's all supplemental material, a fraction of which may be useful for most readers, but none of which is necessary for core troubleshooting procedures of the text and flowcharts. And from a practical standpoint, I'm able to create a larger number of illustrated procedures because the standard of photography and editing required for a Web page isn't the same as for a book, or ebook.

Q: Any downside to linking?

The only downside I can see is if some readers conclude that the links represent material that has been left out of the book, and that the links are a sorry excuse to make up for it. The book simply wasn't designed that way, but you can't please everybody.

Q: Do you have any formatting best practices?

I did keep all of the links in the root directory of my fonerbooks.com domain, and all of the file names are less than eight characters, though in truth, that's an artifact of doing most of my Web design with my old GNN Press editor (thanks O'Reilly) from 1995. Since the links appear in the margins, I ended up breaking them over two lines, with the domain on the first line and the filename on the second line. I could have force-fit them on a single line; it was just a visual design decision.

Q: Will links be a standard part of your future books?

Certainly a part of future ebooks. For print books, it would depend on whether there was a large enough amount of supplementary material on my Web site to justify a page layout that supported links.

Related Stories:

• Linking Books with the Web-Way of Thinking
• Adobe Eyes Interactivity in Ebooks
• Think Digital and Get Accessible for Free
• Open Question: When Will Digital Books Overtake Print Books?

Open Source DocBook XSL Experimental EPUB Support Released

Andrew Savikas
June 3, 2008 | Permalink | Comments (3) | Listen

Publishers with content in DocBook XML format can now easily create EPUB files using the open source DocBook XSL package (which already supports output to HTML and to XSL-FO -- a format that can be turned into PDF -- along with several other formats). Here at O'Reilly we've long used DocBook as the format for Safari Books Online, and more recently been using it more for standard book production (rather than converting to XML from a format like FrameMaker).

The 1.74.0 release is experimental, and additional feedback would be a big help for improving the output. From Paul Norton at the Adobe Digital Editions blog:

The ePub target has been tested against a number of files, but I would encourage those of you who use DocBook to try out the new target and to submit any issues you find to the tracking system on the DocBook project site. The only way we'll know if it doesn't work for you is if you tell us. :)

My personal thanks to Keith Fahlgren for driving the development of the ePub target and basically making it happen.

I'll second the thanks to Keith (an engineer here at O'Reilly) for his work on the project, and also extend the thanks to Paul and to Adobe for their contributions.