I’ve done work on clients’ documents for a lot of years, and I’ve learned that the word document, like the word empty, means different things to different people.
To most content creators (writers, for example), a document is the physical reflection of an idea. It is an imperfect reflection, at best; but the essence of a document, in this view, is the visible manifestation of words on paper. Many people are—or at least profess to be—completely insensible to any aesthetic characteristics of that visible manifestation; they are concerned only that the right words are present in the desired sequence. That’s enough.
Other content creators are indeed interested in the shape and style of the presentation, but they still see only the visible manifestation (on paper or on a screen). It’s a two-dimensional surface divided into light and dark regions, but that’s as far as it goes.
There’s another way of looking at a document, though, an approach that is common among technical writers, information architects, and others with more of an engineering bent. In this view a document is a two-dimensional projection of an n-dimensional data structure, and the content (the data housed by the structure) is almost incidental. What’s interesting is the variety of different documents that can be created from the same structure just by moving the “light source” used for creating the projection. It is this view that enables technologies like content management, XML-based content syndication, and the World Wide Web itself.
Take this blog, for example. The structure was designed before I signed up. All I have to do is pour content into the structure and, voilà, here’s an instant document. You may be reading it as a Web page, with a sidebar full of interesting and ever-changing tidbits; or you may be reading it through any of a number of different syndication interfaces. That’s an elementary application of the view that a document is a projection of a structure.
I’ve worked on technical documentation projects running to several volumes where the explicit application of this principle determined the most fundamental characteristics of the document set: Do we organize the material according to the engineering disciplines that contributed to the system (our sources for content), according to the mechanical modules that are assembled to make up the system, or according to the classes of users who have to work with the system? All three of those models end up being used, with the same content being presented three different ways, in three sets of documents.
The difference between these two ways of looking at the word document is part of what drives the relationship between the content creator and the document producer. I might ask, rhetorically, why authors never seem to understand how to use the Styles feature of Microsoft Word, for example, but I really do know the answer: Their focus is on content and everything I do is just “formatting” or “making it pretty.” We can adopt an attitude of mutual disdain (each considering our own perspective the One True Way), or we can appreciate that each of us adds value to the finished product. I’ll keep making containers to pour your content into; you keep making content to pour into my containers; and we’ll achieve a proper symbiosis. In the end, I always save time and money for my clients, simply because they cannot do what I do. This is not because they are stupid or untrainable; it’s just because they are looking at documents from the other end of the telescope. What I do—particularly when people are standing over my shoulder watching—looks like magic to them (I’m sure this is a common experience for many people who see documents as structures and understand software tools from that perspective). And what my content-creating clients do—developing ideas and telling stories—often seems like magic to me (because that’s not how my brain works).
This relationship applies to editing (polishing the words so people other than the writer can properly and unambiguously understand them), to typography, and to document production of all kinds. The best work is a collaboration that recognizes the strengths of all the contributors.
Good ideas. I think that your point is extremely important for a technical writer to think about: what he/she does best and likes to do most.
I would guess that if TWs did such soul-searching, most would conclude that they really prefer working in content [presentation | management | organization | etc...], and not content creation.
Post a Comment