I was reading JoAnn Hackos article on easy DITA authoring solutions and it got me thinking about what the word “easy” means in regard to DITA or any similarly complex technology.
Can an editing interface make DITA easy? Some DITA consultants that I know complain bitterly about tools that make that claim. DITA may be many things, they say, but easy is not one of them. To present it as being easy is only going to set people up for disappointment and failure.
If they are right, can any DITA editor legitimately claim to be “easy”?
Two kinds of easy
I think they can, but we need to make a distinction between two different kinds of easy: conceptually easy, and operationally easy. Conceptually easy means the task you are asking someone to do is easy to understand. They know exactly what you are asking them to do, and they can tell at once when they have successfully completed the task. Climbing Everest is conceptually easy. It is operationally hard.
Operationally hard means that the steps you have to take to complete a task are difficult or cumbersome to perform, no matter how well you understand them. Writing XML by hand is operationally hard. Even if you understand exactly what you are supposed to be doing, your chances of getting it right the first time without the assistance of a schema-aware editor are slight.
Some tasks are both conceptually hard and operationally hard. Computer programming is one of these. It is operationally difficult to write code that compiles. It is conceptually difficult to create a robust and efficient computing architecture. Many programmers are proficient at the former and deficient at the latter.
If a task is conceptually hard, you will have a very hard time getting people to complete it successfully on a part time basis. They won’t understand what is being asked of them and they won’t know when they have completed the task successfully. Making the task operationally easy won’t shift the needle very much in terms of effective participation.
Structured writing: two kinds of hard
Classic technical communication — before writers got tangled in publishing issues — was conceptually difficult but operationally easy: you just typed up your manuscript and handed it to a typesetter. Traditional publishing, on the other hand, is conceptually simple, but operationally complex.
Desktop publishing combined classic tech comm and traditional publishing to create a task that was both conceptually hard and operationally hard. This led to many tech comm candidates being hired more on their operational skills than their conceptual knowledge. (It seems to be the pattern that when something is both conceptually hard and operationally hard, operational competence will be preferred in hiring. Perverse, perhaps, but operational competence and its outcomes are easier to measure and we tend to manage for the properties that are easiest to measure.)
Structured writing has, by and large, continued this pattern of being both conceptually hard and operationally hard. In fact, for tech writers it has created the situation where they are expected to do a conceptually hard job (technical communication) using a conceptually hard system (DITA) that is also operationally hard to use.
It is no wonder that many are turning to wiki platforms instead, which are both conceptually and operationally easy. (But don’t confuse operationally easy with operationally efficient.)
No editor, by itself, is going to make DITA (or technical communication) conceptually easy. But given the amount of difficulties authors face, making it more operationally easy is very much worth while.
Making structured writing easier
Is there anything we could do to make structured writing conceptually (and operationally) easier for technical writers? Yes. The thing that makes things conceptually difficult is abstraction. The concrete is easy; the abstract is hard. If we can make a task more concrete, we can make it conceptually easier. (And often operationally easier as well.)
Desktop publishing is highly concrete. The appearance of text on a page, the way lines break over pages, the way table cells align, are all highly concrete things. That is what makes desktop publishing conceptually easy, even if it is often operationally hard.
Most contemporary approaches to structured content are quite abstract. DITA, in particular, relies on a number of abstractions with which the writer has to grapple, and contains a significant amount of imperative markup (effectively, instructions to the processor) which means the writer is effectively coding as they write. This can enable some powerful effects, but it is conceptually very difficult.
It we returned to concrete formatting as our standard, we would restore conceptual ease, but we would lose structured writing and all of its potential benefits in terms of quality and efficiency.
But there is another option: we can create markup that is semantically concrete. Semantically concrete markup — which I usually refer to as declarative markup — simply declares what a piece of content is about: what things in the real world it is describing or referring to. This, it turns out, is enough to power most of the publishing, reuse, and information exchange goals we have for structured content, and to achieve some that have previously been out of reach.
Creating concrete semantics makes the structured writing task concrete, and therefore conceptually easier. Combine this with the capacity of structured editors to make structured writing operationally easier, and you have an approach to structured writing that can be extended much more widely across the organization.
EDITED (Webinar date changed): I’ll be examining how to do this in my webinar Structure and Collaboration with Scott Abel on December 12, 2014. The webinar is sponsored by Oxygen XML (disclosure: Oxygen is both a partner and a client of Analecta Communications). I’ll be talking about how to make structured writing both conceptually and operationally easier for collaborators, and showing how Oxygen’s forms-based authoring feature can make structured writing operationally easier. Sign up now.