What I personally like about DITA is the inability to format something with a wrong style.
Put simply – you just can’t mess up the styles! In fact, when you add a new element (such as the “to do” statement or a new step in a procedure), the right style is applied automatically. Taking it one step further, even you if applied the wrong style manually, it will exist only until you close the file. nimbus cloud . When you re-open the file, only the right style is there. DITA’s style requirements are forced onto the document automatically.
How is this accomplished? As opposed to traditional writing techniques commonly used (such as Word or unstructured FrameMaker documents), in DITA, formatting information is not stored together with content. If you open a DITA file in a text editor, such as Notepad, you may see something like this:
<title>Creating DITA Topics</title>
<p>DITA enables you to create Concepts, Tasks, and References.</p>
<context>To create a Task:</context>
<cmd>From the <uicontrol>File</uicontrol> menu, select <uicontrol>New >
Task</uicontrol>. The Create a New File dialog box is displayed.</cmd>
<cmd>In the<uicontrol> File Name</uicontrol> field, enter the name of
<cmd>In the <uicontrol>Topic Title</uicontrol> field, enter the title
of the task topic.</cmd>
<step><cmd>Click <uicontrol>Create</uicontrol>. </cmd>
(Don’t worry, you don’t have to write tags in DITA; DITA editors will do it for you. You can write in WYSIWYG environment.)
As you can see from the DITA code, there is nothing that would define that the topic title should be displayed in blue, the “to do” statement should be bolded, and procedure steps should be numbered. So where is this information coming from?
All formatting information is defined in a separate file called a stylesheet. This is where you define that the topic title is displayed with Verdana, 20pt, Blue, Bold, and the “to do” statement is displayed as Verdana, 12pt, Blue, Bold. When you create content, you don’t have access to this stylesheet, which means you are focusing on content rather than on formatting. The stylesheet is applied to the DITA file that contains the content and formats this content appropriately.
Even more important, different stylesheets can be applied to the same content, creating multiple formats. This is the essence of single-sourcing – where one block of text can appear in one format for one use (such as a printed manual or PDF) while appearing completely differently when appearing in another format (such as a .chm file).
What this means is that in DITA, the concept of separating content from the definition of how this content should appear gives us many interesting opportunities. For example:
1. If the look-and-feel of our content needs to be customized for different OEM partners, we just need to create several different stylesheets, one per OEM partner. Then you can apply one of these stylesheets when publishing content.
2. Similarly, we can create multiple stylesheets for different outputs (e.g., PDFs, online help, etc.).
3. Technical writers can send content for review to subject matter experts who usually focus on content and while making revisions, might “mess up” the formatting the technical writers so carefully applied.. This means we don’t have to be afraid they will spoil the look-and-feel, as the system will apply the correct styles automatically in any event.
4. Finally, probably, the most important one – technical writers can focus on content rather than on fixing formatting issues. I once consulted a large international company that had exactly the same problem – technical writers used to spend too much time on playing around with styles rather than on actual writing. By moving to DITA, technical writers were then freed to concentrate on their main focus – properly creating the content that would explain the product.
So if DITA is so cool, why are there are still technical writers who do not feel comfortable with it and even resist adopting DITA in their companies? Stay tuned and read my next post.