Content development no image

Published on August 12th, 2013 | by Rahel Bailie


A Standard for Exchanging Stories – Meet DITA Maps

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 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.

BBC web "page"

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.


Share this post:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • StumbleUpon
  • email
  • Facebook
  • LinkedIn
  • TwitThis

About the Author

Rahel Anne Bailie is a synthesizer of content strategy, requirements analysis, information architecture, and content management to increase the ROI of content. She has consulted for clients in a range of industries, and on several continents, whose aim is to better leverage their content as business assets. Founder of Intentional Design, she is now the Chief Knowledge Officer of London-based Scroll. She is a Fellow of the Society for Technical Communication, she has worked in the content business for over two decades. She is co-author of Content Strategy: Connecting the dots between business, brand, and benefits, and co-editor of The Language of Content Strategy, and is working on her third content strategy book,

One Response to A Standard for Exchanging Stories – Meet DITA Maps

  1. Don Day says:

    Noz, I debated whether to put this reply in a post and reference it here, but I reference your BBC image directly, so please put up with this brain dump.


    I liked your comment about “just how obsolete the term “web page” actually is.” Maps are fundamentally just lists of links with a specific encoding in the DITA world. In the Web world, as you pointed out, you find maps… er, lists… everywhere in the source view of what comprises a page: nav lists, archive lists, category lists, blogroll lists, featured articles lists, slider lists, post loops, search result lists, and index result lists (in the REST world, every well-behaved segment in a URL that does not refer to a specific resource is an “index” that is encouraged to produce a collection, which is simply a query result set, like files in a folder).

    Although you didn’t show the URL for the page, I think there’s a good chance that item 1 is indeed a primary resource, and the title was probably in the URL for SEO purposes. I assessed the organization of the rest of boxes in this way:

    * Items 4, 6 and 8 are inline blurbs that are tightly related to the article content itself.
    * Items 9, 10, and 12 are more loosely related by category, and item 12 provides social links probably keyed to the article’s URL.
    * Items 2, 3, 5, 7, and 9 are sidebar content that are a list of standard widgets, probably selected more by business rules and marketing value than as direct relations to the story itself.

    Each set has a specific reasons for what is in it and where its members go on the page. One of those policies is the adaptive content rule for limiting what low-bandwidth devices get to the highest value chunks.

    So here we have three obvious lists: one created by editorial policy related to the primary resource, one created by content category selection, and one very likely created by marketing and branding policies. And don’t forget the implicit list that defines the sequence of header, navbar, body, sidebar, and footer regions, and the site map that organizes all the categories into hierarchies for Google ranking and associations.

    What I’m getting at is that each of those rationales represents a query of some sort in which a repeating data model is returned as an array that is decomposed into lists for rendition–most of them being of the ordinary ul/li/a variety in HTML. If ever these ephemeral query results needed to be serialized in a standard format, you could actually do so in DITA map format. At that point, the enormity of alternate uses beyond the Web really blossoms. Let’s say your marketing department needed a snapshot of what was in the sidebar on the day this article was first published; you can show them an outline that represents the selection policy results, driven by that DITA map. Or even print the list of widgets as content for review. Then throw the map away or archive it as a succinct playlist of that page’s query-based organization. Like ul/li/a structures, it’s just a representation of a state, but it can drive more downstream views of those endpoints than HTML tools typically can do with list items. In fact, that’s probably why XML is popular for RSS–we are talking about the ability to syndicate other parts of a page view besides just the primary resources alone. Multiplicity indeed!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Back to Top ↑