Really Strategies Blog

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.

Achieving automation: InDesign/InCopy to XML

InDesign and InCopy are built for desktop publishing - giving great power to design and editorial.  This is all great news.  However, it makes exporting XML rather tricky - particularly the development of fully automated XML exports.  Sure you can capture XML coming out of these applications, but can you really push that XML into your CMS without having text processing look at it? 

We've looked at this over many projects and the key issue is, of course, the discipline required by each group in the process.  If they don't follow the rules, then their content might not match what your CMS is looking for.  A deck must be labeled as a deck somehow.  Likewise, a B-Head or run-in head must be labeled appropriately. There are also customer or genre specific structures and metadata that must be maintained - with paragraph or character styles (or one of several other techniques).

The point is that you can't look over everyone's shoulder.  Styling and other structure related errors are bound to creep into your content on occasion.   If you only want to accept well structured XML, then you need the capability to automatically identify errors and only ingest acceptable documents.

While you can create scripts to QC the content during production, this poses a scripting update problem every time you want to change your format structure (every time you do a redesign, perhaps).  And while scripting is extremely powerful in CS2 & CS3, it is pretty low level stuff and time consuming to produce anything complicated.  It is also problematic if you don't have a specialist on staff.  Better to write scripts once and move QC somewhere else.

So what to do?  One solution is a Schema (or DTD) validation technique that allows this QC operation to proceed during an automated export.  The Schema will be more restrictive than just looking at Adobe structures - it will overlay structures specific to your content.  And while updating a schema requires some technical knowhow, it is more straight forward and much faster than updating scripting of any kind.  The reason, of course, is that this is what Schemas are meant to do well.

Using a Schema to validate InDesign/InCopy content can detect a surprising number of human errors with styling and other structuring techniques.  Not all errors, but it can do a solid job if your content is moderately complex.  Content flows into an interim format and is validated before being transformed into its final form in your CMS.  This means that valid content can be fully automated from InDesign to the CMS.  Invalid documents can be automatically siphoned off for review and correction by production.  Users can then be retrained if necessary.

Beats checking every exported document ad nauseum, doesn't it?  Especially at 2am.

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.

Print and web: one ecosystem?

Ah, content, what are you doing to our beloved work culture?  We were happy when the world was simple!

Print production, so well known, so comfortable in its methods of achieving uncomfortable deadlines.  It was so simple when 'this is how we do things here' easily fell from our lips. 

Web production, so comfortable in it's freshness and technical knowledge.  Yet it still had a world all to its own.

But now, maybe the idea of 'content' is just starting to bring each world into the other's focus.  The definition of content is not really tied to any medium - it lives outside of the reality of 'deployment', of paper & ink, or web browsers. 

Clearly the 'star' theory of content (circa 1999) is long dead, where content is produced centrally and sent seamlessly to different mediums.  Content cannot live completely outside of its context.  It must be edited to each medium.  It can start, end, and be stored centrally, in something like an RSuite (XML CMS), but it changes as it moves to print, or moves to web.

With today's tools, many publishers are living in a world where content flows from manuscript-to-print-to-web.  And where the most efficient content development ecosystem will only be achieved if upstream (print) production and downstream (web) production work to accommodate each other.  Its one ecosystem after all, where the same 'content' travels through both of these environments.

A content hand-off at the the dividing line between these worlds was the first step in fitting these two systems together.  Loosening and blurring that border seems to be the next step as we forge ahead.   A single content ecosystem demands it.

The future of production, the production of the future

Here's a thought -

Given the way things are moving - as we see more and more automation in publishing, for getting print content to the web for example, some changes are bound to occur in the industry.  The pace of change is different in each vertical, so it may happen at different speeds.  But some novel ideas may start to emerge about the role of "page production" in the organization.

4 big trends:

1. The link between print and web content is strengthening.  Print groups are starting to adapt their work to support downstream web content requirements.
2. Some production roles are moving toward system administration roles as editorial & production systems are adopted.
3. In general, technology is becoming more and more part of the print workflow environment.
4. While print production still tends to be the premier process at many publishers, the web versions of content continue to gain in importance.

The question is, how does this mesh with IT and technical management?  Is everything becoming grayer than it already is?  Will these two titanic cultures (print and web) converge into a brand new organism?

And as this trend continues to advance, will page production, in fact, end up reporting in through technology groups?  Exactly where are we all going here?   

Well, these thoughts are all interesting, but the future is a long way off. 

Or is it?

Get XML from InDesign & InCopy today

There has been a lot of activity in the XML-export-from-Adobe-area here at Really Strategies over the last year.  Over this time, we have developed a system with continually deepening capabilities for extracting XML from Adobe InDesign and InCopy.  The projects have been across several publishing verticals and have produced content to meet several XML standards, for text newsletters, and for the web.  The projects that I have worked on all manage content in the K4 Publishing System, and have used the K4 XML-Exporter aided by Adobe API scripting.

Here are a few thoughts that come out of this effort:

1. There is no significant technical barrier to getting XML from Adobe InDesign & InCopy today.  However, it does require clients to put away the notion of the magic export button. 
2. The major limiting factor is the practical limits of standardization required of print production staffs (in conjunction with support by web or text processing production staffs).  However, this limit is continually being reduced through our ongoing innovation efforts.
3. These projects inherently require process change.  Where text is already being manually processed after files go to printer, this is not very hard to achieve.  It may be more difficult for clients to envision and implement changes where no post processing currently exists. 
4. Because Adobe doesn't inherently require file usage standardization in InDesign and InCopy, standardization must be built into the use of the tools themselves - meaning print staff are required to modify their use of the tools - though minimally in most cases.   
5. Projects may also require some semi-automated application of metadata and linking information prior to triggering an export.
6. The K4 XML-Exporter (an add-on to the K4 Publishing System) is a great tool for this process, primarily because it adds some workflow automation as well as automated access to a good XSL processor.
7. JavaScript is now a standard element in these projects, as it can powerfully minimize any necessary changes for the print staff.
8. Integration with Web CMSes, by the way, is an achievable reality. 

We're excited as we continually press forward - its a great time when there is innovation every day. 

Multi-channel and media-agnostic publishing

I continually hear the two terms "media agnostic publishing" and "multi channel publishing" thrown about. Sometimes interchangeably.

For what it is worth, I'll offer up my own definitions.

Multi-channel publishing is the delivery of content through different platforms—print, web, mobile, licensees, etc. Multi-channel publishing does not imply anything about how the content is created and delivered, just that the content will eventually be fed into different channels.

Media-agnostic publishing implies the same thing but more. In media-agnostic publishing, content is created at its source for many different media, which can be another word for "channel." Media agnostic publishing is more aligned with what is also called "single source publishing." Content is created once in some agnostic format (technically speaking, this is generally XML, but the format is more than something technical. For example, the writing needs to be something appropriate regardless of its container) and then delivered to various outputs. Or media, or channels...whatever you want to call them.

Most traditional publishers—those with a history of print publishing—do multi-channel publishing. For many however, print is still the main focus. Content is produced for print, through print-focused tools, and then shepherded into various outputs. Not many publishers (outside of some reference and STM) really have media-agnostic publishing, which requires a hard look at business issues (such as whether print and web versions of an article need to match 100%), process issues (changing workflows and responsibilities) and technical issues (revamping a print-centric infrastructure and finding the right mix of tools to do so).

Even though most traditional publishers do multi-channel publishing and not media-agnostic, we are seeing more experiment with the latter. We also see tools getting better to support that. We expect and see more developments in these areas in 2007.

Writers write and categorizers categorize

In today's IT World, Sean McGrath offers up a good piece of advice regarding where in the workflow to assign classification or taxonomical metadata to content.

He says...

...many metadata based content management systems have trouble getting good metadata out of content creators. The 'aboutness' of the stuff that was used to design the content management system was obvious because it was created after the content itself. However, for new content, the 'aboutness' has yet to be cooked so to speak....Writers write and categorizers categorize. There is an unavoidable delay between the two activities. The writers and the categorizers can be the same people but the activities are very different and cannot be done at the same time.

I am not sure my feeling on the topic is as concrete as Sean's.  I do think there are some cases in which the content development and categorization can - or needs to be - done at the same time. It is one of those "there is no right answer" things that depends on circumstances and the people and processes involved. But I do agree generally and I will say I've seen more of what Sean recommends than the other way around.   And I think it is especially true for publishers who are doing some additional processing for web publishing.

But more importantly, I've often found that even with those who do separate out these activities, there is always this feeling that it would be "better" to move the categorization and classification work more towards the point of content creation (the "why can't we get our authors to tag the content" question).  What I really like about Sean's point is that it questions that assumption.  It is not necessarily better to do it that way.  In fact, there are very good reasons to separate the two activities and the division can indeed be the "better" process.

Keep it simple, keep it real

As technologists, our work requires a good understanding of the application of technology. Implicit in that, I would say, is realizing that technology is not always the answer, at least by itself. Most of the problems we face are process issues. It’s the smart application of technology that is useful. Think of electric can openers. Technology really didn’t help much there. I don’t have an electric can opener. I have the little manual hand-held thing you need to turn. I’ve never had trouble opening a can, plus I have a little more counter space.

Our experiences have shown us that there are specific areas in which publishers sometimes overcomplicate what can be simple or design what is not realistic.  The most abused: too many times we find publishers, especially smaller ones, overestimate workflow and permissions requirements. In small settings, some workflow tasks (but not all of course) can be handled by email and talking over a cubicle wall. If only one person has permission for some action, what do you do when he is out sick?

Third-party applications need to provide flexible and very configurable workflow and permission capabilities to make their product sellable. But too often, customers get overwhelmed by the options and are tempted to feel like they need to take advantage of them all. You don't. It's much better to determine the workflow, communication methods, and permissions that work best for the organization—and in a practical, not theoretical, setting—and then use those parts of your tool. Or better yet, make your basic requirements part of the decision factor in selecting your tools.   But never let the tool drive what you do.

One other area where we've seen publishers get tempted by complexity is content modeling. It can be tempting to capture very minute levels of granularity in your content. Wouldn't it be cool to be able to capture X or Z! But if you don't use that knowledge anywhere—and more importantly if the capture of it requires human effort and those humans for the most part are not willing to do it—it's pointless. There is always a balance between what would be nice to have and what can realistically get done.

We've found that these three areas—workflow requirements, permissions, and content modeling—are sometimes made more complicated than they really need to be.  So if you are in the middle of a project involving any of these three, take some time to reflect. Step back and ask if you have overcomplicated the issues.  To quote Einstein, "Make everything as simple as possible, but not simpler."