Excellent video clip, Don.
I’d REALLY encourage everyone to take 4 minutes and watch it:
Kristen James Eberlein l DITA Architect and Technical Specialist l SDL Structured Content Technologies Division l (t) + 1 (919) 682-2290 l firstname.lastname@example.org
Please consider the environment before printing this e-mail
From: Don Day (LbW) [mailto:email@example.com]
Sent: Tuesday, December 07, 2010 11:06 PM
Subject: Re: [dita] RE: [dita-adoption] Re: [dita] who complains about complexity of DITA?
Complexity can be reducible, according to this 18-minute TED talk done in just under 4 minutes:
From that example, I'm actually encouraged that DITA constraints operates exactly the same way he demonstrates about the removal of non-essential detail from an otherwise complicated network.
The problem is how to undo the perceptions that exist on the basis of discoverable facts (the "Full Monty DITA" perception) and focus instead on the possibilities ("South Beach DITA" or "Low Carb DITA"). Such visualizations and worked examples might be extremely helpful in that regard, particularly if we could engage with popular social media mavens whose tweets tend to have the same "de facto authority" as defaults in software.
Doug Gorman's name for "Simply DITA" is, after all, a clever wordplay along the same lines.
On 12/7/2010 7:10 PM, Su-Laine Yeo wrote:
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
>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
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: