CARVIEW |
An XML workflow presents enormous opportunities for smart publishers, but those opportunities come with serious challenges that require much more than just new technology to overcome.
StartWithXML is an industry-wide project to understand and spread the knowledge publishers need to move forward with XML. It's about the business issues driving the "why" of XML and the technical and organizational issues, strategies, and tactics underlying the "how" of getting started. There are four components to the project:
An online survey meant to capture a broad overview of the issues surrounding the subject.
A research report that will include information, case studies, best practices, technology and vendor profiles, and interviews discussing the factors that make a "StartWithXML" workflow both useful and tricky.
A one-day forum scheduled for Jan. 13, 2009 at the McGraw-Hill Auditorium in New York. Through panels and presentations, you'll spend the morning understanding the "Why" of XML, and the afternoon learning about "How" to move forward. Space is limited.
Online Conversation and Community
An online conversation and community, including a blog, an open comments section for the report outline, and a discussion forum.
StartWithXML Blog:
Chunks and Verticals and Niches -- Oh, My!
Laura Dawson
September 17, 2008
| Permalink
| Comments (2)
|
Listen
Despite the bell tolling on the publishing industry lately, the publishers who are doing well these days are those who have focus. Publishers who have a consistent message, who create content about specific things, seem not to be paddling the lifeboat with broad, generalized trade publishers. Niches, areas of concentration -- call them what you will, but this is where the future of publishing lies. Just as cable TV brought about a revolution in video consumption -- movies on this channel, comedy on this other one, news on this third one -- digital distribution has brought about a revolution in publishing. It's just a question of understanding where the ground is moving under your feet.
Digital tools -- such as e-books, book trailers, widgets, what have you -- are just that: tools. They are no substitution for product -- nor will they sell a product that doesn't deserve to be sold. Funneling money into "digital initiatives" is wasting money -- unless those initiatives are clearly defined.
How to define them? How to read the tea leaves and figure out what initiatives actually make sense and which are a money pit?
The StartWithXML team has looked at XML itself for guidance. XML tools allow people -- editors, authors, production teams -- to "componentize," to break content down into irreducible parts, to re-use those parts, to publish content more than once. If your book content is sufficiently tagged, you can re-use it early and often.
I think about one of my favorite authors, Wayne Dyer. He writes his books. From those books are generated calendars, one-a-day cards, daily journals, audiobooks, supplementary materials (such as meditations). If Hay House felt like it, they could send an email containing an inspirational quote to my inbox every morning. Dyer writes once. But Hay House publishes his stuff many times over, in many different formats. If he feels like doing more, they provide him with a platform for podcasts, conferences, interviews, and opportunities to preface or foreword other Hay House authors' books.
Doing these sorts of tricks -- and creating loads of interesting and compelling products almost as byproducts of your original content -- is much easier and cost-effective if you're already using XML. The "chunks" of content are pre-defined. You don't have to make iterative runs at the original manuscript and figure out what can be re-used; you know from the get-go what you WILL re-use.
This is not anti-literary. It's pro-keeping-your-publishing-house-in-business. And the sooner trade houses realize what their verticals actually are, and pursue them with the savage focus that the niche publishers do, the sooner everyone is happy: the consumer, who gets loads of content; the author, who gets loads of royalties; and the publisher, who is squeezing every last penny out of each word the author writes.
Related:
Can the Author Really Help?
Mike Shatzkin
September 15, 2008
| Permalink
| Comments (2)
|
Listen
A very experienced former book packager who has moved on to become an industry observer and critic of some note pushed back on my suggestion on Friday that authors could be involved in tagging content for contextual meaning. "Not in this lifetime," was his comment, and he suggested that copy editors or managing editors might be the more likely candidates to mark what we're looking for.
Among other things, our critic suggests that the usual consequence of having an author mess with the code is that the next job the packager or publisher has to do is pull out a lot of not-useful clutter.
What are we looking for? We want the biographies within a historical book that are used to introduce the characters. We want the place descriptions from any book -- many from novels -- that would be of interest to anybody visiting or looking for information about the place. We want to know which of the woodworking projects in a collection are suitable for Christmas, or require minimal tools, or a minimal skill level, so that we can create different collections for different audiences.
All things like this, the author will know best, usually better than the copy editor. Also better than the acquiring editor. And certainly better than the managing editor.
Extracting the value of the author's knowledge and developing the tool sets and workflows that make it functional to incorporate it in the XML document of a book will require a lot of reinvention. In that sense, "not in this lifetime" is an accurate metaphor for when it will happen. Publishing needs some "born again" changes and this is one of them.
Related:
What Makes IP an "Asset"?
Mike Shatzkin
September 15, 2008
| Permalink
| Comments (1)
|
Listen
For several years in the 1990s, I had the pleasure of working closely with Mark Bide on Vista's "Publishing in the 21st Century" program. Since then, Mark has largely left the book business to attack digital problems of other content industries as well, but I value the opportunity to sit down with him because I always learn something. He was in our office for an hour on Thursday morning and we captured a few gems. Here's one of them directly relevant to StartwithXML.
Mark offered the observation that too many people in publishing don't understand what constitutes an "asset." He maintains that a content asset has two components: the intellectual property itself and the right to use or license it. The content without the rights information is actually a liability, because you'd have to expend effort (which means money) researching the rights situation before you could use or license the intellectual property.
For all the money and effort spent by publishers on DAM systems over the past several years, very few consistently store rights information with the intellectual property. VERY few. One of the things we've learned quickly in the StartwithXML project is that, while an XML repository readily enables storing rights information with the IP, almost nobody uses it that way. One of the leading companies enabling XML workflows actually described our suggestion that the XML document should hold rights information as "a very good idea." It was also, to them, a somewhat novel idea! And they are a cutting edge company on XML workflows.
So chalk up one more reason to go through the pain of the process change to a StartwithXML workflow. If Mark's formulation is right, and I think it is, doing so is the difference between creating assets and creating liabilities with each new piece of IP!
Related:
Beginning the "StartwithXML: Why and How" project
Mike Shatzkin
September 12, 2008
| Permalink
| Comments (3)
|
Listen
Today we start an exciting new industry research and education project: "StartwithXML: Why and How."
No publisher of any size or scope can be beyond the XML conversation that is now taking place across the industry. That content must be kept in a repository of XML files has become common understanding. And all the content-generation tools we use -- Word and InDesign and PDF prominently among them -- enable an XML export, so publishers are finding they can create a post-production XML'd version of their content for their archive.
That alone is necessary, but not by itself sufficient, to achieve even the first goal of making conversion -- to a different book output like large-print or to the Web or to any of many ebook formats -- cheap and easy. You can use Word or PDF to get to XML, but without the discipline of a StartwithXML workflow, you will often -- usually -- get an output that working with XML discipline wouldn't have allowed you to create. If you don't apply the discipline, the XML output doesn't solve your problem. And even if it did, it only scratches the surface of what XML can potentially offer to publishers in getting them closer to new revenues and cutting costs.
The "StartwithXML" project will explore all the issues of moving to a StartwithXML workflow through interviews and case studies with publishers and with the channel partners they will be working with to reach new readers in new ways. We'll be looking at what benefits can come to a publisher today from working this way, and what important steps to the future are enabled for those doing this (and cut off from those who don't.)
I am introducing the project this morning (Friday, 12 September 2008) at the BISG Annual Meeting. That talk covers the who, what, why, when, and how. The discussion will be continuing in this space from now.
Tools of Change for Publishing is a division of O'Reilly Media, Inc.
© 2008, O'Reilly Media, Inc. | (707) 827-7000 / (800) 998-9938
All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.
StartWithXML Discussions | StartWithXML Survey | Register for StartWithXML | Contact StartWithXML
O'Reilly Media Home | Privacy Policy | TOC Community | TOC Blog | TOC Directory | TOC Job Board | About TOC