XML product literature
Your industrial products become part of well-oiled machines. Unfortunately, your workflow for developing product literature may not be as well-oiled.
Using desktop publishing tools (such as InDesign) to develop product literature means you spend a lot of time applying formatting, designing complex tables, and so on. These time-consuming, manual chores:
- Lengthen the amount of time it takes to get information to customers
- Make it difficult to update information quickly
- Provide many opportunities for introducing errors into content
XML-based workflows can solve these challenges in the development of product literature for machinery and industrial components. This post provides three examples of how XML can improve your processes for developing product literature:
- Creating specification sheets
- Managing common content across models, product lines, and departments
- Handling OEM rebranding
Creating specification sheets
Putting together spec sheets and datasheets in a traditional desktop publishing environment is just painful. It’s easy to introduce significant errors by merely transposing digits in a part number, for example, and let’s not get into the horror of composing tables in a DTP tool. By the time you finish the layout, the information may be outdated—and customers haven’t even seen it yet!
The exact process will vary depending on the database and other tools involved, but generally, you want a workflow that extracts the information from the database and formats it automatically. By eliminating the need for human intervention (typing information, applying formatting, and so on), you reduce the possibility of introducing errors and shorten the amount of time it takes to get content to customers.
Because the workflow is automated, you can also release updates more frequently. If you release specs or datasheets in electronic format (web pages, for example), you could set up nightly updates to distribute the latest information.
Managing common content across models, product lines, and departments
The different models of a product usually have shared features, and those common features can stretch across product lines that contain the same parts.
In a traditional desktop publishing environment, it’s very easy to end up with multiple versions of content about a particular part or feature because there is no “single source of truth.”
A modular content workflow eliminates this problem: you develop chunks of content and mix and match them for a particular information product (a user manual or web page, for example) according to product features. Generally, a component content management system (CCMS) manages the chunks, and authors can search the CCMS to find the modules of content they need.
Sharing content modules has two big benefits: the reuse means you’re reducing the amount of time it takes to develop content, and you present customers with consistent information within and across product lines.
Content chunks can also be shared across departments. For example, a table with specs for a part can appear in a user guide, a trade show handout, and on the web site. Even though that table may be presented with different formatting in those information products, the XML source is still the same for all. That’s the great benefit of XML-based content: formatting (usually applied through automated processes) is completely separate from the content itself.
You really need XML at the core of your content to implement industrial strength (ahem) modular processes. One XML content standard, the Darwin Information Typing Architecture (DITA), is specifically for developing modular technical content. Even if an XML standard isn’t an exact fit for your requirements, you can adapt and modify it. After all, the X in XML stands for “extensible.”
Handling OEM rebranding
If your company provides components to other companies in an OEM relationship, an XML workflow streamlines the rebranding of content.
The separation of content and formatting inherent in XML workflows means you don’t have to open up and modify multiple source files to change logos, corporate fonts and colors, and so on. Instead, you create a new automated formatting process (possibly using your company’s transformation as a starting point), or you apply the other company’s existing formatting transformation if they are already in XML. The correct formatting is applied automatically, saving both companies a great deal of time—and that automatic formatting means you and your partner dramatically shorten the time to market for OEM equipment. By the way, all this talk about the separation of content and formatting has another huge benefit: decreased localization costs and faster release of localized content because you eliminate the manual reformatting work associated with translating content.
XML workflows also provide mechanisms for quickly switching out company and product names, addresses, and so on. The modular nature of many XML workflows also enables a partner company to select just the chunks of information they need about an OEM component.
Even if two companies are using two different “flavors” of XML, scripting can automate conversion. It is much easier to convert XML to XML than to convert content in one desktop publishing program to another.
Desktop publishing tools are wonderful for creating visually rich information. But for product literature, you need a system that produces attractive content, speeds up content production, eliminates tedious reformatting work, and streamlines translation.
XML is a better fit for product literature.
Need more information about how XML product literature can help your company? Contact us.