XML is Not the Answer

XML is not the answer. Structured writing may be the answer. XML is one way to implement structured writing.

More and more these days, I am hearing technical publication managers (and not a few consultants) talk about the need to “move to XML”. This may be a shorthand way for them to describe a very sensible plan to implement structured writing, but if so, I wish they would say “move to structured writing”. Structured writing is a potential answer to many content challenges. XML, by itself, is not.

There is a very real danger in all this XML talk that people can get the impression that if they move their content to XML — any XML — then they will instantly have the ability to reuse content across the enterprise and to seamlessly and effortlessly deliver content to any and every channel in a form that perfectly matches the optimal information design for that channel. It just isn’t so. read more

We Can’t Use “In Tray” Definitions for Content Roles

Everyone in the content industry seems to be trying to define their roles these days. There are a number of new roles and titles being described, and everyone wants to know where to draw the boundaries around them.

Commenting on my recent post on Content Engineering, Jonatan Lundin asked, “So is an information architect a sort of content engineer?” On LinkedIn, Bob Newman protests “I am the Technical Writer – NOT the SME!”. And in the first meeting of the nascent Content Strategy Collective, defining content strategy and content strategy roles was the first thing proposed as a goal for the group. read more

Content Engineering is Not Technical Writing

My last post, I am a Content Engineer, was taken by several people as yet another attempt to rebrand technical writing. I’m honestly a bit mystified by how people could interpret some of the examples of content engineering that I listed as being examples of technical writing, but Hi Ho. Let me set the record straight:

  • Content engineering is not technical writing.
  • Tool building is not tool using.
  • Bridge building is not bridge crossing.
  • Loom building is not weaving.
  • Car design and manufacturing is not driving.

Now, it certainly helps enormously if the people who build tools also understand the task of the people who use the tools. Bridges designed by people who have never crossed, looms by people who have never woven, cars by people who have never driven, are not likely to be very good.

A loom.

Content engineering is not technical writing, any more than designing and building looms is weaving. Photo by Aranel, Wikimedia Commons, CC BY-SA 3.0

On the other hand, the mere experience of crossing bridges, weaving, or driving does not remotely qualify you to build bridges, looms, or cars. Each of these, bridges and cars in particular, require a high degree of knowledge about materials, structures, and mechanics that no amount of bridge crossing or car driving will teach you. They require, in short, engineering knowledge and experience.

Someone who does content engineering, similarly, benefits greatly from experience in creating content, but such experience is not sufficient. They also require appropriate engineering knowledge: knowledge we might sum up as an understanding of the computability of content.

An example is probably the best way to make the distinction. Consider how procedures are typically formatted. Different companies have different styles. Some use simple lists:

  1. Click File. The File menu opens.
  2. Click Print. The Print dialog opens.
  3. Click Print. The Print dialog closes and the document is sent to print.

Some demand a title and label every step as a step:

Printing a document

Step 1. Click File. The File menu opens.
Step 2. Click Print. The Print dialog opens.
Step 3. Click Print. The Print dialog closes and the document is sent to print.

Some use tables to lay out procedures:

Printing a document

Action Result
Step 1. Click File. The File menu opens.
Step 2. Click Print. The Print dialog opens.
Step 3. Click Print. The Print dialog closes and the document is sent to print.

Typically, whichever style is preferred by the company will be specified in a style guide. It is then up to the writers to remember to use this approved style each time. This is a craft process, not an engineered process. Writers are free to deviate from the approved style, and will not receive any feedback or warning if they do so. The only way the error gets caught is if a human editor reads the copy and spots it. A fair degree of style variability is almost certain in such a process unless a lot of time and money is spent on manual verification.

Engineering a process is very much about reducing variability. Not only does reducing variability (of this sort) improve quality, it also improves process by enabling greater automation. An automated process is one that runs without human inspection and intervention. To create a reliable automated process, you have to eliminate variability in the inputs. Garbage in, garbage out.

A simple approach to engineering the format of procedures is to create a style template in your word processor or desktop publishing application. This can help improve consistency, and reduce the work required to produce properly formatted procedures, but you will still experience a pretty high degree of variability because some people will forget to use the style, or will use it incorrectly.

The next step in engineering the creation of procedures is to adopt a structured writing approach, perhaps using XML. In this case we could create markup specifically for procedures which might look something like this:

<procedure> <title>Printing a document</title> <step> <action>Click File.</action> <result>The File menu opens.</result> </step> <step> <action>Click Print.</action> <result>The Print dialog opens.</result> </step> <step> <action>Click Print.</action> <result>The Print dialog closes and the document is sent to print.</result> </step> </procedure> read more

I am a Content Engineer

In the closing keynote of the 2013 LavaCon conference, Ann Rockley talked about the rising importance of content engineering in content strategy. A content engineer, Ann explained, is someone with one foot in the technology world and one foot in the content world. Last year I wrote a pair of posts on my hesitation about taking on the label of content strategist (Am I a Content Strategist?, I Am a Content Strategist). I have no such hesitation about the label of content engineer. I am a content engineer, and I have been one for many years. read more