Really Strategies Blog

A bit like making sausages

How do you make XML?  Well, as the old saying goes, it's a bit like making sausages.  You don't want to see them made, but they sure taste good.

By the way, a quick search on 'a bit like making sausages' reveals that almost everything is a bit like making sausages.

I was reminded of that saying when 'opening up the hood' on a pre-export InCopy file variant for a client the other day - that is, right after the final preparation script was run and right before triggering the XML-Exporter.  I think those in the room actually took a step back, with the look of someone seeing a meat grinder in action for the first time.

There was tagging all over the place - and in many different forms.  All of it was either automatically generated or semi-automated, with scripted support.  It looked awful!  Precisely.  That is because the final form was a machine readable document no longer built for editors or designers.

Well, we checked in the document to the XML export status in K4 and Presto! we had our lovely, tasty XML files - soon to be ready for consumption by a Web CMS.

Lovely.

Funny, but right now I cannot stop thinking about those wonderful sausages you buy in the country markets in France.  Truly you haven't lived until you have tried them.  (Apologies to other national sausage makers - I have not done the sausage travel circuit as much as I would like to.)

The proposition for print composition

For our Adobe-to-XML or K4/Adobe-to-XML technologies and practices, there are some fundamental assumptions.  I'd be curious what the opinion is out there on it.

The thinking goes something like this:

Core assumptions:

1. The best point of application is at the point of use
2. Visual design and layout inherently contain structure
3. Fundamental shifts in the way people work are possible

Regarding the use of page files:

1. Design practices for more than the last decade have focused on visual layout requirements at the expense of good file management practices.
2. Production/Comp professionals have learned to make adjustments to designer files to meet the requirements of printers and to make working with files easier

With the introduction of InCopy/K4 (etc.)

1. Editorial can benefit from organized presentation of text objects.  Lack of management of text objects renders some of the advantages of InCopy less easy to use (e.g. story mode)
2. Editorial can benefit from sensible paragraph and style names, as they now are expected to apply styles in many cases.  Therefore, a mixup in the application of style names is a possible cause for extra work fixing mistakes later.
3. The same file organization requirements that benefit editors is a critical part of an Adobe XML export strategy.

Finally

1. Managing text objects and char/para style naming is a benefit to both web (via XML) and editorial.
2. Production/Comp is capable of managing file structure to benefit editorial and XML exports in the same way they have learned to manage file structure for ease of use and printing.
3. The publishing industry should promote a shift to these file management practices.

Well, what do you all think? 

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. 

Quark vs. Adobe

Quark vs. Adobe.   That was the straightforward and clear as a bell title of a session today at the Book Business Conference and Exposition.   Before the conference, I pictured Don King promoting the session, using catchy phrases like "Today's Bout in Layout" or the "Transition in Composition." 

Don King didn't show up and the the two company representatives were relatively civil to each other.  For sure, they both got their digs in and at one point argued about InDesign's ability to crop and resize images and who stole what feature from whom.

But even as I listened to the Quark presentation and thought some of the QuarkXPress 7 features sounded interesting, I couldn't help to think of the real world where we continually see the movement away from Quark to Adobe products.  Quark 7 may be great.  Some people warn not to discount it.  But like we've mentioned before, we used to do a lot of Quark and QPS work.  But now we have a growing number of projects with InCopy, InDesign, and K4.   There certainly is a shift and it will be hard, if not impossible, for Quark to rebound.

The tyranny of print: wagging the electronic dog

Print.  From newspapers to magazines to trade books, reference books, journals, textbooks and so on, we have lived with printed pages all of our lives.  Now we are seeing the Internet finally start to mature and for several diverse clients, the day where electronic content catches up and eclipses the value of print is here or just on the horizon.  Several of our clients are taking action to change their operations seeing that their businesses will earn, or are already earning more revenue through electronic rather than print content. 

What could be simpler?  The rational thing for management to do is to begin to switch the perspective of your organization to consider web and other electronic products first and then to shuffle that content off to the waning print operation to prepare editions for the still loyal (and paying) print edition customers.  The current best practices of producing print editions, extracting XML and transforming it to various outputs (Web, RSS, email newsletter, syndication, etc) should be reversed it seems.  Why not produce a web edition first, or a general electronic edition in XML, import it into a page layout program and be done with it?

Well, as I’ve sometimes learned the hard way, the devil is in the details.  I’m glad to say, however, that while technology has not fully caught up with this proposition, technology is not the major stumbling block: it's design.  With apologies to the designers I have known and loved (or not), your age old tradition of making articles and illustrations neatly fit together on the printed page, of making the page itself attractive and readable given its finite real estate has put a monkey wrench into our dreams here. 

Much of the print world it seems has been formulated to require copy fitting to meet these presumptuous designers’ dreams which are, as must be admitted, partially derived from the finite real estate of the page size and the finite number of pages planned for each edition.  The web and almost all of our lovable electronic formats don’t have such finite real estate requirements.  As we all know, web articles can keep flowing as long as we want to have our customers hit the scroll button.  Electronic design requirements are less stringent than with print.

This leaves many of our publishing friends with the unhappy knowledge that if content is to be produced for both print and electronic output, that print requirements will always trump electronic requirements.  In other words, the less important print will wag the electronic dog.  An electronic article will need to be copy fitted to a printed page before it can be considered final for multiple mediums.  How unfair is that?

Unless publishers are willing to compromise current product standards, by, for example, implementing significant print design standardizations, outputting different versions of content for different mediums or some other strategy, then this difficulty will remain, and applications like Adobe InCopy, as well as the systems that integrate InDesign and InCopy, will continue to be part of the overall mix of technologies for multiple medium publishing for some time to come.  It means that content management and XML solutions will need to incorporate these page layout and editorial applications and systems even if systems development dollars going forward have the primary purpose of streamlining electronic content production and distribution.  That or drop print editions altogether.

QuarkXpress 7 vs. InDesign

Ars Techinca recently reviewed QuarkXPress 7, comparing it with Adobe CS2. This is an in-depth look at typographic and layout features (as opposed to workflow integration or import/export capabilities).

The conclusion: Quark scores an unflattering "better than suicide" (a reference to former Quark CEO Fred Ebrahimi's remark that switching to InDesign would be suicide).

The Quark question

Bill Trippe asks a good question about the release of Quark 7.0. 

We've written newsletter articles, a few posts on this blog, and a section of a recent whitepaper about Adobe and we've been involved in several projects with publishers moving from Quark to InDesign and taking advantage of the XML capabilities in Adobe's Creative Suite and management systems that work with it.  We used to do a lot of Quark work.  Now we do a lot of Adobe work.  We still know publishers using Quark products of course, but they are become fewer and fewer.

To keep things fair, following Bill's post, Thad McIlroy of Gilbane offers another view. 

XML capabilities of popular publishing applications

We recently produced a white paper that provides an overview on how some applications widely used in publishing - Adobe's Creative Suite, Documentum, and Microsoft Word - are currently handling XML content. 

The white paper is available by request through our web site.   And yes, sorry, you need to fill out a form first.  Sometimes we have to listen to the marketing folks. 

I've copied the introduction here:

XML is a foundation to enable the dream of next generation publishing models: Making it possible and affordable to create content once and use it many times in print and digital formats, to harness content in new ways to hook it into electronic products, to harvest data hidden inside it, and to extract portions of content from across large content collections to create new, targeted products.

To achieve the dream, software that touches content needs to be XML-aware, and those XML-aware software products need to excel in two key ways. First, products need to make foundational capabilities like editing, transformation, and search easier, more flexible, and faster to deploy. Second, software for working with XML content should actively promote the transition to new publishing processes that simultaneously result in both high quality content and products. Achieving the second is dependent on addressing the first.

Unfortunately, ten years after the introduction of XML, even usability, flexibility, and rapid rollout are mostly a dream. In the last several years, however, there has been important progress in the right direction. This white paper describes XML-related developments in key types of software used by publishers, including:

• Data storage, including the advancement of XML capabilities in relational databases and the emergence of powerful native XML repositories.
• Composition systems, focusing on Adobe’s Creative Suite, which has started to make great strides in supporting XML compared with its competition.
• Content management systems, notably Documentum, probably the most widely used content management system by publishers.
• Microsoft Word, the most widely used authoring tool, and one that has for years challenged publishers trying to fit it into an XML workflow.

This white paper does not attempt to cover the breadth of available XML-enabled software, but focuses on widely-used applications that have added greater XML capabilities that move us closer toward having the foundation described above.

More than ever, support for XML is rapidly expanding and evolving. The landscape is constantly changing, and we look forward to the day when we can survey products that make it possible not only to work with XML, but to fully exploit it to fulfill the dream of next generation publishing.

O metadata, where art thou?

We've blogged and written about the capabilities of Adobe's InDesign. And as my colleagues have said before, we are very impressed with these tools and their increasing capabilities with XML, but still see some room for improvement. One area that really needs it is in metadata handling.

You can store metadata as XMP  (a.k.a. XML) in InDesign and InCopy, but for some reason the data is not included when exporting XML from either product. You do get it when you create a PDF or other binary object (it's still XMP), but you don't get it when you export plain ole XML. I understand that XMP is meant to hold metadata for binary objects, but let's not be too strict with that, please. XMP is the container Adobe gives you to store metadata (or properties) about the document you are working on in InDesign or InCopy. Really, that metadata should be available on export, whether you render the document as a PDF or export out as XML. I would like to think about it more in this way: the InDesign/InCopy document allows you to store metadata about it and that metadata should then be available as XMP in your binary exports and within the XML of your XML exports. That makes more sense to me. Metadata has value in all contexts, regardless of whether the file carrying it is XML or binary.

We've also worked with K4 from Softcare, a publishing management system that sits on top of InDesign and InCopy. In K4 we can also store metadata about the object, and K4 can be used to export the InCopy/InDesign XML along with the K4 metadata (also XML) but there is no real connection with the metadata (via XMP) stored with InDesign.  I guess you can pick one or store the metadata in both, because if you need it in your PDF, it needs to be in the XMP in InDesign and if you need it in your XML it needs to be in K4. Got that?  Additionally, we've found K4 to offer rather weak support for multi-level taxonomy classification. (But maybe that is ok if your writers write and your categorizers categorize.)

This is not a slam against Adobe's products or K4. Adobe has made great strides and we are seeing a lot of publishers leave Quark for Adobe products. But we do hope Adobe and Softcare (and other similar vendors working with Adobe products, like Woodwing) listen to users and people who need better synchronization and control of their metadata. Until then, we work around it.

Page composition for the times

For some time now, I’ve been playing with the hypothesis that we may be in some stage of a revolution in print publishing that could be equivalent to the desktop publishing revolution 20 years ago. 

Clearly there is an acceleration of demand for content on the Internet that is in the process of reshaping the media world – including the dramatically growing popularity of blogging, podcasting, and so on, along with the increasing demand for online versions of traditional print content such as magazines, newspapers, reference materials, textbooks, and so on.  What does this mean for print content?  It seems safe to say that it is in the process of slowly weakening its value.

But meanwhile, in some places competition has taken print content to the edge of the possible – a trend that tends to increase its value.  School textbooks in the US, for example, have become tremendously appealing visually, and the trend toward state and district level customization is also working to increase its value.  Furthermore, print manufacturing technology continues to meet these demands: note the foil holograms on some covers these days, as well as new manufacturing technologies like Xerox’s iGen3 – which can help improve the cost effectiveness of manufacturing and distribution of short run customized print.  But does this occasional trend toward increasing the value of print content offset the weakening trend of the Internet technologies?   Or is it simply the logical conclusion and swan song of the desktop publishing revolution?

As new generations of internet users grow up, the digital natives now in our colleges, and internet technologies proliferate, it seems hard to imagine that print will retain its edge in the end.

Current best practices for simultaneous print and web publishing are for print to be developed first and then pushed to the web through the use of XML.  This reflects today’s valuing of print content as being greater than web content.  It now seems more and more likely that within a few years we may see a long-time industry prediction come true: the development of web content first, that is then pushed to print.  The point where this happens may be when a majority of publishing customers find more value in online content than print content.  An article in the January 21, 2006 edition of the Economist suggests that investors may also be seeing this trend, as big media company stock has been in decline even with solid earnings.  (Note also in this edition of the Economist some very interesting articles on management of knowledge workers).

This slow transition is a challenging time for print publishers of any kind.  While the changes to business models are difficult, there are also plenty of challenges within print editorial and production.  For forward thinking print development groups, it may be wise to begin transforming their practices and cultures now.  Developers of composition tools, such as Adobe and Quark will need to accelerate their work in supporting XML and other technologies, such as workflow management systems, will need to mature more quickly in order to help publishers effectively manage costs during print’s slow decline.

Customization in some segments has the effect of increasing the overall content production effort to reach the same audience.  Aside from the obvious cost pressure to increase composition staff (managed in many cases by moving production offshore), customization puts additional pressure on production management resources – whether retained or outsourced along with composition.  Management of page composition using long established practices and tools can break down with the additional stress of growing customization, which adds further cost pressures.  It is clear that composition-related tools (and staff) need to be increasingly savvy in process management to succeed with the complexities of print customization.

So does this mean that the freewheeling, page-is-king days of desktop publishing are being replaced by continual improvement process exercises and cost conscious days of a post desktop publishing era?  Is this a revolution in the works?  Whether revolution is the right word or not, change does seem to be either happening or on the horizon.