Balancing the standardization of structured content against creative requirements is not just about formatting. When companies choose an XML standard, such as DITA or DocBook, they must evaluate whether to use the default structure or modify it to better fit requirements. The discussion about such changes is a creative process itself. When should a company change default structures?
A company implemented DITA to improve the control over conditional content, support responsive designs for phones and tablets, and manage increasing localization requirements. Content was previously developed with desktop publishing software and distributed in print and PDF. Guides contained procedures with more than 100 steps, which included substeps and sub-substeps.
By default, the DITA standard does not permit sub-substeps in the task structure. The content creators requested the addition of a sub-substep element.
Scriptorium’s information architects suggested evaluating the efforts required to either modify or maintain the default structure.
Modifying the default structure (through a process called specialization) would entail the following work:
- Developing and testing the structure customization
- Implementing the change in authoring tools, the component content management system, and stylesheets for each type of output (PDF, HTML, Help systems, etc.)
- Distributing the customization to localization vendors and ensuring their tool chains support the change
- Training new writers familiar with the default structure on the customized structure
Preserving the default DITA structure for the procedures would require the following effort:
- Rethinking the structure of procedures so that they did not include sub-substeps
- Rewriting many procedures to follow the new methodology, which would break up lengthy procedures into smaller related procedures
The content creators were immediately resistant to the idea of rewriting content to match the default structure. They argued that the effort would be too significant due to the large number of procedures. The writers’ bias against the new approach was likely increased by the perception that rewriting was an implicit admission that the current procedures were poorly structured.
The information architects acknowledged that rewriting the procedures would require great short-term effort. However, they believed that the overall benefits of maintaining the standard outweighed the rewriting effort. There would be no costs for implementing and maintaining structural changes for the company or for its localization vendors. New writers with DITA expertise would not need training on custom elements.
More importantly, adhering to the standard offered compelling long-term benefits. The information architects rewrote some procedural content in the default structure. The samples demonstrated how shorter procedures increased opportunities for content reuse, which would reduce writing time and improve consistency. Also, the information architects believed it was essential to consider users reading content on the small screens of phones and tablets. Phone and tablet owners would more easily comprehend shorter procedures.
Ultimately, the content creators and information architects were not able to agree on an approach. The structural changes were not implemented in the pilot project to stay within the project’s budget. However, after the pilot was completed, the information development group hired its own full-time information architect and intended to reevaluate the customization with that resource in place. (Not every consulting engagement has a happy, tidy ending, unfortunately.)