At MadCap Software, we are often asked about the Darwin Information Typing Architecture (DITA) methodology and how it compares or relates to what we do. With this blog post, I will provide a high-level overview of technologies, capabilities, and comparisons of both MadCap Flare and DITA.

What is DITA in Technical Writing?

First, DITA is not a product; it is a technology, or more precisely, a specific XML implementation. To understand the origins of DITA, we must go back in time to the early 2000s at IBM. From discussions with IBM staff at that time, it is my understanding that the company was struggling with two issues. First, IBM technical communicators were struggling with the volume of documentation and document types they needed to create internally. Second, employees were also struggling with the massive amount of documentation they would receive from their vendors and contractors.

The combination of both of these issues, plus the need to find ways to merge and/or integrate both of those silos into the deliverables that IBM needed to provide to their end customers, presented a massive challenge for the company to overcome. The solution to this issue was the Darwin Information Typing Architecture (DITA), an XML implementation. It is important to remember, however, that IBM developed DITA to solve IBM scale problems with IBM scale resources. 

DITA Outside of IBM

The IBM team was quite proud of their work and shared DITA publicly for DITA implementation for the first time at the Association of Computing Machinery conference for the Special Interest Group on Design of Communication (ACM SIGDOC) in 2003. The conference was held in San Francisco and I was lucky enough to be in attendance for the presentation. Some of the core ideas of DITA were quite revolutionary for the early 2000s.   

What Are DITA Files?

DITA is rather simplistic in that it only has two primary file types. Every content topic has a .dita file extension and the extension .ditamap is used for the “DITA map” or outline files that group and organize the topic type files. 

Who Uses DITA?

Many companies use DITA. However, a more important question is “Who should use DITA?” Remember that IBM created DITA to solve IBM scale problems with IBM scale resources. The closer a company and their information architecture resemble IBM (managing millions of topics with dedicated programmers on the writing team), the better fit a DITA architecture workflow might be. However, the further one gets from the IBM model or information type, the more that DITA adoption may create a burden rather than solve a problem. 

Since DITA is a methodology and not a product, you cannot run down to the software store and purchase it. Adopters of the DITA workflow typically source an XML file editor from one vendor, a CSS/style editor from a second vendor, and a transformation engine (publishing engine) from a third vendor. Then, it is up to their own programmers to get all of these tools working and communicating together for the desired output format. Some early DITA adopters are now migrating away from the methodology. You can view a webinar of a case study where CM Labs migrated from DITA to MadCap Flare in order to modernize their publishing capabilities, but reduce their technical maintenance overhead. 

What About MadCap Flare?

If you think back to the very beginning of MadCap Software, it was several years after IBM had released the DITA standard to the public. It was also a time when the technical writing world was somewhat fractured. In addition to this new DITA format, you had tools that were easy to use, but not very powerful. Tools that created software help, but not much else. 

You had powerful print tools, but could not publish to web browsers. You had high-end content management systems, but they came with six-figure price tags and half-year long rollouts or longer. For most authoring teams, it was a painful time. The choices were A) Learn and juggle multiple specialized tools, B) Spend the king’s ransom on a high-end content management package or C) Hire a technical staff and program your own system based on DITA.

This was the genesis of MadCap Flare. MadCap software wanted to produce a publishing system with the power of DITA, the ease of use and editing of Microsoft Word, the print capabilities of the best desktop publishing packages, and to do it all at a price point that any small business could afford. Can this be? Can MadCap Flare really stack up against a DITA-based workflow? I like to use the following analogy to compare the two.

It is Like Automobile Racing.

In most of the world, Formula 1 racing is considered the premier top tier of automotive racing. Formula 1 race cars have the highest performance possible but also require an extremely large staff and a commensurate massive budget. That is because you cannot purchase a Formula 1 race car; you must design it yourself. You must have engineers, physicists, mechanics, welders, and more to design and build the car (and all according to very strict rules and standards) before you can even think about establishing the racing parts of the team such as a driver and pit crew. 

Formula 1 Racing
Top Speed220 miles per hour
Annual Budget$470 million US dollars
Staff500
The car is designed, engineered, and built entirely in-house.

However, in the United States, there is another popular type of automotive racing known as Indy Car racing. At a casual glance, you may not be able to tell the difference between a Formula 1 car and an Indy car. An Indy car can also go 220 miles per hour. The big difference? You can go down to the “race car store” and purchase an Indy car. You do not have to design it yourself. Your team can focus on your core mission of racing.

Indy Car Racing
Top Speed220 miles per hour
Annual Budget$15 million US dollars
Staff25
The car is designed, engineered, and built entirely in-house.

My point with this car racing analogy is that building your own DITA-based workflow is much like fielding a Formula 1 racing team. You will need much more than a skilled technical writer or author, you will need the programming talent and IT resources to keep the entire system up and running, all for just a few percentage points of increased performance. Many companies would rather go with an “Indy Car” type of solution where you can focus on your core business, and that is what it is like adopting MadCap Flare. 

Formula 1Indy Car
20x Larger StaffSmaller Staff
31x More ExpensiveCost-Effective
1-2% Higher PerformanceHigh Performance
Analogous to DITAAnalogous to MadCap Flare

So, is MadCap Flare Better Than DITA?

In many cases it may be, but not in all. Remember, the closer your company is to an IBM model, with IBM scale problems and IBM scale resources, then the added expense for those few percentage points of improved performance may be warranted. However, in a lot of cases, MadCap Flare will represent far more capabilities than your company will ever need at a much more affordable total solution cost, especially if your authoring team doesn’t have full-time programmers assigned and a supportive IT department. 

That is Pretty High Level, How About Some Details

MadCap Flare and a DITA-based workflow will have a lot of similarities. In both cases you will have:

  • XML-based workflow
  • Topic-based content/authoring
  • TOC or Map files to organize topics for publishing
  • Scalability

However, when we dig into the details some differences start to emerge.

 MadCap FlareDITA-based Workflow
Topic TemplatesAs easy as “Save As Template” to create a topic template with your corporate standardsThree rigid topic types, unless a “specialization” is written, complicating the workflow
MultimediaNative support for standard graphic and movie file formats; in addition, single-sourcing meta-data (conditional markers and variables) can be used inside of the bitmap graphics and movie files. It is now possible to single-source your multimedia assets without duplication. Imagine being able to rebrand a training video with every customer’s name in the video.Basic graphic and movie files can be linked
Look, Feel, and BrandingStyling done at the transformation (publishing) stage and defined by the author – no programmer needed; in addition, Flare recursively uses your defined templates and style sheets so that authors can see what their content will look like, for their choice of deliverables, while authoringStyling done at the transformation stage as written by programmers.
Creating Style SheetsNot just one, but three included Cascading Style Sheet editors (a simplified editor, an advanced editor, and a validating code level editor) so that any author at any skill level can define their style sheet for their corporate look, feel, and branding.Style sheet creation typically done outside of authoring with separate tools.
Cascading Style Sheet ExtensionsMadCap  Software recognizes that technical writers have very specific needs so we have built in support for advanced style functionality·         Auto-numbering (think figure numbering or table numbering)·         Style sheet variables (define common elements such as the company primary color only once in the style sheet without duplication on multiple styles)·         Code snippet support·         Auto breadcrumbs·         Dynamic effects (drop-down text, expanding text)·         And more.  As written by your programmers.
Micro-content CreationNative support with no external coding or programming required to support chat bots, virtual assistants, or augmented search results.Requires extra programming/transformation efforts.
Available TemplatesMadCap Software has provided more than 30 varied Project Templates such as Policies & Procedures, Online Knowledge Base, Product Brochures, Software Online Help, representing PDF, Microsoft Word, Responsive HTML5, eBook formats and more.Beyond our provided Project Templates anything you create can be saved as your own custom Project Template.No templates. IBM has provided the “Open ToolKit” which includes samples for your programmers to follow. However, many have used the Open Toolkit as a template, rather than an example, and that is why so many PDFs published from DITA look so generic.

There are many more details that we don’t have space for here, but to summarize, MadCap Software has built Flare to provide the same content-reuse and multi-channel publishing benefits of a DITA type (or other XML-based) system, but without the programming needs and IT overhead  — we put the power and the flexibility in the hands of the content developer or author. Visit our website for a more detailed comparison of DITA vs MadCap Flare, specific case studies and ROI benefits, as well as other informational blogs like “What is Structured Authoring?”