Modern technical publications: structuring structure with MindManager
By: Mike Ingledew
Modern complex products such as aircraft, ships, satellites and military hardware require the same intricate support elements around them. Support elements include everything from provisioning to maintenance and operation to product feedback. Data is the new gold, and product support is not immune to this fact. To make these complex system function as designed, it’s necessary to have highly detailed – and often complex- technical publications.
What is a technical publication?
The modern technical publication is a critical component of a support system. It is the single source of truth for a maintainer or operator, providing essential guidance on product use and maintenance.
To many, the technical publication is nothing more than textual and graphical information on a page, be it printed or electronic to guide the reader in a safe and ‘as designed’ way. We can forgive this impression many have of a technical manual as their interaction is with the page’s content.
Today, technical documents, which support major, complex platforms are no longer a simple write and print PDF process. The modern technical publication is now designed, configured, deployed, and integrated to multiple outputs, media and systems.
Before we discuss modern technical publications, let’s step back and look at what a traditional document contains.
Components of a traditional technical publication
If you look at the components of a typical, PDF-based technical document, you will see a general structure that most people follow.
This might include:
- Table of Contents
- List of Figures
- List of Tables
- List of Terms
- Materials and Apparatus
- Work Plans
As mentioned, these components are laid out in sequential order as part of a master Word or PDF document. Key stakeholders would then read this document either as a whole, or they would zero in on certain points and sections as needed.
This process, however, does not go deep enough in transferring knowledge to workers on the ground who may need to action these points in various unforeseen situations.
While a linear, text-based technical publication may be sufficient for a simple appliance like a washer or dryer, that it simply not the case for highly complex vehicles like airplanes or ocean liners.
In these cases, you need multiple highly complex technical publications. One for the pilots, ground crews, engineers, and so on.
This is where non-linear, interconnected, and digital technical publications come in handy, which has been a major catalyst behind the shift to a more modern approach.
Modern technical publications: how they’re different
Rapid changes in technology and the emerging capabilities of the Internet of Things (IoT) have impacted the technical publication’s role, how we create, deploy, and use information, far beyond page-level presentation.
Today’s technical authors’ engineer a technical publication based on various support domain inputs, desired outputs and broader product support data leveraging needs.
The technical publication is far more than the traditional words and illustrations on a page; structure and information behind the page are essential to integration, identification, and information location. Residing behind the page is information that can deliver real business value and benefit.
Add to the mix that modern technical publications must now comply with complex project rules and specification guidance. Specifications like S1000D are widely adopted to guide structured information production.
What is S1000D?
S1000D guides the modern technical publication definition and production process and introduces many new concepts to that of the traditional development process.
According to S100D.org. this process can be defined as:
“An international specification for the production of technical publications using a common source databases.”
SD100 is used globally in a variety of industries and products, including:
- Defense systems
- Civil aviation
A conventional technical document’s monolithic mindset has now changed to that of a modular construct, breaking information down into chunks of information. This modular mindset introduces new definition requirements for our content.
For example, the Data Management Requirements List (DMRL) is a must-do at the start of each project, listing all of the modular content a project will develop.
Developing critical project components like the DMRL is a time-consuming task, often requires external authorization and a method for sharing to non-technical publication contributors.
MindManager’s role is creating technical publications
At TDW, we have been using MindManager to develop and design a number of our S1000D requirements, including the DMRL.
Visualizing the DMRL in a structured way to share on the project is an efficient and friendly way for contributors to provide critical feedback. The ability to export the content of the MindManager structure to an S1000D defined Excel spreadsheet template for import into an S1000D Common Source DataBase (CSDB).
Along with the DMRL there are other uses for MindManager. For example, defining an S1000D Standard Numbering System (SNS), listing our project Information Codes and making Business Rules Decisions are examples of how MindManager can add value to our S1000D processes.
Because of both of these use cases, MindManager eases the design and configuration process for many projects. This process aids the visualization of complex technical publication structures, and sharing with team members that may not understand the S1000D structures yet still have to authorize and collaborate with the publication production process.