Write Once Read Many (Ipg Conference 2010)

  • 2,466 views
Uploaded on

Presentation slides offering an overview of XML and best ways to think about its applicability in publishing

Presentation slides offering an overview of XML and best ways to think about its applicability in publishing

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,466
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
29
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Thank you for having me here today. Twitter opportunity, if relevant.
  • In developing this presentation, Bridget helped elicit nine questions that IPG members would want answered as a result of my talk. The broke down into two big groups: “Why tackle agile content” … (click) and “How do I make content agile?” Today’s presentation is structured along these lines, with time at the back end for questions. Oh .. We did have a ninth question – whose answer I’ll save to the end.
  • Let’s start with a baseline definition of XML Extensible – can be adapted or customized for specific types of content (click) Anyone signed up by the middle of last week received an e-mail from IPG a week ago with (among other things) links to two glossaries of XML terms and related buzzwords that we published on the Magellan blog. Both can be found at the link shown here, and they’ll remain up and available after the conference.
  • To provide a bit more background on XML, let’s compare how most books are created today to how they might be created in a more agile approach. At the top, you see how we typically work today, combining content, document structure and design decisions in a single, document-driven approach. This workflow readily supports one output opportunity per document, and repurposing can be hard. On the bottom, you see what Phil Madans of Hachette Book Group calls a “content-driven” approach. The source document still links content and structure, but applies deign attributes separately, supporting cost-effective output across multiple formats
  • Essentially, disengaging design increases agility, allowing you to use one source document to support multiple formats and uses
  • Although XML documents tagged for structure are very useful, certain types of books can be tagged for meaning, increasing their value across other new or recombinant uses.
  • Agile does come with a cost, though; most publishers have to become more standard in their content workflows. On the left, a “write once, read once” workflow allows you to do things many different ways, because rendering the end product, typically a printed book, lets you take many paths By comparison, an agile approach, as shown on the right, requires that publishers use reasonably well-defined processes to create content that really can be “write once, read many”
  • So why do I need to know about XML .. Three environmental factors
  • In preparing for today’s session, one of the questions asked was, in effect …. Short answer is “no” It’s not just about XML, though
  • I don’t know about you, but this is the only survey I have ever seen in which a group of editors agreed on one thing, let alone two.
  • You see this in other ways, as well. Here’s a chart that shows areas in which various publishing segments see promise. Fixing print-to-web processes is a priority at most imprints that are not professional; and everyone is looking at ways to do more book formats
  • There’s a lot of survey data, and I’m happy to provide links, but in the interest of time, a bottom line
  • So that’s the “why” argument; we’re switching gears to talk about “how”. Planning and implementation are key here
  • On this last point, I’d like to offer up what one of my IPG reviewers called a “scary chart”. I hope I can make it less scary for you. On the left, you’ll see one dimension, the ability to divide a book into stand-alone components, what we call “chunks. On the bottom, the axis measures the relative frequency or potential for content reuse. In the chart, we’ve listed types or genres of books. The placement is directional or representational, not absolute.
  • For certain books … here, cook books, education titles, reference, travel, among others … the likelihood of updating, reuse and components or “chnks” is quite high, and these are the types of books for which a substantial investment in content tagging might pay off
  • For other books, a significant investment in XML would probably be overkill. Novels don’t get reused or updated much, and they offer few or no chunks. They still benefit from XML’s ability to support cross-platform uses, but it makes sense to focus largely on tagging these types of books for structure.
  • Last year, we published a research paper, still available at oreilly.com, that outlined five considerations underpinning the business case for XML These included … The first four of these are publisher-specific, and today I am focusing on the ROI piece
  • We talked before about the Copernican shift, with content at the core. If you start at the 12 o’clock position, you see the print book and then e-book; these are most common direct outputs today. Increasingly though, other uses could be supported, if the conversions costs were manageable As you move further clockwise, those uses are spelled out: direct publishing to the web, increased use of large print, keeping content in print using POD technologies, and offering higher-value, annotated editions. There are other, untapped opportunities out there…
  • So, there’s a rationale, and an ROI … how do you do this? Three buckets (explained). The fewer titles you produce, the more likely you are to stay closer to the top of the list (commercial solutions, outsourced services, standard transforms) Multiple solutions (increasing in flexibility and cost)
  • Here’s the truly scary chart … I don’t want to make you XML experts in an hour, but that write once, read many model has a few complications – you need to use XML applications to transform the original document into other formats. Sometimes that takes one step, sometimes it takes more. The transforms are called style sheets, and they come in a variety of flavors: CSS (simplest), XSLT (changing one type of XML document into another) and SXL-FO (creating a formatted, printable document)
  • The more you invest in style sheets, the less you pay in prep costs
  • In effect, then, you want to match your investment in style sheets to the volume of work against which those style sheets can be applied. If you are small, this doesn’t mean you can’t use sophisticated style sheets. It does mean that you’d get a better return if you adapted where you could to use commercially available or shared style sheets.
  • In our research paper, we talk about a number of better practices uncovered in our research. This is an excerpt from the full list, and I’d like to focus on four items
  • This can take a while, especially if you are moving a backlist, as well
  • Here’s a practical list that ties back to the survey results
  • On the revenue size, there are also opportunities Before the last click… you’ll remember that I had a last question to answer.. What was it?
  • Given all you have heard, what do you think I am going to say?
  • Here are a handful of links and ways to get a hold of me. You’ll note that the first link is the one I mentioned earlier, the glossaries developed ahead of this presentation. Thank you for your time… With that I’ll open the discussion up for questions.

Transcript

  • 1. “ Write once, read many” Planning for, producing and delivering agile content IPG Conference March 19, 2010
  • 2. An overview of today’s discussion
    • “ Why” tackle agile content?
    • What is XML?
    • Why do I need to know about it?
    • Is it going to go away?
    • If not, is it relevant to my business?
    • “ How” to make content agile?
    • What are the benefits and costs?
    • When will I see an ROI?
    • How do I get started?
    • What are the best ways to save on implementation?
    “ It’s all well and good telling me about XML, but I don’t have ONIX yet! Is XML a priority for me?”
  • 3. So what is XML?
    • Short for “extensible markup language”
    • Identifies elements (the building blocks of content) and defines document structure
    • Can create or adapt elements to capture specific niche structures or taxonomies
    • Allows publishers to customize the presentation of elements across multiple uses
    With XML, you get a host of acronyms and related terms. We’ve posted two glossaries online at http://bit.ly/ahxDGi.
  • 4. Tagging (mark-up) defines structure and separates content from design Traditional Print-Centric Approach Content Structure Design Three linked elements; one output opportunity Content-Centric Approach Content and structure are linked; design is separate Multiple output opportunities Migrating to agile content Adapted from work by David Young and Phil Madans, Hachette Books Content Structure Design
  • 5. Using XML applications, multiple formats can be generated from a single source (file) Structural components of the work are identified and connected to the content Print book (multiple formats) Aggregation (e.g., annual “best of” publication…) Mobile Web page Syndication, more Disengaging design increases agility ebook PDF (e.g., SITB) Adapted from work by David Young and Phil Madans, Hachette Books Content Structure Design
  • 6. If you’ve tagged for structure, you can also tag for context (meaning)
    • Formats are supported by consistent tagging for structure
    • All content that crosses platforms benefits from structural tagging
    • Recombinant, aggregated, syndicated and searchable uses rely on contextual tagging
    • “ Chunkable” or repurposed content benefits most from contextual tagging
  • 7. Publishers must balance process complexity with content agility Starting point – XML transition “ Write once, read once” (single-format delivery) “ Write once, read many” (supporting multiple formats and uses)
  • 8. Why do I need to know about XML?
    • A “Copernican shift”, with IP (not a printed book) at the center
    • Old channels atrophying
    • New channels rising
    • Multiple formats with significant transform costs
    • Demand for web-ready marketing content
    • Recombinant and “chunked content”
    • Need to link IP and rights
    • Cost management AND revenue growth
    • Different models for different kinds of books
    • One size cannot fit all (a strength for XML)
  • 9. Is the need for XML a passing fad?
    • Mark-up (tagging) is a core component of book production
    • XML and its predecessor, SGML, are three decades old
    • STM and journal publishers were early adopters of SGML
    • Recent growth in use of XML among professional, business and some trade publishers
    • Still, the question isn’t as much “ Will XML last? ” as “ Will the need for more agile content persist or grow? ”
    • To understand the need for agile content, we surveyed the toughest audience we could find …
  • 10. Editors’ views on the need for agile content
    • 100% noted some or a lot of problems with content storage and retrieval
    • 89% noted that additional formats take more work
    • 71% plan for more than one use of content
    • 62% get files back from printers to edit or update
    • 53% think about chunking or recombining content
    • No editor felt “everything was fine; no need to change”
  • 11. The upside for more agile content
  • 12. Core take-aways from our survey
    • Almost everyone sees a value in cost-effectively supporting more formats
    • For most publishers, the ability to manage multiple formats is far from “under control”
    • Content storage and retrieval is not a “science”
    • Increasingly, publishers and editors are looking for the flexibility and control that XML can provide
  • 13. In a nutshell, if you need to…
    • Reduce direct or indirect content costs …
    • Improve content storage and retrieval …
    • Make greater use of ebook, large-print or POD formats, or …
    • Get ready for a more robust content marketplace, then …
    • Agile content (née XML) is relevant to your business
  • 14. Implementing XML: benefits vs. costs
    • An investment in content agility requires advance planning
    • It often leads to changes in processes, technologies and organizational structures and roles
    • Publishers must learn and apply new tools in new ways
    • Different types of books benefit to greater or lesser degrees from an investment in XML
  • 15. Estimating XML’s potential benefits Many Few or none Frequency of or potential for reuse Travel and tourism Cookbooks STM Author or annotated editions Travelogues Tests Fictional series Historical fiction (opportunity to capture people, places, events) Novels “ Chunks” Low High Religion (esp Bibles) Business Education Reference Scholarly monographs
  • 16. Estimating XML’s potential benefits Many Few or none Frequency of or potential for reuse Travel and tourism Cookbooks STM Author or annotated editions Travelogues Tests Fictional series Historical fiction (opportunity to capture people, places, events) Novels “ Chunks” Low High Religion (esp Bibles) Business Education Reference Scholarly monographs
  • 17. Estimating XML’s potential benefits Many Few or none Frequency of or potential for reuse Travel and tourism Cookbooks STM Author or annotated editions Travelogues Tests Fictional series Historical fiction (opportunity to capture people, places, events) Novels “ Chunks” Low High Religion (esp Bibles) Business Education Reference Scholarly monographs
  • 18. How do I obtain a return on my investment? Business case components taken from “StartWithXML: Why and How” research paper, section 2.1
  • 19.
  • 20.
  • 21.
  • 22. Digital marketing Custom publishing Content aggregation
  • 23.
  • 24. Agile solutions fall into three “buckets” Increasing cost or complexity Increasing cost or complexity
      • XML editors
      • Word 2007
      • InDesign/InCopy
      • Sharepoint
      • Workflow solutions (e.g., K4)
      • “ DIY”
      • Outsourced DADs (codeMantra, Ingram, etc.)
      • In-house (e.g. MarkLogic)
      • Standard transforms (“collect for print”)
      • EPUB output
      • Custom transforms
      • Proprietary databases with real-time calls or periodic feeds
  • 25. Managing and applying transforms XSLT CSS XSLT XSLT XSLT XSLT Large print PDF, print POD Mobi etc. Other* XSL-FO XSL-FO XSL-FO XSLT XSL-FO Why style sheets? They are the tool that makes “write once, read many” possible … *Chunked, recombinant or annotated content
  • 26. Style sheets lower per-page prep costs Stylesheets Simple = $550 Moderate = $1500 Complex = $2500 Highly complex = $5K - $10K Composition $.50 - $4.25 Adapted from work by Rebecca Goldthwaite, Cengage Learning
  • 27. The payoff is volume-related Adapted from work by Rebecca Goldthwaite, Cengage Learning
  • 28. How do I get started? Acquisition Contracts & agreements Editorial Production editorial Production or operations Marketing & sales Develop author guidelines Implement Word templates using XML functionality Keywords (book, chapter) Integrate rights information with content Confirm additional downstream uses With authors, tag for meaning Work with editors to tag and “chunk” Apply style sheets Implement and maintain version control Manage and apply transforms Work with solutions providers Use tags to help target audiences Title-specific SEO/SEM Monitor search and keyword us to inform upstream tagging
  • 29. Best ways to save on implementation
    • Begin with the end in mind (plan first)
    • Commit to sustained change over a period of time
    • Remember that it’s not (just) about XML
    Successful implementation starts with effective planning. Here are five planning and seven implementation “best practices” to keep in mind as you develop more agile content workflows.
  • 30. Begin with the end in mind … Planning Implementation
    • Establish and evaluate end-user requirements
    • Assess your processes across functions and handoffs
    • Model both current (operational) and future (strategic) benefits
    • Solicit senior-level support for sustained change
    • Determine the point at which you want to “start” with XML
    • Obtain and maintain operating buy-in, support and dialogue
    • Rank your key business benefits and measure progress openly
    • Plan for early wins, ideally spread across multiple functions
    • Exploit the value of prototyping
    • Capture and share deep editorial knowledge
    • Foster and communicate objective measurements
    • Capitalize on the value of new, downstream uses
  • 31. Commit to sustained change … Planning Implementation
    • Establish and evaluate end-user requirements
    • Assess your processes across functions and handoffs
    • Model both current (operational) and future (strategic) benefits
    • Solicit senior-level support for sustained change
    • Determine the point at which you want to “start” with XML
    • Obtain and maintain operating buy-in, support and dialogue
    • Rank your key business benefits and measure progress openly
    • Plan for early wins, ideally spread across multiple functions
    • Exploit the value of prototyping
    • Capture and share deep editorial knowledge
    • Foster and communicate objective measurements
    • Capitalize on the value of new, downstream uses
  • 32. Remember that it’s not (just) about XML … Planning Implementation
    • Establish and evaluate end-user requirements
    • Assess your processes across functions and handoffs
    • Model both current (operational) and future (strategic) benefits
    • Solicit senior-level support for sustained change
    • Determine the point at which you want to “start” with XML
    • Obtain and maintain operating buy-in, support and dialogue
    • Rank your key business benefits and measure progress openly
    • Plan for early wins, ideally spread across multiple functions
    • Exploit the value of prototyping
    • Capture and share deep editorial knowledge
    • Foster and communicate objective measurements
    • Capitalize on the value of new, downstream uses
  • 33. So if you are looking to … Goal Keep in mind Streamline ebook production
    • Standard formats, particularly EPUB, exist
    • If you support more than EPUB, buy, borrow or create transforms that can be reused across titles
    Produce more formats
    • Figure out the formats first (large print, POD, library edition etc.)
    • Buy, borrow or develop XSLT and XSL-FO tools that can be shared or easily adapted
    • Simplify: make XML files that support seamless downstream use
    Improve internal processes
    • Catalog pain points (file maintenance, retrieval, versioning, etc.)
    • Be clear where XML helps (versus workflow improvement alone)
    • Focused projects: short or prototyped; senior and operating support; look for early wins
  • 34. Growing your content breadth Goal Keep in mind Repurpose content
    • Tie plans back to pain points, where applicable
    • Buy/develop XSLT and XSL-FO tools that can be shared, adapted
    • Simplify: make XML files that support seamless downstream use
    Create related “chunks”
    • Capture and share deep editorial knowledge
    • Prototype and test (make many small mistakes, not one big one)
    • Test pricing where you can (not an XML suggestion, but …)
    Create expanded editions
    • Survey (be mindful that the expressed need may not be there)
    • Engage both editors and marketing/sales staff (break down silos)
    Develop or use mobile apps
    • For smaller publishers, app development is likely not a priority
    • To take advantage of app readers, ask for standards (typically XML-based) and structure content so that it can be ported easily.
  • 35. Agile content vs. ONIX: who wins?
    • Agile content is the priority
    • “ Metadata in Excel is acceptable; keeping print formats as the center of your universe is not” (Laura Dawson)
    • BIC, BISG offer “alternate routes” to ONIX-leery publishers
    • Every title published today that is “not agile” is one that will:
      • Cost money to repurpose later one; or
      • Be too costly and thus unavailable/ineligible for downstream use
    • Lesson: invest a lot less now or pay in conversion costs or lost revenues later
  • 36. Useful links
    • http://bit.ly/ahxDGi (link to XML and related glossaries)
    • http://toc.oreilly.com/startwithxml (research paper)
    • http://www.bisg.org (standards and current issues)
    • http://www.idpf.org (standards, EPUB)
    • [email_address]
    • @brianoleary (Twitter)
    • www.linkedin.com/in/brianfoleary (LinkedIn)