The Effect of DITA on Information-Development Roles

Home/Publications/CIDM eNews/Information Management News 12.05/The Effect of DITA on Information-Development Roles

Jen Linton
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.

Information-development manager
As a manager, what do you usually think about? Costs and resources. Have you ever asked the question “How do I produce all of this information and still find cost cutting opportunities?” Or, “How do I produce all of this information more efficiently because of a limited number of writers on my team?” DITA helps to answer these questions.

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.

Information developer
Your information development staff are likely to discover that their own authoring processes will change significantly. Changing from a book-oriented approach to a DITA, or topic-based, approach is not easy. The DITA topic focus can take writers a while to grasp, but the results are exciting. Authoring in topics forces one to plan the structure for content in advance, rather than having it evolve during the composition process.

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.

Editor
The role of the editor will also change with DITA. The editor needs to ensure that the topics are stand-alone pieces of content. Transitions used in chapters and sections of a book don’t work very well in DITA because the reader is expecting standalone topics. Transitions have to be built into the topics themselves or constructed through the related links to other topics. If the topics are not truly standalone, their reuse in more than one deliverable will be limited.

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.

Information Architect
Information architect is likely a new role for some organizations, one that will play an important role in the XML authoring lifecycle. The main responsibilities of the information architect include defining and promoting the fundamental design concepts embodied in the organization’s architecture. The information architect must know the document type definition (DTD) thoroughly and must be comfortable making changes to the DTD if needed. The architecture must be familiar with every aspect of the DTD and be able to interpret the elements for the writers.

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.

Production Manager
Processes used by the production manager must to adapt to this new architecture. Using DITA XML, you might need to learn mapping to create your topic-based deliverables. You will also have to learn how to develop style sheets for the different media in which you will be delivering your information. You may work closely with the translation organization, web publishers, information architects, and graphics developers.

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.

Summary
I haven’t mentioned all of the areas for change within this article. Clearly, some changes will be easier than others. The amount of change depends on how quickly you can move to DITA. Know that changing to DITA XML will not happen overnight. It does take some time to get all the stakeholders on board with the new idea, but in the end, the positives outweigh the negatives and everyone seems to benefit.

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.