This is an appeal to the DITA community: the experts and the evangelists, and possibly the tools vendors as well.
We’ve done a good job selling DITA: after years of slow growth it’s gaining momentum. As it does so, paradoxically, I’m hearing more and more anti-DITA rhetoric. While some of the rhetoric reflects a lack of understanding or even a hidden agenda, some is worth listening to.
I’m thinking of two things in particular that the DITA community often touts as selling points: authors no longer have to worry about formatting, and their DITA content can readily be used for adaptive content — output customized for the audience.
As good as those sound, I don’t see content authors raving about them. We need to understand why that is, and find a way to address it.
Leave the formatting to us
I’ve proudly touted this in every DITA class I’ve taught: Freed from having to worry about fonts, indentations, and other formatting issues, authors at long last can concentrate on content.
Except that a lot of authors like to worry about formatting. Oh, they’re grateful to be rid of weirdly indented paragraphs and things like that. But they want to tweak table formats and insert page breaks so that their content is perfect for a particular output type (usually PDF).
You can’t blame the authors for wanting their content to be good. Perhaps our tools fall short by not making the content as good as it should be.
Table formatting probably isn’t a big problem. By and large, it can be managed through the XML transform. But page breaks are a special case.
Usually when an author wants to insert a page break it’s because the XML transform has placed a page break where it shouldn’t be. So it’s not about inserting desirable page breaks; it’s about avoiding undesirable ones. The solution? How about smarter XSL transforms?
The default DITA Open Toolkit already knows not to separate a title or a heading from the first line of following text. I think it also knows to avoid widows and orphans. Would it be feasible to build in additional checks, like not breaking up short tables and not separating a figure from the preceding text?
If it’s not feasible to update the DITA-OT, then perhaps someone in the community can provide some sample XSLT code to handle common formatting issues. I’m thinking of something akin to the excellent examples in Leigh White’s DITA for Print. If the XSL transforms can be made smarter in this way, a lot of authors will no longer feel the itch to tweak their formatting. And they’ll be more inclined to embrace DITA.
The other big selling point for DITA is the ability to adapt DITA content to particular audiences in particular contexts. It sounds great. Except that practically no one is using DITA in that way.
Why not? Metadata is the key to making adaptive content work, and most of the authors I know simply aren’t comfortable working with metadata. Even when an information architect develops a great taxonomy to support a solid content strategy, metadata still eludes many writers. Perhaps it’s counter-intuitive to create content and also tag it according to a taxonomy.
How can we make metadata easier for authors, so they’ll be comfortable using it effectively?
DITA already has a simple way of including metadata in topics and maps. The element is flexible enough to support any and all taxonomies. But it requires the authors to do too much by hand.
Some higher-end content-management systems (CMSs) have become good at managing metadata. But that’s at the CMS level, an environment where authors might be less comfortable working. Can we do anything to make metadata more intuitive, and less manual, at the topic and map level?
What if editing tools, as part of their file-create dialog, included checkboxes with which authors could assign metadata based on the local taxonomy? The result would be a pre-populated element that could be modified later, if necessary, in the normal way.
What other ideas might help authors become more comfortable with metadata and taxonomies?
A glass half full
Unlike my colleague Mark Baker, I see DITA as a glass half full, not half empty. When Mark asks “Why does XML suck?” I paraphrase Churchill and say that XML is the worst way to develop content — except for all of the others. If XML sucks as a way of communicating information and telling stories, then so did cave drawings, papyrus scrolls, typewriters, and word processors. All of them had strengths and weaknesses; all of them enabled savvy communicators to reach their audiences.
Yet for all its potential, DITA still has hurdles to overcome in terms of being accepted by the majority of content authors. What about it, DITA community?
Do you agree that we need to help build authors’ trust in DITA’s ability to format their content? That we need to help them become more comfortable with using metadata?
What should the community do to address these issues? What is the community already doing, that I haven’t mentioned?
Are there other hurdles to overcome besides the two I’ve mentioned?
I’d love to hear what you think in the comments section.