Guest posts for the next couple of weeks by Noz Urbina, who took my request for a guest post (while I recover from surgery) so seriously that he wrote enough for several posts. As the overall title says, DITA has a flexible way of helping authors be in control of their content, and eliminate the development bottleneck. Noz may call this “exchanging stories” while I might insist that it’s “creating new perspectives” but whatever our terminology, the concept is the same. We agree that a lot of corporate content can have many good lives, if created in a shareable way in the first place, and that there should be a standard way of doing so.
DITA Maps in a Nutshell
A DITA map is a file that defines how to pull together modules of DITA content into a contextual structure for users. It could define the structure of many deliverables, such as portions of the navigation for a website, the table of contents in print material, or the heading structure of a brochure or flyer. The offer a powerful, standardized tool to address to the core content problems of reuse across multiple channels and contexts, and to provide a framework for author-driven structure and semantics for today’s content needs.
Page-level Reuse Revisited
In “DITA-to-Web: The next Big Thing – Part 2”, we learned how DITA could be used to deliver the right content to a specific user profile, while still having only one actual module of content to manage, review, translate, and so on. This reuse of content across different contexts alone is of great benefit when compared to non-semantic, unstructured HTML blobs, which required us to duplicate content across various assets in our CMS to have to right content appear in all deliverables.
The ability, however, is focused at the module level. That is to say, all the content is part of one logical block of content – in the old terminology this would the “page level”, but, obviously to some, this terminology is badly outdated and I need to address it before I can continue.
Beyond Web “Pages”
You may have already heard a lot of commentary illustrating that today’s web world is no longer made of “pages”. Take the BBC.co.uk example. The content that’s loaded when the browser hits the address is various modules that have converged to create the desired result.
I’ve numbered this screenshot to illustrates how many modules this “web page” is really made of. In this case, on the desktop, it’s 12 modules.
When viewed on a Smartphone, we go from 12 modules to 4 (all but 1, 9, 10 & 11 disappear).
Whether twelve was already far too many, or whether it’s best practice to feature different content on different devices are not a relevant debates to this article – the important part is that the BBC wanted to do it, and so it did.
In the same way that specific portions of the content might vary for different contexts in a single module, as the DITA to Web article described, the selection of modules themselves might vary as well. If we theorize, it’s easy to imagine that for a regional audience, or subscribers that have access to certain special content, you might have the same core assets surrounded by different modules. You might also have the same modules, but with slightly or very different content on another web address. Or a combination of the two.
The net result is an enormous multiplicity of possibilities when looking at the content on any one address on the web. I think this starts to make clear just how obsolete the term “web page” actually is.
The Multichannel Angle
I’ve made an argument for modular reuse and haven’t even left the browser to discuss other channels such as print deliverables, in-store kiosks, or content for devices such as smart televisions.
In the enthusiastic debate on the Google Group after Rahel’s third post, Karen McGrane contributed scenarios where it would be very useful to string together existing content modules into new deliverables:
“Say NYTimes puts out a big trend piece on the Paleo diet. We [magazine publisher] have a lot of old content on that topic, and 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. But right now we have no easy way to access this archived content, so it would take too long to produce.
We [entertainment brand] spend too much effort firehosing content onto the homepage. We put up new images and stories and they fall off the homepage almost immediately, replaced by fresh content. We know we should take some of those resources who are creating content and shift that effort to finding new ways to make existing content findable, browsable, and reusable. But as an organization, we just don’t think that way.”
Here, whole collections of modules might be strung together to create a “multi-URL structure”, which then, itself, becomes a reusable asset, across formats. Although we have HTML files and RDF triples and microformats, there’s not really anything in the traditional web world of standards for describing these multi-module structures.
Next week, we continue with more discussion around DITA maps, strengths and weaknesses of different authoring systems and how to use them to their best advantage.
- When technology is no longer disruptive, but confounding
- Content strategy and design thinking
- The Summer of DITA becomes The Autumn of…?
- Authoring in DITA: the good, the bad, and the sometimes ugly
- DITA Maps and the Real World
- A Standard for Exchanging Stories – Meet DITA Maps
- Holes in the Template: Piping content into the CMS
- To DITA or not to DITA: That’s a Good Question – Part 2
- To DITA or not to DITA: That’s a Good Question – Part 1
- DITA: Not Just for Technical Content
- Content classification and findability
- Content development
- Content management
- Content strategy
- Information design and usability
- Professional development
- Social media
- User experience