Really Strategies Blog

Working with XML in InCopy, InDesign, and RSuite

We've recently announced the availability of the next evolution of the RSuite CS3 Connector, which integrates RSuite with Adobe InCopy and InDesign CS3.

The Connector enables some very exciting features for publishers looking for full XML workflows with these Adobe tools:

• Publishers can manage their content in the XML flavor of their choice but enable creation and editing of that content within InCopy. This is done through a transformation between the publisher's XML and INCX, the native XML file format for InCopy.  We've enabled some tools to make this a simple process for the end-users, including the ability to navigate for content in RSuite from within InCopy (so users who want to stay within the Adobe application do not need to go to another app) and the ability to open the document in InCopy from the RSuite CMS browser-based interface (for users who are working within RSuite).
• And then publishers can link to the articles or images managed within RSuite from the InDesign document, also managed in RSuite.  InDesign users can refresh the links to update the content based on changes made to the content by other authors and editors.
• We've also been involved with a few projects in which RSuite is used to dynamically generate the InDesign document.  In this scenario, the RSuite user assembles the content they want into RSuite's "content assembly" construct and then pushes it through a workflow that dynamically generates the InDesign file with links to the content already in place.  

We've created a short screen cast that illustrates the CS3 Connector if you want to take a peek.

And what about CS4 I hear you ask?  So far, most, but not all, of the publishers we have talked with interested in this type of integration are using CS3.   We don't expect many needed changes in the actual plugins to work with CS4.  The biggest change in CS4 is the underlying Adobe content models, which have changed significantly between CS3 and CS4.  But, fortunately, they have changed for the better and are easier to work with.  So if you have any interest in seeing this type of integration with CS4, let us know.   

The eBook Challenge

Yes, it looks and sounds like a fun new game but it's actually quite a confusing landscape. And the image depicted here is a simplified version of starting points, formats, stores, readers, devices and their loose connections.

I'm still catching up from last week's Tools of Change for Publishing conference where the big takeaway was 2009 is the year of the ebook.

What I want to know is are publishers prepared? Which ebook format is best for you? Do you distribute to all devices or just one? How do ebooks fit into your multi-channel publishing workflow?

I can hardly wait for 2010 to see who comes out the winner. Stay tuned.

RSuite CMS provides loud and clear answer for Audible.com

We are often asked by publishers to describe the real business impact RSuite CMS has on our clients. Along with my previous post on Blood-Horse Publications, Audible.com is another client that has leveraged the power of RSuite to realize its business goals.

Audible, Inc., an Amazon.com, Inc. subsidiary, is the leading provider of premium digital spoken audio information and entertainment, on the Internet.

In early 2007 Audible.com launched an aggressive project to revamp their entire metadata program to better manage and process the metadata files they receive from their publishing partners.This program had the following business objectives to meet:

• Ensure error-free metadata by using publisher or publisher aggregators as the source of data, and by developing new tools to drive, search, browse, and publish to store functions off this sourced data.
• Ensure the ability to identify Audible products on partner sites by providing ISBNs that correspond to the downloadable digital binding with each product in feeds to partners, wherever and whenever possible.
• Reduce the occurrences of human error by automatically populating data into web site databases, from the sourced data.
• Improve findabilty, searchability, and marketability of products by standardizing keyword, category, authors, contributors, and publishers.
• Improve royalty systems by making contract entry a requirement for any product being pushed to an Audible site.

During a 4-week proof of concept (POC), RSuite was configured to prove out several use cases:

1. Leverage RSuite’s workflow tool to ingest ONIX feeds and audio files
2. Apply additional metadata (both manually and automatically)
3. Distribute the appropriate content packages to target delivery sites.

During this stage many business rules were also documented that were applicable to improving Audible's business opportunities. After a successful POC, Audible.com selected RSuite for its metadata and aggregation solution.

RSuite became the framework upon which Audible crafted solutions to meet all its requirements: workflow, business rules validation, content aggregation and delivery. In 6 months, RSuite was configured and implemented to become Audible's workflow tool, which enables seamless transfer of content from publisher feeds to web site-ready files.

Now after using RSuite for over a year, Audible has realized its goals of integrating a tool that would satisfy the business objectives and show a return on investment quickly. As Art Zegarek, director of data architecture told our team, “RSuite has become a very critical system very fast!" It is satisfying to know that RSuite is helping an aggregator such as Audible.com meet its business objectives every day.

Start With XML Conference

Attended the Start with XML conference on Tuesday and am happy to report it was excellent!  This bodes well for the next O'Reilly conference - Tools of Change, where we will have a booth and where our own Lisa Bos will be speaking.

There were a lot of highlights for a single day.  The morning keynote by David Young, Chairman & CEO of Hachette Book Group USA was an engaging overview of why to start with XML. (All presentations are on the Start with XML conference site, though some may miss something without the talk).

Several presentations by top production leaders were also interesting.  In particular, I'd like to point out the accomplishments of Rebecca Goldthwaite's team at Cengage Learning in developing standardized design that does not appear standardized(!).  Amazing that so many strikingly different appearances can be auto-generated from XML and layout templates.  It just goes to show that their design teams 'get it' and more importantly, that design teams in general can remain highly creative in the world of XML.  Take this to heart people!

But the presentations were all very good.  If I start mentioning all the good ones, then I'll be mentioning everyone.  I think this may indicate a watershed year - the number of people who have quality knowledge of the business, technology and people issues in developing an XML workflow is potentially reaching critical mass.  Perhaps we are ready to move forward in publishing after all.  If Start with XML is any indication, then the larger Tools of Change conference will be a watershed event this year.  It's a very exciting time.

What is the difference between RSuite CMS and MarkLogic Server?

Publishers often ask us “What’s the difference between RSuite CMS and MarkLogic Server." Great question!  The most straightforward answer is that RSuite is a content management application and MarkLogic Server is a database. It’s that simple.

MarkLogic Server is an incredibly powerful XML repository on top of which many publishers have built fantastic applications, O’Reilly’s Safari U, Elsevier, and Congressional Quarterly, to name a few. These custom built delivery applications are just one way MarkLogic Sever has been used.

RSuite CMS is also an application built on MarkLogic Server. RSuite CMS sits on top of MarkLogic Server to leverage the native XML repository (i.e., database) and search capabilities. Without a database, RSuite would not be able to run – just like a car needs an engine. However, without a chassis, steering wheel, electronics, etc., the engine would be of little use. Therefore, think of RSuite as the ignition system and think of MarkLogic Server as the engine. Both are very important to content management.

Investing in RSuite CMS: A four month ROI

I’ve been involved in technology well over 20 years now and in the information industry just over a decade. In that time I’ve seen my share of project successes and failures, but one thing I have never seen until now is a publisher actually get the ROI they were expecting out of their technology investment within the first year of implementation.

Blood-Horse Publications, a Kentucky-based publisher that is the definitive resource for thoroughbred information, licensed RSuite CMS in 2007. At our recent user conference, Luther Andal, Director of Technology for Blood-Horse, provided the following summary of their investment in RSuite:

• Evaluated (through a proof of concept) and launched RSuite CMS in less than 16 weeks
• Recognized significant revenue from the data feeds and editorial content that was aggregated by RSuite in an automated fashion, which in turn populated a subscription-based website and created and distributed a daily PDF product
• Reallocated two IT staff because of the efficiencies gained (saving over $100,000 of annual production costs)
• Realized an ROI in 4 months

That is pretty impressive if I say so myself. In these days of year-long projects that go off the track (I’m thinking train track here, not horse track), it is refreshing to see a publisher with a success story by keeping the project scope tight to meet a true business need. As a best practice that we promote, keeping the scope focused on meeting specific business objectives allows for the best possible success. Just ask Blood-Horse Publications who is now enjoying the capabilities of RSuite CMS as a core technology to their publishing operation.

Stay tuned for more RSuite success stories.

Complex layout, XML and a little...Obama?

Complex layouts.  Full automation.  That is what many of us are working toward.  You know what I'm talking about - Layout to useful XML (and back again) with speed and very little increase in manual effort.  It's achievable.  But it means changes to production practices no matter what technology you use.  Change is coming.  And change is possible - if you don't believe me, go ask Barack Obama.  So if you're on the Obama bandwagon - and after Iowa, any candidate's bandwagon, red or blue - you must believe you can change production practices, even in the most intense and fragmented development operation.  Think about how hard it is to change the country - what's change in the publishing trenches compared to that?  I'm asking you to believe... :)

The architect and the interior designer

I heard a story the other day about a store owner who hired an interior designer to design her new retail store. With great enthusiasm they set about designing a great space. It was going to look great - and it did look great in the sketches. So she submitted their plan for approval.

What she didn't know and what she found out very quickly is that she was required by law to hire a registered architect to draw up the submission plans. So the designers sent their plans and drawings to an architect to 'just draw them up'.

Unfortunately, the architect found that there was no HVAC system in their design - oops. Bathroom design was not to code, as were several other things. Well, everyone scrambled, and after much brouhaha between the groups, as you can imagine, the design was revised and I suppose everything turned out fine (if more expensive). But it was touch and go for a while.

The lesson: work with an architect from the beginning, so you can create with the required constraints in mind.

Does this story sound like anything related to print-to-XML/web workflows and print content production in general? If so, then who is the interior designer? Who is the architect? And what is the HVAC system?

Requirements, the publishing manager, and accountability

Senior publishing managers: do you have a clear idea of your role in publishing systems projects?  How about in requirements gathering for publishing systems projects?  (By senior publishing managers, I mean the publisher and direct reports or the equivalent - print or web).

BAs & PMs: How clear are the lines drawn between your business requirements, your functional requirements, and your system requirements?  Are you encouraging your senior publishing managers to take the appropriate project roles?

I'm thinking of two major projects I've come into contact with over the years where it was clear that the dividing lines drawn were wholly inappropriate to the intended constituencies, particularly for publishing managers.  I've also seen one major project where the requirements gathering was rigidly compartmentalized by the consulting company, probably as a means to ensure that each constituency was dealing with the appropriate subject matter. 

Some problem indicators:
1. Publishing managers reviewing quasi-technical diagrams in a functional requirements session (yes, we need to use XML; yes, we need a digital asset management system!).
2. Business/financial managers making top down decisions on specific systems. (Though there are cases where this could be appropriate)
3. Technical teams being left to determine how much time a task should take.  (What’s the matter? it only takes 10 minutes to process...)

Each to their own:
- Publishing managers should be concerned with functional requirements, which determine the effects of a system on staff work, including how work gets done by editors, etc.  They should also include setting standards for performance.
- Business/financial managers should be concerned with business requirements, or the overall financial effects of a system including related process changes.
- Technical teams should be concerned with systems requirements, systems, and architecture, to meet publishing manager needs (within financial constraints)

Publishing managers can have an important impact on a project.  My advice is not to get your hands dirty with specific technology.  Falling in love with a particular system or even a type of system, is a baaaad idea, trust me.  Falling in love with improvements in performance and ease of getting work done for your staff is a much healthier idea.

Senior publishing managers often consider the following:
    - We need to create this new online product
    - We approve doing this publishing technology project. 

They can more positively impact a project by making a few simple accountability statements and holding on to them like a pit bull.  They might sound something like this:
    - We need to create this new online product, and make content production for it take only this amount of staff time.
    - We approve doing this publishing technology project.  This project must reduce time spent on these non-editorial tasks, this amount, by this much, and decrease overall time in our production process, this amount, by this much.

This should set up a good interplay between subordinate publishing managers/staff and the technical team as they participate respectively in the creation of functional requirements and system requirements.

What I want from Adobe - x-ray file formats

Consider The big content system integration diagram (draft 1).  What are the bottlenecks for the content stream?  Well if what I'm doing is any indicator, importing and exporting from InCopy or InDesign still has a little friction to it.  This is being addressed by Adobe progressively - see CS3 (yay!) for example over CS2.  Also being addressed by Softcare and other companies, again progressively.

But is there a fundamental change that can happen here?  Can we get XML that can pass through Adobe formats frictionlessly like Superman can see through walls with his x-ray vision?  (Digression here: There is a surprising amount of controversy on the Web about Superman's powers - many self proclaimed pundits seem to say that his X-Ray vision is unrealistic!  Not science that it is caused by low gravity on his home planet?  Baloney!)

Maybe the problem isn't that content can't yet be imported and exported seamlessly, maybe it is that content shouldn't be imported and exported at all.  If Adobe considered InDesign/InCopy not to be a holder of data, but an aggregator of data for print layout, then we might start getting somewhere.  Already, images are externally linked, why not, we might then ask, have text objects be externally linked?  I'm not talking about the page geometry, etc. that might live inside of an InCopy document.  I'm talking about just the text - and as XML if you please.

If Adobe therefore allowed XML content to remain external as files, and it allowed all external content, XML or images, to be linkable via HTTP protocol or otherwise, then we might have a situation where media and XML management systems could maintain content continually - without having to messily import during print production and export after print production.

Think of all the advantages!  Tremendous.  Metadata could be added externally, preparation for web could happen simultaneously. And Adobe page apps would still manage page layout and editing within page geometries so no skin off their nose.   Of course, this is not an easy thing to accomplish - but it is the logical future state - each format to its own system, with specialized apps consolidating, editing, and arranging the last mile of content.