Two weeks ago I wrote about information design and information architecture. That leads us quite nicely to today’s topic, which is Darwin Information Typing Architecture or DITA and taking it into use.
If DITA is totally new to you, this paragraph is for you. DITA is one of the most popular ways to produce and publish information in a modular way. Its main principle is that information is divided into different topic types: conceptual information is written in the concept topic, step sequences are written in the task topics, and reference data in the reference topics. You can combine these topic types in any way you want as each topic must be a standalone module without obligatory topics to read before or afterwards.
DITA saves money, time, and effort in writing, illustrating, translating, and publishing. That’s quite a selling point and it leads to a question that many Adina clients present to us: how should they take DITA into use? The situation is different in each company, but here are 5 tips for the start of the planning phase.
1. There must be at least one person in the company who really understands what DITA is, how to use its features, and which DITA variant is suitable for the company. It’s a good idea to spend time in the beginning to build the necessary know-how. In 2010, I was lucky and I was able to start the project by reading the entire DITA 1.2 spec and underlining and labelling it with post-its to mark up the best bits for our company. Because the spec is now new and improved, it’s much easier nowadays. The biggest problem might be the time for all this studying because that’s no light bedtime reading: for example, the so-called full DITA spec for the latest 1.3 version has 1189 pages…
2. Think about the use cases for each interesting feature. Ask yourself my favourite question: is there a real reason for using them? DITA is full of interesting features, but if there’s no real use case in your company for, for example, using conkeyref, perhaps that could be added later? Plan big, start small.
3. Design everything end-to-end. Don’t just focus on one part of the process, such as writing the information. That leads to problems later on when you get to translations and publishing. Remember another favourite: get out of the silos. Talk to each other. Write down all your requirements in the beginning and prioritise them.
4. Dare to make decisions, demand that you have the power to decide, give people the responsibility to decide. If some decision is less than ideal, it’s usually changeable. The biggest decisions like which tool is selected are understandably difficult to change, so check out #3: plan properly, do your requirement analysis, prioritise your wishes.
5. Stick to vanilla DITA as much as possible. Avoid specialisation and proprietary features. This way you won’t be tied to a tool and your information is easier to process in other tools. I’m not saying that specialisation is a bad thing, it a core DITA feature that you use to make the open standard fit your case. I’m also not saying that proprietary features are bad. I’ve used both successfully in multiple different projects. At this stage, check out #1 and #2: understand what you’re doing, know why make the choices you make, and understand the pros and cons of each choice. Count your ROI for each choice.
It’s not rocket science, but still it’s sometimes easier to have a more experienced person to help you or just to have someone to talk to. That’s why us consultants are here.
This leaves one big question unanswered. How do you justify to company management that first you must spend money to save money later? That’s a very good question indeed. Let’s get back to that one later.