Really interesting discussion so far with many insightful comments from the trenches.
Michael's comment, "DITA can be complex, if you need complexity. It can also be simple, if you need simplicity" is true, however the issue seems to be that the *default* state of DITA is complex. In practice there is a world of difference between "DITA has 100 elements and you can add up to 100 more via optional packages." and "DITA has 200 elements and you can hide up to 100 of them by configuration."
As a general statement about technology, users overwhelmingly stick with defaults, much more than developers usually think and in spite of what experts recommend. Here is one example: http://www.ingentaconnect.com/content/routledg/rics/2008/00000011/00000001/art00003 . There are a few reasons people tend to stick with defaults:
- Choosing what to change means reading a big pile of stuff
- Afraid that if they turn something off, turning it back on will be a huge hassle or impossible
- Not easy to get budget approval for taking features out of a product and putting them back in later
- Too busy with other critical tasks in getting the project off the ground
- Nobody ever got fired for sticking with defaults in software
In addition to the tendency of users to stick with defaults, I think another thing going on is unit bias (http://sciencethatmatters.com/archives/35). Many, although not all, vendors like to be able to say that they "fully support" something without a bunch of footnotes describing the 17% that isn't supported.
BTW, so far we've been focusing on the perceived complexity of the standard itself, but I'd guess that a lot of the complaints about "DITA" being complex refer to issues with tools, and particularly with customizing output. There isn't really anything we as OASIS committees can do about tool issues, but it's worth keeping in mind that people aren't always talking about the standard when they talk about DITA's complexity.
JustSystems Canada, Inc.
Office: 1 (778) 327-6356
XMetaL Community Forums: http://forums.xmetal.com
For partners only: http://www.justpartnercenter.com
From: Michael Priestley [mailto:firstname.lastname@example.org]
Sent: Tuesday, December 07, 2010 5:50 AM
To: Dick Hamilton
Cc: email@example.com; firstname.lastname@example.org
Subject: [dita-adoption] Re: [dita] who complains about complexity of DITA?
>The "DocBook is dead" undercurrent in this thread surprises me.
I hadn't noticed that undercurrent, and don't think it's relevant to the discussion in any case. Getting
But I do think that just saying "DITA is complex" is a complete mistake. DITA can be complex, if you need complexity. It can also be simple, if you need simplicity. There are plenty of case studies from both ends of the spectrum. Boosters of DITA tend to focus on the simplicity of the simple cases and the value of the complex cases, and detractors of DITA do the reverse. Both are misleading.
A big driver for the creation of the DITA maturity model was to bring some clarity to the discussion. At level 2 of the model, you're using just topics and maps, and only prepackaged specializations (if any). Many organizations adopt at that level and are quite happy with their ROI. You get the potential for substantial additional returns from higher up the model, along with increased cost - although over time, there is a trickledown effect, as specializations created by organizations at level 3 or higher are tested and contributed back to the community, allowing groups at level 2 to capitalize on that investment.
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
Dick Hamilton <email@example.com>
12/07/2010 02:22 AM
Re: [dita] who complains about complexity of DITA?
The "DocBook is dead" undercurrent in this thread surprises me. DocBook is still alive and well in many applications, esp., open source.
Even with more elements (though if you include L&T, DITA 1.2 is bigger than DocBook 5.0:-), I'd argue that DocBook is much simpler for writers and will be until practitioners learn how to use the complex features of DITA to create simple applications that support the work that writers need to do.
(By "application" I mean a combination of specialization, features like keyref, content strategy, and writer training to create a custom solution that addresses a particular business need.)
I wonder if the correct "marketing" approach is to acknowledge that DITA is complex, but emphasize that when properly used, that complexity makes it possible for tools developers to create applications that are simpler and more capable for their target audience.
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: