Printing a document
||The File menu opens.
||The Print dialog opens.
||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:
<title>Printing a document</title>
<result>The File menu opens.</result>
<result>The Print dialog opens.</result>
<result>The Print dialog closes and the document is sent to print.</result>
Tom Johnson started the discussion with Structured authoring versus the web. Sarah O’Keefe and Alan Pringle took it up in Structured authoring AND the Web. My turn: Structured authoring FOR the Web.
One of my long term grievances is that structured authoring has been adopted piecemeal. Rather than approaching it holistically as a method that can provide a wide range of quality and efficiency benefits to the authoring process, people have tended to adopt it for a single purpose, and to use it only to the extent that it achieved that singular purpose.
In my last post I argued that navigation based on classification schemes does not work because readers don’t classify their experiences. But while that is generally true, it is important to note that sometimes readers do classify their experiences, and that when they do, it is important that we base our navigation on those classifications.
In Web Organization is not Like Book Organization, I said that the TOC does not work at a large scale. It is worth talking a little more about why it doesn’t work, because it has important consequences for many of the navigational schemes that people propose for the Web and other large information systems.
The reason a TOC does not work at a large scale is that a small scale TOC acts as a list that the reader can simply browse, but a large scale one becomes a classification scheme that users have to navigate. If you can’t take the TOC in at a glance, or at least read it through comfortably, then you have to trace down particular paths in the hierarchy of the TOC, and that means you have to figure out the classification scheme behind the TOC. And that does not work.
In his blog post, Two Competing Help Models: One-Stop Shopping or Specialized Stores?, Tom Johnson explores the dilemma posed by trying to put a company’s help information on the Web using the old tri-pane help paradigm. Do you combine all the help for your product lines into one site with a master TOC, or do you put up multiple small sites with separate TOCs?
Tom shows that there are significant problems with both approaches, but he looks at it only from the top down perspective (which assumes that the reader first finds “the help” and then uses the search and browse mechanisms of the tri-pane help system to find specific pieces of content). Further problems become evident when we consider what is likely the more common case: that the reader Googles for a specific answer and lands not on “the help”, but on a specific page in the help.
In a comment on my Content Wrangler article, It’s Time to Start Separating Content from Behavior, Laura Creekmore said (emphasis mine):
[T]his conversation has brought to mind some thoughts I’ve had recently, and I think this is an even more difficult issue. Because eventually, we’re going to come up with all the technological fixes we need to resolve the issues above. However, right now, content management systems have already outstripped the technical interests and abilities of the majority of content creators and subject matter experts with whom I work. [And no, I’m not slamming my clients here. They are really smart people.] When we require advanced technical knowledge in addition to advanced subject knowledge in order to fully take advantage of the capabilities of our content systems, we’re not going to get the results we want. We have to NOT ONLY figure out how to do this, but we ALSO have to figure out how to make it easy and intuitive. I will say, I also don’t mean to slam these efforts — they are critical steps, and this is essential thinking. I’m just saying, please, let’s not stop this effort once we’ve made something POSSIBLE [as we have done with so many current CMS]. Let’s not stop until we’ve made it a reality for all content creators.
Sometimes microblogging questions require macroblogging answers. Here’s the conversation:
@arh: Did @hixie really call XML a “disaster”? Is #techcomm aware of this? http://html5doctor.com/interview-with-ian-hickson-html-editor/
@mbakeranalecta: @arh XML is a disaster. Bad implementation of an essential concept. So is QWERTY. So it goes.
@arh: @mbakeranalecta Generally agreed. What concerns me are the #techcomm folks who think XHTML is “the future”.
@mbakeranalecta: @arh If people don’t see the value in making content mutable and addressable, then presentation formats are all they care about.
One of the most frequent concerns that writers express about structured writing is that it will rob them of their opportunity for creativity. In itself, this is not an argument against a business adopting structured writing. Businesses don’t exist to provide creative outputs for writers, but to create products for customers and income for shareholders. But that aside, does structured writing really rob writers of the opportunity to exercise creativity? I think not. In fact, I think it increases the opportunity for real creativity.