Alan J Porter
[This post is part of a planned series of articles that examine how the traditional book industry could benefit from adopting XML.]
In order to prosper, publishers must re-engineer their processes and focus on creating content, not books.
A few days ago I saw a job posting from the publishers of my first book, who were looking for an editor for one of their imprints. What caught my eye was that the posting emphasized that the new editor should have experience and skills in using the same software that had been used to produce my book. A book that was published in 1997 – thirteen years ago!
Technology has changed a lot in thirteen years and so has the way that content can be created, handled and made ready for publication. But this publisher is far from being alone in sticking with old processes. My experiences working on other book projects in the last few years have just reinforced my belief that the vast majority of the traditional publishing market still works around a production system designed to do one thing – move paper.
A process that, despite changes in tools, has changed little since the dawn of the printing press.
For centuries the traditional publishing workflow has been:
- The author writes a manuscript (first on paper, then typewriters and more recently word processor software – these days usually Microsoft Word)
- The completed manuscript is then sent to the publishers for editing. Editing involved marking up, with either pen, or now using track changes and comments in the word processor, although sometimes it is just an email list of things to change. The editing phase can go through several iterations before everyone is happy and ready to go to publication – and by publication I mean go to print.
- The book, article, pamphlet or whatever is then recreated in the publishing tool. In the days of the mechanical printing press this meant manual typesetting, then with the emergence of desktop publishing tools it meant importing and converting the content from one for to another. The end result was the same however. Once the content is at the print ready staged it is locked into the format and layout of the physical page. Changes at this stage become costly, time consuming and rarely get reflected back into the source content.
- If the content is going to be published in more than one format, say a paperback and a hardback version, then a whole parallel production process has to be created.
- As systems and software are changed, as inevitably happens, the content becomes locked in multiple different software formats meaning that it either becomes unusable and the book goes ‘out of print,” or that multiple parallel production processes have to be maintained and coordinated for different titles based on when they were originally published.
- Even where publishers are now producing eBooks they are still setting up separate parallel production processes by taking the source content and having it converted into yet another layout driven format, that still uses a page-based paper-like model.
The best way to leverage the power of XML for any project is to use it from the start. This means using XML writing tools during the content creation process.
As I started to write this blog post I received an email from an editor of a magazine I contribute to on a semi-regular basis, who had attached a copy of my latest article for last minute edits and a request to use MS Word version tracking so that any last minute changes I made could be “replicated in the InDesign file.” Another example of a process where the content is locked by the format of the deliverable, even though the magazine in question is now delivered electronically rather than as a print copy.
Once the content is locked into the deliverable format like this, it loses any potential to add value.
As I outlined in my last post, using XML allows the publisher to add real value to the content; it also allows them to fully separate the content from the publishing process allowing the content to be reused and republished many times over in different formats and on different delivery platforms without having to lock the content into the physical design of a page.
With XML the strictly linear production process that we are used to can also change allowing for more flexibility and reduced time between creation and publication.
There are several ways that the XML mark up can be applied to the content, either at creation or as part of a post-creation conversion process.
An XML publishing workflow requires authors to create structured content using XML-enabled authoring tools.
The best way to leverage the power of XML for any project is to use it from the start. This means using XML writing tools during the content creation process. The problem is that most authors (and I’ll include myself in this statement) just like to start with a blank sheet and let the words flow without having to worry about tagging and structure; another throw back to the parchment / typewriter approach. This is the reason why the vast majority of documents created in MS Word use the default normal.dot template.
A well configured XML editor can give the same sense of freedom, by having a well thought out schema (mark up template) applied and installed before the author starts.
In the comments section of my last post publisher Richard Hamilton suggests that the biggest issue with getting authors to use XML is that it is perceived as ‘too technical’ and that implies both a step learning curve and a restriction in flexibility and style.
He makes some valid points. The truth is that the XML can be hidden from the author behind a template or a series of basic styles. If this were presented as a specific publisher’s Style Guide, rather than as XML Tagging it would make it easier to accept and implement for a non-technical writer. Most authors are used to working with different style guides from different publishers; working with XML should be no different.
Another approach is to develop the XML markup as the book is being written. In the sprit of full disclosure, Richard Hamilton, mentioned above, is the publisher of my upcoming book “WIKI: Grow Your Own For Fun And Profit”. In keeping with the book’s subject I am writing the book on free wiki software, (PB Works). Once I had a couple of chapters drafted in a totally free form way, Richard then developed a test page on the wiki to map the underlying wiki markup to XML, and associated that with basic styles such as:
Here is the Chapter title (Format = Heading 1)
Here is another heading (Format = Heading 2)
I, as the author, could then apply this style to my ongoing work without having to worry about the mark-up underneath.
By using just the first two chapters of the book we have developed both the required markup, as well as the end page layout and format for the print version. The book design is completed before I have finished the writing task greatly reducing the production time. It also means that changes can be made very close to publication date. The same source will also be able to be used to produce multiple versions for different delivery platforms without locking it into any one production process.
It’s no more costly to send your content out for conversion to XML than it is to create and manage it in the inefficient ways most publishers do today.
Another alternative is after-the-fact tagging. Once a manuscript has been delivered it could be sent out to specialist companies for conversion to XML. This could be an off-shore process or an in-house one. It is no more costly than importing, cleaning up and replicating edits in a tool like InDesign or applying existing typesetting markup languages such as LaTeX and the potential payoff is even greater.
It may be that to take advantage of XML and the added value it can bring that a book’s production ‘team’ will need to expand from the author / editorial / print to now include intelligent content and multi-media specialists working with the original author or adding value on behalf of the publisher. The production team will become more akin to a movie production with relevant specialists bought in on a per project basis. There may be an incremental increase in initial cost using this approach, but the pay off can be so much greater as instead of just a couple of print versions and maybe a basic eBook page turner, you can now deliver the same content as a full multi-media experience that not only works on today’s emerging technology, but will be positioned to take advantage of tomorrow’s technology too.
Switching to XML does not mean getting rid of paper in favor of eBooks, it means that paper becomes just one option among many. Most importantly it means changing the business model from shifting paper, to delivering intelligent content with real value.
[In the next post I’ll look in more detail at how XML can be used to add value through multi media and different presentation and delivery models.]
About the Author
Alan J. Porter a 20 year veteran of the corporate communications industry is founder of 4Js Group LLC a consulting and services company that specializes in combining creative talent with business expertise to help companies tell their story. He is also the regular writer of the monthly Disney*Pixar “World of CARS” comic book series.
His latest book, “WIKI: Grow Your Own for Fun and Profit” will be published by XML Press in May 2010.
Blog: THE CONTENT POOL http://4jsgroup.blogspot.com
Email: ajp@4jsgroup.com
Phone: 512-968-7362
Twitter: @4jsgroup
