|
||||
| DCLab.com | About DCL | Tech Info | Press Info | Contact Us | DCLNews | Partners | Wiki | Client Area | ||||
|
One of the most common reasons for project failure when converting to a component content management system is writers not making the leap from unstructured to structured authoring. Many writers still resist structured authoring, fearing it will rob them of their creativity and make them replaceable. However, some writers, like Amanda Cross, learned that the opposite is true. Writing with structure makes authoring documents faster and easier, freeing the writer to invest more time in the tasks that they find interesting and that their employers find indispensable. At the beginning of my experience as a technical communicator, I idealized writing self-contained documents, agnostic of any other documents, perfect for the product and audience. I wanted to enjoy the accomplishment of looking at a finished product committed, forever-unchanging, to the department archive and saying, "I wrote that."
Piled on top of keeping up on my existing documents, each new project added more tasks to my queue. Suddenly, the chore of crafting a unique treatment for each topic wasn't the source of career fulfillment that I thought it would be; it was a pain in the neck. It took forever to find where I'd written something when I needed to change it, and I couldn't easily delegate because someone else couldn't predict where they'd find information in my document. Plus, I couldn't avoid the sinking feeling that the unique treatment I created for each document was pretty much always the same. After all, these documents were for parallel features used by the same audience in the same product for the same use cases. I was clearly wasting time that I wanted to be spending on branching out into different kinds of responsibilities:
I'd Never Really Wanted to Reinvent the Wheel In college, you work on standalone projects for a couple weeks at a time. In business, projects can spawn other projects and stretch out in perpetuity. My mistake early on was thinking that the satisfaction I got from completing one project in college had to translate to completing one project in the business world. But, in fact, I could get satisfaction from completing documents that really helped people, even if the audience analysis, document structure, and page design had been done as part of other projects. So to free up my time to accomplish more, I began reading through the documentation that already existed to find the structure that was already there. (By the way, if you've ever read through an existing document to get ideas on how to write your own document, you've already begun down this path, even if you didn't know that the "structure analysis" buzzword applied to what you were doing.) Over the years writers had misinterpreted (or disregarded) the existing structure, so I also looked for the kinds of information that were misplaced. For example, if a previous writer had put information about corporate policy in the definition of a database column, I still wanted to have a place for that corporate policy in my new structure. I didn't want to leave anything out just because someone had typed it in the wrong place. Trying Out the Structure Soon I had designed a structure with a place for everything, and I was ready to try it out. Not only was I able to produce 600 pages of documentation for the new project single-handedly in about three months, but at the same time I was able to use my time to participate on the design team. I had time to comment on every iteration of the design, argue issues of usability, and make myself the final authority on naming--things to which I'd never been able to give the time they deserved.
The Real Test It was an achievement, to be sure, but so far I'd been the only one using the structure I'd created. It didn't feel like its mettle would really be tested until someone else tried it out, ideally on an existing module to demonstrate that there really was a place for every piece of information. We got that chance when new writer Amy was assigned to update an existing module, and a rough one at that. I was an advanced user of the product, and after reading the documentation, I didn't understand a thing. The documentation made the product seem much more complicated and difficult to use than it really was. Even so, when I sat down with Amy to review the structure, talk about the kinds of information we'd expect to see in each section, and discuss the reuse opportunities, she looked skeptical. Previously, these modules repeated information in as many contexts as the writer deemed necessary, but the new structure called for a place for everything and everything in its place. You can always link to further information as needed. The idea of having exactly one predictable place to put each piece of information was new and a departure from what had always been done before. Still, Amy is open-minded and enthusiastic about improving the documentation, so with an offer to help any way I could, I left her to give it a try. The Moment of Truth This is where the story gets short, because I had almost nothing to do with the rest of it. Re-writes can take as much as six weeks, so I waited till the next week to peek over the wall to ask our fresh face how the re-write was going. Great, she said, it was almost done. I was surprised that it was going so fast, but she told me that the structure made it easy. With a place to put everything, she said, it just fell together. The last time I touched the document was to review it. Indeed, with a place for everything, the document had fallen together in a way that made the product easy to understand. The writer's attention was available to focus on the quality of the content, without having to puzzle out where to put it and the SME reviews were quick and easy.
DCLNews Editorial
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Data Conversion Laboratory, Inc. 61-18 190th St., 2nd Floor, Fresh Meadows, NY 11365 718-357-8700 convert@dclab.com Copyright © 1997-2008 Data Conversion Laboratory, Inc. All rights reserved. |