Upcoming SlideShare
×
Like this presentation? Why not share!

Like this? Share it with your network

Share

# Multiple Formats, One Source: Supporting Multi-Format Publishing with a Single Source of Content

• 190 views

Describing Kaplan Publishing's goal of achieving multiple format publishing from a single source of content.

Describing Kaplan Publishing's goal of achieving multiple format publishing from a single source of content.

More in: Technology
• Comment goes here.
Are you sure you want to
Be the first to comment
Be the first to like this

Total Views
190
On Slideshare
188
From Embeds
2
Number of Embeds
1

Shares
5
0
Likes
0

### Embeds2

 https://www.rebelmouse.com 2

### Report content

No notes for slide
• Here’s our product development process through to print.Start with word document, google docs, etc., This is where the author or SME writes the content. After some initial work, the content is moved into Adobe InDesign where it’s laid out and formatted for publication. After the design has been approved and the title has been proofread (the content will switch between PDF + INDD) it’s sent to a printer, who sends us back a PDF of the document.The final product is printed and shipped to warehouses where it’s distributed to various sellers
• The main starting point
• This process outline is one you’ve already seen. It exemplifies the product development process from Conception to Print (simplified). I’ve included a second format (INDD  ePub) for this example. So how does this exemplify too much manual work?I’m going to outline (at a basic level) all of the manual steps that need to occur within the product production process. Word to InDD- Basically the author writes the required content. It’s worked over by a copyeditor in its original format and then it’s moved into Adobe InDesign where it’s worked over by the typesetter and proofreader. This process is overseen by the production editor and is aimed at making sure that the content looks good and is grammatically sound. It’s then sent off by the production editor to the printer, who prints the PDF. The same basic process is repeated for generating an ePub. The reason the process is repeated is because ePub has different content + structural standards than print. Due to inconsistencies in our source INDD content our current production processes require that it is proofread and typeset again. Additionally, the ePub requires manual QA due to bugs that are generated as a result of Kpub’s usage of InDesignWith every new format additional manual work is added to the process, which in turn makes it harder and harder to scale product production. It should also be noted that we do have a single source of content for our multi-format production process: Adobe InDesign. However there are challenges associated with using InDesign as a source that necessitate manual, repeated work for any export. I am going to go into more detail on this subject in a few slides.
• Branching Effect  each branch is a one way street. Any change to the content in one branch will need to be made to ALL branches where that content used. That means that the typesetting +, if necessary proofreading, that occurs when creating a (for example) print product needs to be repeated when creating an XML based product, again for an ePub product, so on and so forth since the unaltered usage of our INDD content could lead to non-matching products across multiple formats.So let’s say that a significant error is found in 4 paragraphs in the print product. This error requires that the paragraphs be rewritten. The resulting new paragraphs are 6 lines shorter. For the print product this means that it’ll need to be re-typeset since the text won’t reflow automatically. Without redoing the reflow of the book it’s entirely possible that different components such as illustrations, graphs, and assessment content support materials (such as equation pages) will be misplaced. This is just for print. The same process of re-typesetting (at the minimum) would need to be repeated across each production “branch.” This might sound superfluous since ePub/XMlbased content will reflow automatically, but as I said before the challenge is with the our usage of InDesign. To make sure that our content presentation and structure are consistent across multiple formats repeating the typesetting , and possibly proofreading, processes is necessary. As you can imagine this kind of work is highly inefficient and time consuming since it requires so much manual repetition. Because the source content is structurally inconsistent, it is not possible to simply transform content from one format to another even if you have the appropriate plug ins. Instead all updates are made manually which in turn increases the likelihood of additional errors occurring. Basically, it’s a potentially endless loop.
• As I’ve alluded to in previous slides, we’ve encountered challenges in using InDesign as a source. I want to make it clear that the challenge isn’t with Adobe InDesign, the program, but rather with Kpub’s usage of the program. When we were doing only print books HOW you got the content to look as it should wasn’t a going concern. This means that while our content generally has a consistent look and feel the backend isn’t necessarily as neat. The two main culprits (in our usage of InDesign) are character and paragraph styles: According to Adobe a character style is a collection of character formatting attributes that can be applied to text in a single step. A paragraph style combines character and paragraph formatting attributes, and can be applied to a single or multiple paragraphs. For our purposes it meant that as long as the collection of attributes produced the appropriate looking content it didn’t matter what those attributes were or what the different styles were called. It’s the same challenge as using XML or HTML without strict guidelines governing the placement and relationships of element sets. The challenge in using InDD as a source for multiple content formats is that it’s a tool designed primarily for print production. There are plug ins (official and otherwise), but they rely upon well formed InDD content since the target formats require similar well-formedness. Unfortunately, most of our InDD source content was developed before a well formed content structure was necessary. Thus it does cannot be easily transformed to multiple content formats since it does not conform to many content structure standards. What this implies is that our usage of character and paragraph styles (naming, placement, relationships, etc.,) was not consistent from title to title or even from chapter to chapter. Why? Because print book production adheres to a consistent visually based standard, NOT a content structure standard like you’d find with DITA XML or XHTML.This seems fairly straightforward, but it’s important to remember that in the late 1990s when digital producst like eBooks were first developed they seemed like a flash in the pan (and at the time, they were), but this time around the concept has stuck and is slowly, but surely gaining market share against traditional print products. What does this mean? It means that where a visually based standard was enough for print production, it is not enough for non-print products, which require content structure standards as well.It’s a classic case of kid in a candy shop. Too many pretty things (InDesign really does give you a plethora of ways to get your job done) and not enough rules leads to toothaches down the road.
• Let me make it clear that print products DO utilize a content standard (INDD- visual appearance), but for non-print products that’s not enough. With non-print products content requires a standardized LOOK (visual content standard) and content structure (XML DTDs). Why?There are multiple digital formats and services  leads uncertainty regarding display since variances such as screen size, resolution, hardware restrictions, user requirements, languages, formats can result in one format having different display requirements than another. So if visual requirements can change then the content itself requires standardized structure. Using XML isn’t enough though. The challenge is that, as with using a visual standard, there are potentially dozens of ways to create valid XML. For this reason, it’s super important that any XML usage is governed by a set of rules or DTD/MOD files. These govern exactly what elements can be used where, and what their relationship is to other elements and structures. This allows for repeatable content structures, which in turn allows for scalable multi-format publishing. In short, the lack of standards does not indicate an absence of standards. It means though that having a visual standard isn’t enough for non-print content. Nope, it requires additional standards (content structure standards) to ensure that the content looks as it should (no matter the platform or format) AND that the content is structured in a consistent and repeatable fashion. One other thing is that content standards also need to be enforced. Otherwise, why have them?
• Once we found out that round tripping didn’t work for us we shifted our focus to implementing a “single source of truth” for our content. We acknowledged the inconsistencies in our INDD content and thought that by stripping out the visual content standards and imposing content structure standards we’d be able to still utilize our INDD content in the short term, while using the DITA content as a source for non-print products. Eventually, we hoped we’d be able to standardize the InDesign content, build the necessary transforms for multiple delivery formats, and be able to shift INDD from a source to an output. To this date, we have not successfully scaled this process as the challenges involved with moving INDD content into KTP DITA and then transforming the content proved quite challenging and time consuming. The iBooks project is a perfect example.
• It all boils down to this conundrum: moving content from a limited to highly structured situation and vice versa is incredibly difficult. On the surface it seems like a relatively simple challenge: You have limited content standards because your content was built for a single purpose (Print)Thus you have a situation where you need additional standards: multi-format publishing You create the appropriate standards.Implement them onto existing content and export/transform content accordingly. As Kpub discovered it’s significantly more difficult than this. 1) In our case, “limited” structure  “highly” structured meant that we had to create and implement a content structure standard that took into account structural cues from a visual content standard (InDD). 2) We then had to translate these cues into our content structure standard, 3) After this, I extracted the content into a usable form (INDD to XML) and synchronized the content by eliminating or merging any inconsistent elements uses, or placements.4) Then I had to utilize a set of transforms to get the XML extracted content (INDD XML) into a form where it could be digested by a tool. This adds another 2 steps onto the process: One to transform the content so that the appropriate XML tags were used and the proper structure approximated. And then a 2nd transform to “burst” the content and give it the hierarchical structure KTP DITA required. Along the way there were plenty of manual QA steps added into the mix.What this meant is that unless a company is able to impose a uniform content structure standard it’s almost impossible to make this process scalable due to the amount of repetitious and manual work that needs to be done. This in turn makes the possibility of creating an efficient multiple-format publishing workflow extremely low. If (in our current process) it takes (on average) 2 weeks to output (minus QA time) a single iBook, how can we expect to scale this process so that we can produce different products (ePub, iBook, HTML5, Print, etc.,) simultaneously, efficiently, and accurately? The answer is that without content standardization (multiples allowed), process streamlining, and the imposition of content structure standards (multiple allowed) you can’t expect a scalable multi-format content production process.
• Competing business goals and priorities is a challenge because it means that there’s never a winner. If someone is temporarily on top, it just means that you follow their requirements til they get booted out and then you have to pivot. Pivoting is hard work.2A) Non-standardization leads to a lack of automation. A lack of automation leads to a non-scalable process. 2B) Limited resources is a couple of things. First, at Kaplan Publishing our content team is 2 people. Second,  is always tight. These challenges mean that more often than not you’re not able to address all potential and real challenges, only those that are most pressing.3) Multiple existing workflows is a fairly straightfoward conclusion. Different business units all have a different way of doing things. This in turn makes everything harder for the publishing team because they then have to reconcile these differences in a way that doesn’t eliminate or cover up any steps unique to a particular workflow.4) Every business unit has different requirements. Different formats have different requirements. These differences make it challenging to implement a single standard for different outputs.5) Things are changing. Not hour to hour, but quickly enough. If companies cannot keep up with these changes or just make smart bets than they run the risk of failure.
• This looks very similar EXCEPT it uses XMl/HTML as the content source instead of InDD. What this means is that all of the content proof reading and copyedit would occur in one spot (XML/HTML) and would only have to occur once (or whenever content needs to be updated). Typesetting and other visually dependent factors would still occur on a format by format basis, but would be guided by strict format specific content standards. This consistency means that there’s a minimal amount of QA that needs to occur thus reducing the amount of time needed to produce products. As I’ve stressed several times, the key ingredient is consistency, reduction in manual work, and reduction in process repetition. By streamlining the process and implementing content standards + content structure standards it will be possible to create a single source of content for multiple formats. This should not be mistaken for a cure all. This consolidation does not solve all of the challenges I outlined in earlier in the presentation. For example, not all manual tasks will be automatable and this process assumes that content currently in InDesign will either be transformed to XML/HTML or, if new content has to be created, written natively in XML/HTML. What this solution does do is make addressing the challenges of legacy content and automation possible.
• By utilizing a single content structure repetitious work can be eliminated or at least reduced. This in turn will lead to a more efficient process, which again isn’t a cure all, but represents a significant improvement over our existing processes. Not only does reducing repetition reduce production timelines, but it also makes content updates, errata fixes, metadata creation/implementation, etc., significantly easier. One is always easier than 2, 3, etc.,
• What this all leads to is a predictable process. This in turn allows for the implementation of software (automation). Automation is reliant upon a predictable process, which requires that content have a consistent structure. Once automation reaches a certain point + quality a process can become scalable. The key to calling a process “scalable” is the total (or to an acceptable level) elimination of human input except for QA and content creation/update/removal.
• Increasing process efficiency is not a panacea for all the challenges facing the publishing industry, but it does address a significant issue and blocker By introducing and enforcing content structure standards, content becomes more flexible in its application. It means that content can be used in more places, more reliably since the underlying structure is consistent throughout. No company operates in a vacuum there are always legacy content and structures to deal with. The challenge is managing the transition from these systems to your new consolidated processes. At Kaplan Publishing we’re still wrestling with this transition, but I believe, based upon my experience over the last year, that we’re well on our way to a successful transition from our legacy process, but there’s still a lot of work to be done. The ultimate takeaway from all of this is that it’s worth it. Reducing the amount of time required to WORK the content means that there’s more time to innovate or improve the content. This in turn will allow for companies to better serve their customers since consistently structured content is the baseline for being able to quickly and efficiently meeting customer needs.

### Transcript

• 1. Multiple Formats, One Source: Supporting Multi-Format Publishing with a Single Source of Content Alexander Berman Content Manager Kaplan Publishing @Alex_Berman647 @LavaCon
• 2. KPub Product Development Process Word INDD PDF Print
• 3. Just because something works now doesn’t mean it’s the best solution for later
• 4. CHALLENGES 5 Challenges for Kaplan Publishing’s Existing Content Development Process
• 5. #1 Too Much Manual Work Word INDD PDF ePub Print
• 6. #2 Too much repetition INDD PDF XML ePub HTML Print
• 7. #3 InDesign as a Source
• 8. #4 A Lack of Standards
• 9. #5 Shared Service Graduate programs Pre-College Programs Health Programs Bar review Shared services • GMAT • GRE • MCAT • SAT • AP Tests • ACT • PSAT • NCLEX RN • NCLEX PN • USMLE Board Tests • Comprehensive and Multi-State bar review for aspiring lawyers • Responsible for supporting the SBUs . • KPub, Tech Support, Call Center are all shared services.
• 10. HOW WE TRIED TO MAKE IT WORK* *Since 2011
• 11. Round Tripping INDD Transform Transform XML
• 12. KTP DITA Single Source of Truth
• 13. iBooks INDD • Proofreading INDD XML • Transform Word DITA • Copyedit • Typeset • Transform Widget IBA • Export • Proofread IBA • QA iBook
• 14. WHY IS IT SO HARD?
• 15. Limited Structure Highly Structured
• 16. Takeaways • Competing business goals and priorities • Scalability Challenges – Lack of automation – Limited resources • Multiple existing workflows • Different standards for outputs • Uncertainty of future requirements
• 17. HOW DO YOU BEAT THE SYSTEM?
• 18. Step #1 Print INDD PDF Enhanced PDF XML/HTML ePub Mobile
• 19. Step #2 Reduce Repetition
• 20. Step #3 Predictability Software Scalability
• 21. Conclusion • Not a panacea • Increased structure = Increased flexibility • It’s hard, but worth it