Do you ever get in your car, turn the key, and just drive? Probably not. Usually you have a destination in mind, and a plan of what you want to do once you get there. Companies that want to stay in business more than a few days start off with a set of goals—a destination—and a plan for how to achieve them. Strategy is essential to any business, and if you’re planning to adopt DITA, then a DITA content strategy is an essential element in your DITA success.
Those who are new to DITA will find it challenging to write their own content strategy, but there are resources–consultants, books, and training that can support development of this key element. If you’re still a bit unfamiliar with DITA itself, make sure to read our post on what DITA is first.
Why You Need a DITA Content Strategy
Adopting DITA without a content strategy is like driving without a map or a specific destination. Without one, you’ll eventually get somewhere, but it might not be where you wanted to be. And you may need to backtrack a lot to get there.
You definitely need a DITA content strategy before you start looking for tools. If you plan on picking up materials to build a new garage, you’ll need a different vehicle than the one you take to go to dinner at a fine restaurant. The details that you hammer out in your content strategy are how you’ll identify which tools you’ll need and what requirements they’ll need to meet.
So before you start shopping for DITA tools, start writing your content strategy.
Features of a DITA Content Strategy
Your DITA content strategy should include the following elements, to ensure management buy-in and team direction:
- Goals
- Information Model
- Reuse Strategy
- Metadata Strategy
- Publishing & User Experience
- Processes, Workflows, & Reviews
- Human Resources
- Tools & Tool Candidates
- Other Factors
Goals
First you need to confirm your DITA goals. Your DITA content strategy starts with goals that define what you’re trying to accomplish with DITA. The rest of the document details how will you reach these goals.
You might include increased reuse of x%, consistency across product lines, authoring time shortened, 90% of review times met, or content targeted to specific users.
Make these goals concrete. Concrete goals can be measured, and that means you can actually measure the “before” versus the “after” to show management and other companies how successful you’ve been, thus proving your return on investment (ROI).
Information Model
Use this section to determine which elements you will use, how, and where. Also use this section to outline the elements you will not use (like <i> and <b>) and why.
This is where you’ll make a decision to include, for example, <shortdesc> elements in every topic (a best practice for most use cases) or nowhere (it’s an all or nothing decision).
Reuse Strategy
Identify the kind and level of reuse you expect to see and what DITA mechanisms you will use (map, topic, keyref, conref).
Metadata Strategy
Use this section to determine how will metadata be used, what attributes and values will be used and for what purposes.
Publishing and User Experience
This section describes what you want the end user experience of your content to be.
- What formats will you publish to?
- Where will you publish?
- How will the users access the content?
- How will they search/find specific pieces of content?
- Will they be able to filter by version, OS, role to find the content that is specific to them?
- Will you publish updated topics when they are approved? On a release cycle?
- What metrics can you gather about your end users?
- How will users rate and comment on content?
- Will users be able to submit their own content and if so, how will that be moderated and controlled?
- How will you automate the publishing?
Although it’s very difficult to imagine the end result sometimes, this is an important section to include because it will help you define exactly what tool(s) you’ll need to publish. Think of this section as defining the high-level requirements of your initiative.
Typically, you won’t be able to implement a lot of what you plan here immediately, but you’ll need to have the infrastructure to make it possible. For example, if you decide content should be filterable by operating system, then you need to include how authors will mark their content as applying to a specific operating system in your Metadata Strategy.
Processes, Workflows, & Reviews
Processes and workflows can benefit from some incredible streamlining through the content lifecycle, from authoring to reviewing and publishing.
Use this section to define your ideal workflow for the content lifecycle, like the review cycle. Exclude tools for now because your requirements here will help you determine what tools meet your standards. You’ll want to answer questions like:
- Do reviews need enforceable dates?
- Do you need to be able to audit review comments and changes made based on review comments?
- How many sets of reviews will you have, who is involved in each one, and when do they occur in the content development cycles?
- Will you assign content to a set of reviewers?
- Do you want automatic email notification and linking to the content to be reviewed?
- Are reviews on topics, submaps (like chapters or Agile groupings), or maps?
Although much of this will be a guess when you first draft your content strategy (if you’re not using consultants), you’ll then be able to shop for tools that meet as many of these planned requirements as possible.
Human Resources
This section lists high-level resources that need to be acquired or are available in-house to leverage. This section lays the foundation for a full project plan.
If you decide you need to hire full- or part-time help (like a consultant or a DITA Open Toolkit developer), this is where you’ll outline the resources and necessary skill sets.
Tools or Tool Candidates
In this section, you want to identify the types of tools that you anticipate needing. If you already have some in house or if you are required to use something in house (like SharePoint), then this is where you would outline which tools and how you anticipate them being used. From this list, you’ll develop detailed requirements, then create a short list of candidates that meet those requirements, and finally ask for trials and demos of likely candidates. You’ll create a pilot (a hands-on trial with your own content) with as many of those tools as you can.
- XML Editor
- CCMS or other repository
- Publishing
- Review
- Translation
- Other (like Acrolinx for vocabulary control)
Other areas
Depending on your use case and business requirements, you may need to address some other key areas in your DITA content strategy including:
- Risk management
- Governance
- Standards
Resources
Book Review: Content Strategy 101 by Sarah O’Keefe and Alan Pringle
