Published on July 1st, 2013 | by Rahel Bailie10
DITA-to-Web: The next Big Thing – Part 1
DITA (Darwin Information Typing Architecture) vs the Web
For the last fifteen years, the Web CMS has reigned supreme as the way to manage larger volumes of content. Professionals at all in the digital space, from developers to designers to communicators, are familiar with at least some of the systems. From the blogging-platform-turned-basic-CMS (such as WordPress and Tumblr), to the behemoth systems (such as IBM WCMS and Adobe CQ), there are literally thousands of choices in between.
The Web World
These thousands of systems are not the same, but they are similar. Each system looks for its competitive advantage by adding some bells and whistles – one integrates social media better, another handles assets (documents, photos) better, one concentrates on workflow excellence. However, underneath all of those “special features” are a few common underlying principles.
At the risk of oversimplification, the systems follow these common principles:
- Make the interface easy for communicators by supplying form fields in which they can enter (or more likely, cut-and-paste) text, and add assets.
- Have an integrator create all the business rules (a.k.a. customized code) that governs how the content will be routed with the CMS to be displayed on the Web to users.
- Connect any post-publishing functions (such as content scheduling, analytics) to the Web CMS.
A Parallel World
In a parallel universe, a different type of content management software has quietly existed in the shadow of its more flamboyant counterpart. Its roots are in help authoring tools, that were originally meant to publish content to PDFs, or to tri-pane help. Somewhere along the way, it was dubbed “component content management”, which turns out to be an unfortunate choice. The similarity between WCMS and CCMS invites a jump to the conclusion that these systems work the same way. But it’s not an apples-to-apples comparison. It’s more like apples to fruit cake – two very different beasts indeed.
There are only about a dozen commercially-available systems on the market, and they work on a different common set of principles:
- The goal is not to publish content; it is an authoring environment that manipulates content and then lets a communicator “generate” the final content through a “build”, much like software builds are done. (The generated content can then be published or otherwise used for designated purposes.)
- Communicators work in an XML editor, with an authoring framework which gives them highly structured content, with granular control over what will be output and how the content will be grouped.
- As long as communicators understand how to work within the rules of the framework, they get to shape the content in ways far beyond the capabilities of any Web environment (where communicators use forms fields to enter content).
- The role of the developer is to create the rules that transform the content into a format that can be ingested into other systems, such as a display layer within a WCMS.
Until now, the most common application of this authoring method has been for online help, knowledge bases, and book-form content, such as user guides.
Is there a way to get the best of both worlds? Part 2 next week …