Comtech Services, Inc.
In your information-development organization, you and your staff members may wear many hats. They can include manager, writer, editor, graphics specialist, production specialist, project manager, usability specialist, and many more. When you decide to change to a topic-based writing architecture such as Darwin Information Typing Architecture (DITA), some of these roles may require different definitions and responsibilities. I have identified five of the main roles and how they might be affected.
Cost cutting in your department might include reducing the amount of information you translate. Translation usually represents a large portion of a department’s costs. DITA can help reduce translation costs by helping you to send smaller chunks of content that have been changed through to the translators rather than the entire book.
You may also reduce costs by changing the way you author content. Authoring based on a topic model makes possible more reuse of content across different platforms (i.e., departments, products, and deliverables). Reusing topics of information provides a significant return on the investment of time put into creating information. The more time that is saved by not having to re-author information, the more time you have to encourage innovation within your team.
You will have much work in the planning phase of moving to DITA. First, you will have to work as a team to analyze all your information and begin putting together a reuse strategy. You will need to define specifically what content you will deliver to your users. Then, you must construct a comprehensive information model in which you define each of your topic information types, content units, metadata, file naming conventions, folder structures, and more. A sound information model requires that you make good decisions about the ideal deliverables for your users.
Once you have an information model in place, you will have to learn how to mark up your content using the correct XML elements. That means that every XML element must be defined and illustrated in your DITA authoring guidelines.
On the other hand, when you use structured writing, you will not have to deal with those pesky formatting issues that always seem to take so much time. Instead, formatting is up to the style sheets and the production manager.
As you can see, the information developers’ role will change as you move into a DITA architecture. It will help if your writers do some of their own research to understand the basic DITA concepts rather than just finding out from the manager that they suddenly need to start authoring in a new way.
An editor must also ensure that links are implemented correctly. The editor and the production manager must work closely together to validate the links and the metadata. Authors should complete the required metadata attributes and values, but editors should also check the metadata to ensure that the correct values have been assigned.
In addition to reviewing links and metadata, the editor must review the use of XML elements in the topics. Often, writers will use an element because they want to control the formatting even though the content does not conform to the semantics described by the element. Editors may want to use a special editing style sheet in which extreme styles are assigned for editing purposes. For example, if a writer uses a bold format tag that they are not supposed to use, the editing style sheet could format it a 38 point bold italic font to emphasize that the tag was used incorrectly.
Of course, editors will continue to review areas of style and language that have traditionally been their responsibility. Checking for consistency across topics is essential. Because topics written by different authors are likely to be used together in DITA maps, authors who introduce in their own terminology and voice will creates problems for the deliverables.
We have provided only a few examples of how an editor’s role may change. We anticipate that editorial responsibilities will change for many different types of edits, including structural and developmental edits, copyediting, legal and policy edits, user interface edits, and verification edits. We recommend that the editorial staff review ensure that new opportunities to benefit the reader are anticipated and made part of the regularly editorial procedures.
Another responsibility of the information architect, when using a topic-based architecture like DITA, is to manage the various topics that are created by the writers. It is critical that a person take on this role when moving to a new topic-based architecture so that there is some sense of control over who is creating what topics and to ensure topics are not being duplicated. The information architect will have the broad view of the information-development environment.
Some of your responsibilities will include ensuring that the style sheets work correctly and that you leverage the metadata in each topic.
You must understand which topics are delivered to which users and media, and you will work with the information architect to make sure there are no duplicate DITA topics. If you are interested in the technology of technical communication and production, you might want to consider adopting the production manager role. If you are most interested in how ‘behind the scenes’ everything works, you will get exposure to it through this position.
What if you don’t have all these roles on your team already? Does your organization have a group of writers who handle all these responsibilities individually? Before making the change to DITA, think about assigning roles and responsibilities so that one person doesn’t take on the challenge on his or her own. Dividing the responsibilities will help not only to ease into the new methodology but to get more people excited about the changes.