XML: The death of creativity in technical writing?
Originally published in STC Intercom, February 2010
I spend a lot of time giving presentations on XML, structured authoring, and related technologies. The most common negative reaction, varied only in the level of hostility, is “Why are you stifling my creativity?”
Does XML really mean the Death of Creativity for technical communicators? And does creativity even belong in technical content?
To answer these questions, let’s look at a few types of creativity and how they are affected by the introduction of XML into a workflow.
Introducing XML into an organization usually results in automation of layout. Instead of writing information in a page preview mode, with line breaks and page breaks visible, you create information in a relative formatting vacuum and must rely on the output generation process to assign the appropriate formatting to your content.
If you are the type of writer who likes to use pretty purple hearts as bullets instead of the “boring” black circles, then, yes, XML will kill your creativity. XML also (generally) reduces or eliminates your ability to manage page breaks and line breaks. The quality of the final output will depend on the stylesheets that are created, probably by someone else, to generate output.
This separation of content and formatting is not unique to XML. This article, for example, was written in OmmWriter (a Mac-only text editor), transferred into OpenOffice to apply a few styles, and then sent to STC as a Word file. The Word file is then imported into InDesign to produce the print/PDF version. I have little or no control over the final look and feel of my content.
Even in unstructured, non-XML environments, most technical writers are expected to conform to a formatting template. That removes most formatting decisions from the writer’s purview. What’s left are the finicky production issues that the software cannot handle in a template—copyfitting, tweaking hyphenation, and perhaps moving tables and graphics around to improve the look of a page.
It’s my opinion that, with rare exceptions, technical communicators should not focus on page production. I wrote a related blog post (A strident defense of mediocre formatting) on the same day that I asked a coworker to fix a kerning problem in some text. In my defense, the text was actually on a book cover page. And that summarizes my position fairly well: page production for cover pages, perhaps; page production for the body of a 600-page book, no. I see the cost savings from automated output, which can be significant, as a reasonable trade-off for giving up creativity in page layout in technical content. There is also the related issue that much of our content is delivered both in print and online, so production work might have to be done more than once. And let’s not even get into the localization issues. (For the opposing view, consult Roger Hart’s blog post, Technical communications—the business of eliminating poetry?)
For content organization, XML may or may not interfere with creative approaches. For example, if an article is required to have a list of authors, an abstract, and then the body text, you can easily enforce this organization through XML. Without XML, enforcement would come from the magazine editor. But embedding existing stylistic requirements into XML is hardly a new infringement on creative license. The problem arises when XML is used to enforce organizational requirements that are new or that were not previously enforced. Usually, XML structure will describe the required components of a book or deliverable. A book might have front matter, chapters, optional appendixes, and a required index. A help system might require a copyright topic as the first topic. An API reference could specify how each class or method must be documented (e.g., name, description, syntax, parameters, example).
Within the required organization, however, there is generally a good bit of room to maneuver. For example, how should topics be linked together? What is the best way to provide navigation through the content? Michael Hughes wrote an excellent article on a grouping technique he called “task clusters” (The Anatomy of a Help File: An Iterative Approach). XML is like a scaffold: it supports you as you build your content; once you are inside the overall structure, you have a lot of freedom to organize. The consistency imposed by XML makes content more predictable, which may be helpful to the reader.
Interestingly, XML does not provide a way to constrain authors into a very common requirement for magazine and newsletter articles—a minimum or maximum word count. It’s as though the scaffolding determines the footprint of the building, but the author controls the number of floors, the height of each floor, and the interior walls on each floor.
At the paragraph or sentence level, XML has very little sway over the content. You might have to construct links in a specific way, or be limited in the formatting you can apply at the character level (e.g., you might not be able to bold words inside a title), but beyond that, you have few constraints.
Editorial style guidelines impose much stricter rules than XML structure can. For example, your style guidelines probably include rules about where to use boldface, the infamous “click” versus “select,” and other hot buttons of technical writing. If you are unhappy with constraints on word choice, that is unlikely to be an XML problem.
Using an XML technology called “schema,” it is possible to impose certain data types on an element. For instance, you can specify that a <date> element must contain numbers in the format yyyy-mm-dd that result in a legal date. Data typing is rarely used for XML content; it’s much more common with XML data, such as configuration files.
Inside the Box of XML
Although the use of XML reduces or even eliminates creativity in page production, the resulting output can still be quite good. XML’s reputation for producing ugly pages is not an inherent limitation of the technology, but rather a result of inadequate effort in configuring the print/PDF stylesheet. (PDF stylesheets are quite difficult to build.) For a business, the appeal is clear: automated formatting is a one-time effort and saves critical time at the end of the document creation process. Copyfitting to save paper is less critical when the final deliverable is a PDF file and not a printed book.
For document organization, the creativity constraints are less clear. Many organizations simply use XML to enforce guidelines that are already in place, such as organization of reference content. Within these structures, authors still have a lot of room for creativity.
XML has little effect on content structure inside paragraphs.
Thus, I can finally answer my initial questions. XML kills off the possibility of creativity in one specific area (formatting), has some effect on high-level organization, and very little impact on low-level organization. Technical communicators add the most value and have the most opportunity for creativity in crafting sentences, paragraphs, topics, and groups of topics that explain complex concepts to their readers. XML does not interfere with this mission.
Why, then, is there so much resistance to XML? There is a perception that XML forces writers into creating cookie-cutter topics rather than useful technical information. I suppose the blame lies with those of us who spend more time discussing the glories of automation rather than how structure can support writers in creating better content. It’s my experience that after a transition period (which can be as much as a year), most writers actually prefer working in XML because it eliminates the need to memorize formatting conventions and instead lets them focus on content creation.