Re: [dita-adoption] who complains about complexity of DITA?

["Jang F.M. Graat" <jang@jang.nl>]

I fully agree with comments made by Mark and Anne. My experience is  
not in the world of business documents, but rather in small and medium- 
sized machinery businesses. People in that area do NOT want to go into  
XML at all, as it is scary stuff to them. What I am seeing is that the  
argument for DITA is not as difficult to get across as you would  
think. Basically, I am telling these customers that the documentation  
world has finally learned how to do things effectively by copying the  
approach they have been using in their engineering departments for  
decades, if not longer: they do NOT create copies of subassemblies  
that are to be incorporated into new machines. They know everything  
about conrefs, except the name for it. They practically live in a DITA  
world in their CAD designs all the time. But when it comes to the  
technical documentation, they completely forget about all this and  
start hacking away in MS Word.

I am not telling these customers to go for some kind of tool built on  
top of Word, just to please them and not rip them out of their comfort  
zone too much. I DO want to get them out of their comfort zone, but  
only if I can offer them a much better comfort zone to replace it.  
Nobody has ever complained to me that Word is such a wonderful tool  
that they cannot imagine anything better, so there is a real  
opportunity there, if only I can offer them something that obviously  
works for them. DITA methodology is wondeful, DITA tools are not at  
all geared to offer my kind of customers what they would dearly need.  
And of course, the number of elements in DITA is way off the target  
for easy acceptability by niche users. That is not a big problem given  
the new concept of constraints. As I have been telling people in my  
presentations: constraints will save DITA's life. But the tools have  
to become much more user-friendly. This includes tools to define  
constraints as well. So far, I have seen some very small steps in the  
right direction, but we're very far removed from what is needed in my  
business domain.

Kind regards from Amsterdam

Jang


On 8 dec 2010, at 23:36, Mark Poston wrote:

> From my perspective as a consultant speaking to customers about DITA  
> in non tech doc areas there is a common theme of not wanting to push  
> knowledge of XML onto users at all.
>
> It's easy for us to suggest that DITA will solve all sorts of  
> problems, but when it comes down to it, the practicalities of doing  
> so are always a lot more complex.
>
> A big challenge to start with is convincing an organisation that XML  
> is the way to go. Without the tools and infrastructure in place  
> there's always going to be a difficult road ahead. For wider  
> corporate use there are challenges from IT departments to accept  
> such changes unless they already fit into an existing IT system -  
> quite often based on Microsoft technologies.
>
> Tech docs teams have generally been a little easier to provide  
> solutions for as their requirements have previously fallen outside  
> of any corporate systems and are for only a smaller closed group of  
> users. This is becoming less the case now.
>
> Overcoming these challenge means that solutions need to be provided  
> that will address the different types of user's needs - considering  
> their user personas if you like.
>
> The work of the BusDocs sub committee is taking a step towards this,  
> and that is likely to introduce more types of content that meet  
> specific needs of different areas in the business. This is very  
> useful work but when it comes down to it, it still ends up being  
> about the tools that are used and the education that is required to  
> adopt them.
>
> For me, for DITA to become successful outside of tech pubs, the  
> focus needs to be on tool vendors taking away the need to know  
> anything about XML and using DITA as the hidden enabler of a content  
> architecture. This brings about the need for DITA-aware tools where  
> XML is never seen - of course there are some of these already (for  
> example Quark XML Author springs to mind).
>
> For many users, features such as conref, keyref, constraints,  
> reltables are too technical for them - these need to described in a  
> context that is appropriate to them and their particular use case,  
> or not described at all as it doesn't actually matter. As a vendor,  
> architect or system integrator they are, again, the enabler - just  
> like a programming language is an enabler to providing a software  
> solution to a customer.
>
> These user friendly descriptions are what the DITA Adoption  
> committee can help with, along with their work on defining benefits  
> of DITA for different audiences.
>
> My concern is that as DITA grows, and it will only continue to grow,  
> it becomes such a complex standard that it will gain a reputation as  
> being as such and perceived as an expensive thing to implement. This  
> is, of course, completely the opposite to the original reason for  
> recommending DITA as an option to tech pubs team, as vendors were  
> able to quickly support and therefore provide a more cost effective  
> solution with, quite often, easily identifiable return on investment.
>
> As the DITA standard grows so to are the requirements for vendors to  
> support it, making XML authoring tools and other systems do more  
> than they were originally intended to do. I am not a tool vendor but  
> I can imagine that implementing the new con ref and key ref features  
> (for example) aren't that straight forward. I just hope that there  
> is still the interoperability between tools now that DITA is not  
> just about parsing XML but also has requires a complex application  
> layer on top of it to implement its features.
>
> Personally, I would like to see an open source DITA interop  
> framework that allows tool vendors to use a common library that  
> implements features in the standard. This can then be integrated  
> into tools in a consistent manner. As the standard grows, this  
> framework would provide the processing logic for DITA's features.  
> It's partly there in the DITA Open Toolkit already ... Which is  
> developed hand in hand with the standard itself.
>
> A long-winded response but I hope provides some useful discussion  
> points.
>
> Kind regards
>
> Mark Poston
> Mekon Ltd.
>
> Sent from my iPad
>
> On 6 Dec 2010, at 15:59, "Bruce Nevin (bnevin)" <bnevin@cisco.com>  
> wrote:
>
>> Are we entirely clear about the use contexts in which users find  
>> the number of elements onerous or confusing? Obviously, the  
>> authoring environment is one.  But do architects also object? Do  
>> the tools vendors object? This seems less likely to me, but it's  
>> not something to guess, we should find out. And is that (the number  
>> of elements) the only complexity that they object to?
>>
>> The constraints mechanism can neatly address the perceived  
>> complexity in the authoring environment. (Be it noted that existing  
>> mechanisms provided by [some?] authoring tools to hide elements  
>> from authors apparently do not reduce these complaints, maybe  
>> because the complaints come from users who don't make use of them.)  
>> But creating and managing constraints is another layer for  
>> architects and designers to deal with.
>>
>>     /Bruce
>>
>