Home » main blog » Currently Reading:

Let’s Get Real: The Secret To Making The Case For DITA Adoption To The Rest Of The World

June 8, 2008
These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • StumbleUpon
  • email
  • Facebook
  • TwitThis
19 Comments

By Scott Abel, The Content Wrangler

The Organization for the Advancement of Structured Information Standards (OASIS) is seeking participants to help move the adoption of the Darwin Information Typing Architecture (DITA) forward, pushing the value proposition of DITA outside of the technical documentation arena. It’s called the DITA Adoption Technical Committee—and ironically, there’s nothing technical about it.

The Purpose of the DITA Adoption Technical Committee

The OASIS DITA Adoption Technical Committee members will collaborate to provide expertise and resources to educate the marketplace on the value of the DITA OASIS standard. By raising awareness of the benefits offered by DITA, the Technical Committee increases the demand for, and availability of, DITA conforming products and services, resulting in a greater choice of tools and platforms and expanding the DITA community of users, suppliers, and consultants. Since DITA adoption is stronger in the US than in the rest of the world, especially the European Union, the Technical Committee will actively solicit participation from non-US members and help to facilitate providing information promoting DITA adoption globally.

Image I fully support the need for a committee designed to educate the marketplace on the value of DITA. It is exactly what’s needed in order to move the standard forward. But, in order to make the committee a success, we need excellent communicators with the gumption, know-how, and network to get the word out about the many ways DITA impacts the world and those who live in it. And, we need them to be paid for their efforts.

As a former journalist, I can speak to this issue with respect to publicity. Reporters don’t respond overwhelmingly to press releases, they don’t need (nor want) to understand the details involved in creating DITA maps, nor the convoluted way in which standards are created. What they want are sexy stories of interest to their readers/viewers. We need people who will use new media platforms to expose people to the many success stories that are popping up like weeds after a big storm. There are many cool and sexy uses of DITA that are in use right now. But, it’s unlikely most of our readers know much about them, because there’s no one whose job it is to promote them full time. And, if you don’t know about them, then readers of more general interest business publications—and the folks who run the major corporations around the globe—don’t either.

What’s Needed?

Volunteer PR folks don’t have enough at stake to work as hard as required to get the attention of the media. Sure, they can get DITA mentioned in the obvious places, which is not impressive. Blogs, magazines, and newsletters in the content and technical communication space are hungry for DITA news, but they don’t have a major impact on adoption outside of their own subscriber-base.

What’s needed is a concerted effort to educate major business magazines, airline publications, technology television shows, technology reporters for major newspapers, bloggers and podcasters influential in the technology and general business spaces to report on real-world solutions that just happen to be made possible because of DITA. We also need analysts and venture capitalists to understand the implications of adoption and the value proposition DITA may provide. Money flows from these sources, either directly or indirectly, and to ignore them is a bad strategy.

DITA cannot be the focus of DITA adoption and publicity efforts. Neither can OASIS. The approach we’ve been using is so 1996. It’s old-school and again, it’s not working or there would be no need for such a committee.

imageThe focus has to be on the human impact. How does DITA help make the world a better place? How does it make it possible for humans to interact with one another? How will it help everyday humans in their everyday lives? How can it help governments better serve their citizens? And, more specifically, can it help save lives in a disaster? Yes. How about saving taxpayers money? Yes. Can it help middle school teachers provide better learning materials to their students? Yes. Can it help law enforcement better protect those they serve? Yes. Can it help prevent puppies and kittens from being euthanized? I’m not sure, but maybe.

All of the human interest topics that sell papers and tv shows need to be the focus. It’s no mystery that articles and TV shows about kids, puppies, love, sex, politics, religion, and other human stories are most interesting to the population at large. Therefore, it only makes sense that we find ways to tell the DITA story without making it (nor OASIS) the focus. There are many ways to do this, but again, it won’t likely happen with volunteer labor.

Filter Out the Noise and Non-sense

Promoting the adoption of DITA is not the same thing as promoting OASIS, and yet, I haven’t seen many news releases that focus in on the benefits of DITA without littering the news with way too much self-serving marketing hype designed to accomplish a totally different goal: keeping OASIS in the news (and therefore, attracting more sponsors). This same problem is also a byproduct of most—but not all – vendor marketing programs aimed at getting your interest in DITA to lead to you purchasing their products. Just when they get you interested, they have to declare they are the “world’s leading vendor” (which anyone with a dictionary knows is not possible for all vendors to be—one leads, all others follow) or they make up non-sense vocabulary phrases like “fully DITA-compliant” (there’s no way to validate this claim) or “smart elements” (as opposed to “dumb elements”) that don’t mean anything. They just can’t help themselves.

In my book, this is one of the biggest hurdles to DITA adoption in the mainstream. Let’s strip away all the noise that prevents normal humans from understanding what we technology addicts find so wonderful about DITA, XML, content reuse, content management, dynamic content, personalization, and so on. Let’s find ways of getting ourselves noticed by the greater public by speaking to them in a language they understand. You would think in a community dominated by communication pros, this would be obvious. The first rule of good communication is to know your audience. The second is to understand the intent of your communication. And yet, most messaging about DITA ignores these rules. It’s almost as if the folks creating these materials don’t have any clue who we are nor how to get our attention. And, if they can’t figure that out, it’s no wonder their message is being filtered out by the general business press and by business leaders.

It’s so obvious to me. Delivering the right information, to the right people, at the right time, in the right language and format is the promise of DITA. Shouldn’t we try using these same principles while trying to attract attention to DITA and promote its adoption. When I am given the opportunity to make this case, most folks respond with a resounding, “Duh! Why didn’t we think of that?”

The Bottom Line

In order to get the attention of the mainstream media we need those with some “skin in the game” (a stake in the outcome) to provide the financial resources necessary to fund a proper outreach program designed to sell the interesting aspects of DITA in ways journalists and business leaders care about. We’ve relied on the volunteer labor pool long enough and it’s not working. Well-meaning consultants who help to form and improve the standard cannot be expected to have the time, energy, resources—nor skills—needed to promote the standard and be billable consultants and thought leaders at the same time. Until we have human cloning, this approach isn’t scalable.

The widespread adoption of DITA will require folks with a demonstrated track record of getting attention to help move these ideas into the mainstream. I have many ideas about how this might work, but the main stumbling block, as I see it, is our continued reliance on an outdated adoption model. If we expect the entire world to change and move toward XML, the very least we can do is to change right along with it.

I’m interested in what you think about this topic? Am I way off base, or right on target? What are your thoughts?

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • StumbleUpon
  • email
  • Facebook
  • TwitThis

Currently there are "19 comments" on this Article:

  1. David Sky says:

    An interesting, and important, idea. Does anyone have any examples of other technology that is doing this right? Even Firefox is way more consumer focused, so not a good example.

  2. Marcus Carr says:

    Sorry Scott, but I suspect the whole “promotion of DITA” is fatally flawed. If technology is good, it takes off – otherwise it doesn’t. DITA hasn’t, and my money is on it not lighting the information world on fire. Blogs and wikis are the model that we should be following – their success is undeniable.

    Standardizing the containers and building tools to work with DITA is all well and good, but at the end of the day SMEs are still required to know more about structure than they should have to. Unless the bar is driven down a lot lower, I believe that DITA will remain just another XML structure.

  3. David Farbey says:

    This is a very interesting idea but I don’t think it is going to happen. No-one wants to spend money on marketing something that doesn’t have the potential to bring them revenue.

    Moving to structured authoring is a culture change for writers and editors far more than a change in software tools. You have mentioned that yourself in many articles. To what extent can business cases and the cool stories affect attitudes in the doc department?

    By the way, I disagree with Marcus – I believe there is a place for structured documentation, alongside participatory content development methodologies like blogs and wikis. The two approaches are complementary, not interchangable.

  4. Marcus Carr says:

    David, I meant that it should be as simple to create structured documentation as it is to create data in blogs and wikis. Not only do I not consider the two to be interchangeable, I’d go further than to suggest that they are complementary – I think they should be one and the same.

    We need to develop ways of creating structured documents without requiring the authors to understand the schema. We’ve moved away from needing them to enter angle brackets, but for structured documents to flourish, we need to go much further. One way to do this would be to decouple the editing interface from the output schema and have a programming stage between the two. This would reduce DITA to an interchange structure though, which is all I believe it should be anyway. Obviously though, there’s not much point in trying to sex up an interchange structure. That’s one of the reasons that I think the whole effort is misdirected – it’s solving the wrong problem.

  5. David Farbey says:

    I’d like to continue this discussion with you directly, Marcus, as I am reselling a product that does make it really easy to create DITA topics. But then I think (form the URL you associated with your last comment) that you may also be involved with an XML based product.

    Please email me at david_AT_farbey_DOT_co_DOT_uk

  6. Larry Kunz says:

    Good points, Scott. In fact, I see a lot of parallels with our efforts to get out the word about the technical communication. profession

    I beg differ on one point, though. You say “The focus has to be on the human impact. How does DITA help make the world a better place?” I think the focus has to be on the BUSINESS impact. How does DITA improve the ROI for those who invest in it?

  7. Just to add a bit to the discussion Marcus and David were having, left to their own devices, most writers would write unstructured which leads to more stream of consciousness writing. Problem with that is that not all streams are alike. Without something to guide their structure, I believe that people would not be as concise. That’s one of the strengths that DITA brings and the real challenge facing DITA as it matures is how to embrace other, less-structured, writing environments effectively (as an input mechanism as well as an output mechanism).

    I agree with Larry and Scott. We need to be able to push the business case that makes DITA attractive in the long run (because it’s expensive in the short run) so those who would most benefit say to themselves, “This makes sense and will save us money eventually.” Volunteers just don’t have the bandwidth (or even the expertise) to market something like DITA effectively. We need excellent communicators who are also sales people (of which there are few in the technical communication community) to “sell” this product. Until there is a commercial push that is outside of the vendor products to make the standard a commonplace practice (and not just a sexy experience someone had); there may be a wall that impedes the further spread of DITA beyond the information architecture professionals.

    The only true way to avoid stagnation is to “sell” DITA and you do need to pay good sales people. They want, and deserve, a piece of the DITA pie.

  8. Marcus Carr says:

    Julio, left to their own devices, most writers would not write unstructured. No team of writers is going to embark on a documentation project without at least discussing how many levels of headings they’re going to use and generally how the documents will feel. We should distinguish between data that is explicitly structured (conforming to a schema) and implicitly structured (conforming to conventions but untested against a schema). “Unstructured” in this light would mean a random arrangement of information – not something that a technical author is likely to produce.

    Rather than dictating the structure, we should be informing users of inconsistently structured documents along the lines of “This is a warning – of the xx number of similar documents in this dataset, this structure has only been used y times”. (We use http://www.schematron.com for this.) Otherwise, the whole system relies on the structure being complete and stable before authoring begins, which has always proven problematic.

    Why are systems built on the assumption that the authoring interface should be tightly bound to the schema? Why shouldn’t the structure develop and emerge during the data creation process? Neither of these questions are unique to DITA, but may point to reasons why DITA and “XML authoring” generally isn’t as popular as one would have thought it would be.

    Rather than postulating about how to promote it, perhaps it would be more value to consider why DITA hasn’t lit the world on fire. Maybe it’s because it’s using essentially the same model that we’ve been seeing for decades in SGML and XML systems. Standardizing the outer structure makes life easier for programmers, but when are we going to start making it easier for authors?

  9. You bring up some excellent points, Marcus. Let me address the last point first. The reason DITA hasn’t lit the world on fire is because it’s still young (in terms of the industry as a whole – 6 years) and a lack of marketing. I do see a swell in adoption and that happens only when there’s a body of writers who actually get a good presentation on how to use the language effectively. While you may not believe it, once you really get into the paradigm DITA supports, the language is actually liberating rather than restrictive for a writer.

    One of the things DITA helps with is getting information in a format that actually aids readers. It sets a level of expectation that’s consistent throughout an information set that’s obvious. When I look at a task, I know what to expect. When I look at a reference topic, it’s got a certain look and feel. You can do the same thing arbitrarily but, in an extremely large writing team as would exist in a large company, it becomes difficult to enforce. DITA helps you achieve that consistency.

    Also, with specializations or good training, you can use the XML model to help gather information that can be massaged by your writers directly from programmers. The structure helps them at least get the information in a usable format for you. While that approach could lead to the danger of “why do we need tech writers?” I believe that it adds to the efficiency of the information development cycle when done correctly.

    Having said that, I will readily admit that DITA isn’t for all technical documentation teams because it could be fairly inefficient for small teams. However, for larger teams or those dealing with the government, the benefits DITA brings in terms of structure, reuse, and modularity are superb.

  10. Marcus Carr says:

    Julio, you and others have also raised some very good points and I’m exploring some of the links that have been provided to me about DITA. If you’ll indulge me to play devil’s advocate for a little while longer though…

    XML is older than DITA and it hasn’t caught on either – not in the “XML is the new ASCII” sense at least. I worked for many years in SGML before that and it was the same story – good idea, but poor reception.

    Yet there are niches where XML has huge numbers of users – take Wikipedia for example. Something like 2-5 million authors (depending on how you count them) versus the DITA user base of… dunno, but it’s not those kinds of numbers. So what’s the difference? Ease of use. Telling people how better to use DITA won’t make them use it, whereas getting them to use it without knowing it will. This is one reason why I don’t think marketing DITA will help.

    Another is that I’m not convinced that standardizing down to a certain point solves that many problems. Making topics portable and easily snapped together is useful, but you still need to make sure that content is what you think it is.

    An S1000D project here in Australia comes to mind – the DoD purchased 22 Tiger helicopters from Eurocopter. (http://en.wikipedia.org/wiki/Eurocopter_Tiger. Yes, the link to Wikipedia is intentional… grin As the data was S1000D, there was an expectation that “everything was going to be fine”. When the data arrived, there were two main problems – the first was that the data had been authored using three levels of depth in the modules whereas the DoD needed two, so the data was all going to have to be reworked. The second? A substantial portion of the data had been authored in French.

    Delivery of this dataset in properly structured S1000D meant nothing. Standardized containers weren’t really any use. The data was all cross-referenced and arguably accurate, but it was only of notional use. The changes to the module levels was going to break the cross references anyway, so despite their correctness at the time of delivery, they weren’t going to be much use in the long term…

    How can DITA overcome these sorts of issues? As soon as you start to customize your topics, you start to lose interoperability. As soon as you require a variation to a topic, you start to lose interoperability, and so on. For my mind, all of this occurs because the shape of the dataset is decided before you know what the data will actually look like – how it should look based on natural content, not on predetermined design.

    Maybe there are answers to all these things – I certainly don’t claim any expertise in DITA so I’m completely prepared to be proven wrong. On the other hand, I’ve been in this industry for nearly 20 years and DITA didn’t resonate with me from the start. Maybe it’s just me… but I think that marketing DITA is going to be a real uphill battle.

  11. Scott Abel says:

    For those of you who believe XML is not being adopted widely, you are obviously sheltered in your own little world and have little idea what’s going on outside your cubicle. Not only are XML standards like UBL being mandated by governments (Denmark, Spain, etc.) XBRL is being mandated by the US Securities and Exchange Commission. Those who don’t see the changes that are taking place are missing out on a big opportunity.

    Take a look at this video about XBRL to get a better understanding. It’s only a matter of time before DITA becomes a requirement, not an option.

    <object width=”425″ height=”344″></param><embed src=”http://www.youtube.com/v/5F1E-2LkhW8&hl=en” type=”application/x-shockwave-flash” width=”425″ height=”344″></embed></object>

  12. ScottAbel says:

    Here’s a link to the video as the embed code doesn’t work in the comments field.

    http://www.youtube.com/watch?v=5F1E-2LkhW8

  13. Marcus,

    You’re correct that ease of use is important and that is a driver that can’t be ignored, which is why there are so many vendors producing parsing editors. What’s more important, when talking about information, is consistency and predictability. Those factors, and the ability to reuse topics and elements is what makes DITA so strong. The other key to the benefits of the language is the fact that DITA can be specialized relatively easily. This allows any organization to develop a set of tags that makes sense to their authors and still inherit a base set of processing to go along with that specialization. You can also alter the output by overriding the base processing using XSLT. This sort of power is difficult to ignore.

    You’re correct that XML has been around longer than DITA but the vary arbitrary nature of XML is its weakness when it comes to developing and delivering information. It is difficult to predict how to handle the incoming information without having either a schema or examining the entire document. I suppose that’s why XML didn’t take off as an information development language, though it’s used as the basis of many programming standards and products.

    Sure wikis are easy to use and hide some of the language under the covers. The inherent problem is that it relies on the writer to follow some sort of structure on their own and doesn’t even describe an optimum structure. Guidelines are a help towards achieving structure but, especially at my age, you still rely on the human memory to enforce and enact those standards. DITA (or any other structure-based authoring language) removes human frailty from the equation.

    All that said, nothing replaces the writer from the equation. The old GIGO adage still holds true when it comes to content. You can provide any environment to make the structure and final presentation adhere to best practices or any standard you want but if you don’t have quality control in terms of the content you still lose.

    Your S1000D example is a prime indication of that sort of problem. However, I would expect that someone missed a translation step along the way before delivering the product to the customer and that was the actual failure, not the standard itself.

    I wouldn’t write a novel in DITA but that’s not the purpose of the language. The main thrust is help focus highly technical information into a consistent paradigm that enables both author and reader to set expectations and to help reduce costs through reuse.

    Hope this helps. :D

  14. Marcus Carr says:

    Scott, I’m missing the association between a six and a half minute commercial about XBRL and DITA becoming a requirement (of whom or what?). Perhaps I’m just not clever enough for DITA.

  15. Marcus Carr says:

    Julio, thanks for your comprehensive answer. It fits with much of what I’ve seen written about DITA elsewhere, so still leaves me with unanswered questions. There’s not much value in us debating the relative merits of DITA, so instead I’ll just point out the concepts that cause my reluctance to embrace DITA. If DITA is going to be successfully marketed, it’s people like me that will have to be convinced.

    Consistency and predictability vs specialization – these two concepts are surely at odds with each other, yet you offer them up two sentences apart, as though they were two sides of the same coin. They are in a sense – they’re diametrically opposed.

    Altering the output using XSLT – this is a characteristic of any XML document, so implying that it is somehow more powerful in DITA is simply not the case.

    Arbitrary nature of XML is its weakness – DITA only standardizes down to the topic, which can contain anything. The complexity is in the topic, not in the higher structure. Converting a “sect1 containing sect2 containing sect3” type of structure to topics is trivial – the difficulty is in what to do when sect3 contains a set of specialized elements.

    The only way to enforce structure is to dictate it – you can use forms and templates to suggest structure and Schematron to warn when it’s not being followed. This can produce structured data that is better written than it might have been with a guided syntax editor.

    DITA facilitates reuse better than other XML – as per the arbitrary nature point, the higher level structure is not the problem. Reuse depends on the *information* being applicable in two places, but the variability of the information is in no way influenced by the structure that it exists in.

    I have watched DITA from the start and have read plenty about it and asked plenty of questions, yet I still have these concerns. If DITA is to be marketed, I (and many others in their sheltered little worlds) will need quantitative answers as to how DITA is better. I’m not trying to be difficult, but I know this industry well enough to be cynical.

  16. Maybe I’m being unclear because of my familiarity with DITA. One thing that you should realize is that each topic type is highly structured and the contents of task, reference, and, to a lesser extent, topic are restricted by their DTDs. A generic topic has the fewest restrictions but, in general, I and others tend not to recommend this type except in specific cases.

    Specialization can restrict the types more or present a model that is more familiar to a user. This is not at odds with the architecture but gives an organization the ability to give their writers a more familiar structure than the base, so if, for example, they want to present the steps element of a task as a procedure element, they can. Specialization still embraces consistency and predictability just gives a different face to the language to the users.

    Whether using the base or a specialization, the XML parser is the final decision maker in your coding. If you place a section within a section (in the base language) you will get a parsing error and no output is produced. The model is strictly enforced. All the better editors enforce the structure by presenting only elements allowable at an insertion point. The fact that you can hand-edit the files later and create something that would be incorrect is irrelevant; nothing can protect against that sort of thing. The error is still caught before output and you pay the price then.

    I suggest that you use a free trial of one of the editors and play for a few weeks with the language. Maybe some of your questions may be resolved as it appears I’m not doing that great of a job addressing them. I know it works as I’ve been using it for years.

    I hope I’ve been of some help, Marcus but I haven’t done sales in a while and find myself quite rusty at providing the compelling benefit to the customer presentation I had learned (guess I’ll have to go back to some of my sales training books). I do know that I’m glad that I’m working in a relatively simple structured environment that helps me focus my writing. Now if I can only get this English thing down; I’d be awesome. LOL.

    Have a good weekend.

  17. Michael Priestley says:

    Hi Marcus,

    DITA separates topic-level content from higher-level containment. So in your S1000D example, with each section as a separate topic, the reusers could have achieved their goals by writing new DITA maps, without touching the content. This is a difference in reuse modularity between DITA and S1000D.

    You also mention that as people specialize they lose interoperability. While this is true to a degree, it is much less true of DITA than it is of predecessor architectures. Given a set of arbitrarily specialized DITA topics and arbitrarily (differently) specialized DITA processes, they should interoperate at the level of their common semantic denomenator without any special work. And complete integration should be possible simply by assembling new shell processors, with minimal new actual code.

    The three things that DITA does that are relatively unique to it are:

    - the insistence on the topic as a basic level of reuse, across any project

    - the ability to reuse and repurpose any topic from any document into new maps without editing or refactoring the original document

    - the ability to specialize new content types without breaking existing processes

    Each of these capabilities buys value on its own, but combined they enable sometimes astonishing levels of flexibility, usability, and reuse.

    I’ll also refer you to the DITA Maturity Model, if you haven’t seen it already – it grounds each of the major DITA features in the context of increasingly sophisticated adoption scenarios.

    http://dita.xml.org/wiki/the-dita-maturity-model

  18. Marcus Carr says:

    Thanks to all who commented, particularly Julio and Michael. I’m looking at the DITA Maturity Model and checking out a few other resources.

    Despite my apparent resistance to DITA, I don’t write it off. If it is to flourish though, it needs to be able to stand up to robust debate – if it doesn’t, no amount of marketing will save it.

  19. Marcus,

    Agreed. I hope that the debate made some sense to you and that, at least I, made an argument that at least piqued you to further investigation.

Comment on this Article:

Subscribe to the Newsletter

Get The Content Wrangler Newsletter delivered straight to your home or work Inbox. It's full of content goodness.

Sponsors

Magnus Opus
JFM Concepts VDP Web
Tech Comm Suite
E-Spirit
Scriptorium
Intelligent Content
Oxygen
Future Changes
Earley & Associates
TC World Magazine
Byte Level Research
Edit Me

Readers

Subscribe by or


Twitter

Posting tweet...

Powered by Twitter Tools