In the previous post, I talked about some arguments why DITA could be a good choice for your content. Today, I’m going to discuss some popular beliefs about DITA and explain why each of them is true or false.
DITA is all about reuse, single sourcing, and reducing translation costs
True, but it’s not just that.
In general, DITA is about content automation. For example:
Automated content assembly: content that addresses a specific user’s issue can be automatically assembled out of stand-alone pieces of information and delivered to the user based on the user’s profile, product configuration, bill of materials, and so on.
Dynamic change of content representation: for example, we’ve built a solution that automatically converts complex textual procedures written in DITA into interactive flowcharts.
Making chatbots smarter by feeding them with content that can be intelligently parsed and processed to find an answer that precisely addresses the user’s question.
…and many other examples when DITA enables the level of content automation that goes far beyond traditional reuse and single sourcing.
With DITA, making content reusable requires implementation. With a non-DITA solution, content becomes reusable as soon as you create it.
Your content will not become reusable just because you split it (or a tool automatically did it for you when importing your current content into its format) into smaller chunks. Making content reusable is a design task in the first place. A technology can only support it.
To make content truly reusable, it has to meet certain criteria:
Content granularity should match user’s context granularity. To address a specific user’s issue, the content provided to the user should be determined by a combination of multiple factors comprising the user’s context: the user’s profile, product, details of the issue, etc. These factors may come in different combinations, so the content should be granular enough to allow content publication and delivery tools to match content components to the specific situation.
Content should be written in a context- and delivery channel- independent way. Otherwise, its reusability across different situations and ways the user engages with the content will be limited.
Content should be structured in a way that makes assembling different pieces of content smooth.
This means reusability requires an information architecture to be built anyway, regardless of whether or not you are going to use DITA. Just taking an existing content and splitting it into chunks alone rarely improves the quality of your content. Garbage in-garbage out. In this sense, implementation would be required in any event, if you want to make your content truly reusable.
Who cares what's under the hood as long as your goals are achieved?
It depends on how you see your strategic goals.
Some opponents of DITA say that as long as the tool provides all features you need, you don’t really need DITA, and don’t have to worry if the tool uses a proprietary content format. Let’s see whether you do need to take into a consideration what the tool has under the hood.
Suppose you’re looking for a home security camera that would let you monitor what’s going on at home while you are away. You have a talented friend who is willing to build this solution for you. That custom solution would include all features that commercial products provide, and maybe even more.
There’s only one drawback: your friend isn’t going to use any industry standards, including the format for recording the video. The camera she’s going to build will be based on proprietary standards, which none of the existing home security products are aware of. But you’re not worried: you’ll be the only user of the camera, you are going to use only the app your friend would develop for you to watch camera’s recordings, and don’t have any other software that would need to access the video footage.
If that’s the case, and it’s not going to change in the foreseeable future, the only thing you’d have to worry about is who is going to help you if the camera stops working and your friend isn’t available. If the total dependency on your friend is not your concern, perhaps you’ll be fine.
But if you are going to grow your single camera solution into something bigger to make it work with Alexa or Google Assistant, integrate it with additional security cameras and other apps, or maybe even smoothly replace it with an alternative solution, you’d better go for something standard.
The same applies to DITA. If your only goal is to get a single sourcing solution, and in the long-run you feel comfortable with:
Locking-in to a specific vendor
Forcing everyone to work with the same tool provided by the vendor, regardless of their goals and working habits
Not looking into possibilities to expand the benefits that you’re getting to other teams
…then you really don’t have to worry about what you have under the hood and may let the tool define and control your work. But if you have a long-term vision of how content automation could be enabled across teams, then you would need a content infrastructure based on a standard recognized by multiple players on the market.
DITA is for big organizations with deep pockets
From the previous answer, you could get an impression that adopting DITA makes sense only in case you are planning for an enterprise-wide deployment, and small technical publication teams wouldn’t benefit from DITA. While in some cases, the return-on-investment is easier to justify for big organizations, it doesn’t mean small teams should forget about DITA.
DITA is still beneficial for small teams when:
They have a lot of content to reuse – repeatable content isn’t a privilege of big companies.
They are looking into reducing translation costs. For example, almost all our European customers are small publication teams with up to 10 writers (in many cases, it’s literally just one or two writers). One of the key drivers that brought them to DITA was high translation costs. With DITA, they could reduce them by up to 70%. Since all translation vendors, including makers of translation management and translation memory software, in our days work with DITA, it makes a lot of sense to choose DITA as a content standard.
They want to choose the tool chain they feel comfortable with. For example, quite a few of our customers used unstructured FrameMaker and wanted to continue using it after migrating to DITA. Because FrameMaker fully supports DITA, it never was a problem. There’s a good choice of publishing tools that support DITA, so they can select whatever works for them in the best possible way.
They don’t want to be locked-in to a specific vendor on any stage of the content process, whether it’s authoring, reviewing, translating, or publishing content.
They want to enforce structural consistency of their content.
A beauty of DITA especially for small organizations is in ability to adopt DITA in phases. You can start with simple and modest goals (such as increasing content production speed and reducing costs of content creation and maintenance) and eventually introduce the increasing level of automation on all stages of the content process.
In the next post, we’ll discuss other popular beliefs about DITA, like “DITA requires a significant learning curve”, “You cannot use DITA without specialization”, “Authoring in DITA is like writing a code”, and some others.