Published on August 19th, 2013 | by Rahel Bailie0
DITA Maps and the Real World
It would be nice to have called this post “DITA Maps and the Real World: A Love Story” but how can practitioners love a tool they don’t know about, because it’s not available in the system they’re using or no one has educated them about the potential? Noz Urbina elaborates on last week’s post with a closer look at how DITA maps work and why, once you’ve used them, you’ll never want to go back.
The (In)famous CMS Form
In a typical Web CMS (WCMS), the way to construct the somewhat complex module relationships, as discussed in last week’s post, is with the ubiquitous CMS authoring form page. In the fourth post of this series “To DITA or not to DITA: That’s a Good Question – Part 1” there was this diagram of a typical form:
These forms exist for some very good reasons, but there are also many downsides to them. Forms are advantageous because they:
- Control input structure (at least to some degree) for consistency.
- Can provide “pick lists” of things like media assets, any manner of other controlled items like names, places, part or product numbers.
- Can guide the use of metadata (again, at least a little) by providing a pick-list of taxonomy terms or keywords for the asset.
- Help prepare content for Responsive or Adaptive Design deliverables because of the additional structure imposed.
Forms are also the downfall of many websites because:
- You need a CMS integrator or a heavy-duty IT person to build a form according to your needs.
- Once a form is built, changing it is usually a costly or complex affair. This is for financial, bandwidth and technical reasons, but possibly worst of all, because all sorts of downstream processes depend on what’s coming out of the form. A responsive design might not respond so well if you change the fields being fed into it. Each form is custom built, so all the downstream processing is custom, as well.
- Forms can get visually extremely complex, leading to user stress.
- There are few organizations who are able to properly structure the part which just says “content”, i.e., the “BLOB”-y central crux of the asset itself is left uncontrolled.
- Forms are, in every way, completely bound to the specific software package they were made in.
- Forms are everywhere, but there is no shared standard. You can only author your content in one tool, and every channel you publish it through must be customized to match your form, or instead, you must sacrifice things you want in your content because you can’t afford all that customization.
The result is generally that forms are:
- Too general for the metadata-rich consistency needed for multichannel / multiformat output – e.g. you can buy a responsive web template for WordPress for $40, but it’s going to be too generic to support complex, reusable, multi-channel, semantic content.
- Are unusable, inappropriately rigid author-torture-devices. As necessary content variations or re-combinations are discovered, this leads to work-arounds and hacks by authors desperate to hammer their round pegs into the square holes provided.
Rick Yagodich wrote an article on handling structure and semantics in the blobs. However, as what we’ve described about DITA so far, Rick’s article talks about content at the module level. Even if we break content up into nice modules, we don’t have a standard way of bringing it back together into something useful for the user.
A Road Map Through the Modules
DITA provides a solution for these greater-than modules that is universal across all software packages and channels. It’s called a DITA “map”. The DITA map (also often written as DITAmap or DITAMAP) can work simultaneously like a table of contents or site navigation map, but it’s actually much more than both.
A DITAmap contains little or no content actual content. In it you define:
- The modules you want
- The sequence and hierarchy you want them in
- Any special metadata for the modules, specific to the structure you’re defining
- Any story-level navigation and linking (to other contained modules or to external URLs)
- Audience, platform or other content profiling metadata for filtering modules in or out
In this diagram from our book, you can imagine that the DITAmap defines the black interconnecting lines in each deliverable:
Point number 4 above is deceptively simple. The map gives you the ability to create a little “bundle” of relationships and navigation that could be plugged into one deliverable, like a corporate site, and then perfectly be hived off with no extra work, to be fed elsewhere. This could be a microsite, its own mobile app, a print system to run off a hard-copy, or even a partner organization, if your partner uses DITA too. If we read Karen’s reuse wish again, suddenly it seems much more achievable.
“…it would be great to quickly pull it all together into an ebook that we could sell as a Kindle Single. We could capture that attention and make money off our back catalog.”
Being able to control metadata within a map means you can retrospectively apply things like keywords, search terms, short descriptions (for example for different SERPs depending on the context) or taxonomy tagging to existing assets without having to rework them.
Because the content is all standards-based, you can dump all your content from CCMS A and load it up in CCMS B, and all of your metadata and relationships are still intact. This saves some companies millions of dollars just in in migration costs.
Why a map?
To use an analogy, A DITAmap is to content as a travel guide is to the physical world.
You have all the “world of content” out there, and the map guides you through, telling you:
- Where to go
- In what order
- What routes are available between stop-offs
- Anything special you should know when you’re there, like the names of monuments or restaurants.
Like a good travel guide in the digital world, you can apply contextually-driven filtering that “turns on and off” certain things on the map that you’re interested, for example, all the Chinese restaurants or locations of your bank.
In Rahel’s example, she explained this filtering for use inside module content. If the context is “users with 4G phones”, you could turn on/off the 4G-marked content. In the DITAmap, you can turn off the whole module if needed. Other users then won’t be distracted by links or content not relevant to them at any point on their journey. I have some clients creating over 50 different “expressions” of the same content in this way.
Serving multiple contexts – the BBC example
If we go back to the BBC example, in one context (mobile), 12 modules were used. In another (desktop web), 4 modules were used. But what if we had many more contexts? An organisations might easily have 5 different user types, 20 countries, and 10 product configurations. Here is that multiplicity word again, and this is where a DITAmap really shines.
Without any IT support or a custom web form, the DITAmap allows the author to drive what modules they want, in what contexts, and be 100% sure that their work is multi-channel and automation-ready.
Some customization of your DITAmap editor often makes the process even easier, but off the starting block we’ve retained all the benefits of a form in a standard specification that all off-the-shelf tools can edit today.
Beyond DITA in the CCMS
DITAmaps are so useful that they may one day see adoption for use on regular HTML modules. If organisations can’t justify migrating all some particular content to DITA for multiformat, many they can just clean it up a little and “re-wrap” it in DITAmaps for web and mobile web use. This would allow them to leverage their assets for new user and organizational value, which is really the point.