Do you need DITA?

Judging by Social Media last week, there were many strong opinions at the tekom tcworld conference towards the DITA authoring standard and the associated tools. It seemed, as the philosopher Swift once said, “Haters gonna hate”, and, by inference, “Hypers gonna hype”.

Eliot Kimber provided an interesting summary in a post to the DITA users group forum (Trip Report: Tekom 2015, DITA vs Walled Garden CCMS Systems):

“For background, Germany has had several SGML- and XML-based component content management system products available since the mid 90’s, of which Schema is probably the best known. These systems use their own XML models and are highly optimized for the needs of the German machinery industry…These products are widely deployed in Germany and other European countries. DITA poses a problem for these products to the degree that they are not  able to directly support DITA markup internally, for whatever reason, e.g., having been architected around a specific XML model such that supporting other models is difficult. So there is a clear and understandable tension between the vendors and happy users of these products and the adoption of DITA…
…It’s clear to me that DITA is gaining traction in Europe and, slowly, in Germany but that the DITA CCMS vendors will need to step up their game if they want to compete head-to-head against entrenched systems like Schema and Acolada. Likewise, the DITA community needs to do a better job of educating both tools vendors and potential DITA users if we expect them to be both accepting of DITA and successful in their attempts to implement and use it.”

This may have led those who are asking, do I need DITA?, to come away from the conference more confused than before. So, we thought it might be useful to provide a rough guide to whether it’s worth adopting DITA:

You probably don’t need DITA if:

  • The way the content looks to the user is the most important issue.
  • You have fewer than four writers.
  • You write narrative content.
  • You have limited budgets for tools, training and migration.
  • You don’t have the time to deal with the issues around changing working methods.
  • Your content has a “shelf life” of less than two years.
  • You use a lot of graphics with annotations.
  • You need to customise outputs [added] for individual documents [added] (such as PDFs).
  • The cost of migrating existing content will be expensive.
  • You want the presentation layer embedded with the content layer.
  • You don’t want to work within strict rules regarding how topics are written (where content is marked up semantically).
  • You need to put JavaScript code directly inside topics.
  • You need to use the tools used by developers or the marketing department.
  • You want a simple information architecture.

You might need DITA if:

  • You need to write to (and enforce) a standard.
  • You need to localise content into many languages.
  • You have more than four writers.
  • You want to write semantically.
  • You need a more efficient authoring, [added] reviewing [added] and publishing process.
  • You create many variations of the same document.
  • You want intelligent content that can adapt to different users and contexts.
  • You are spending too much time on formatting content.
  • You need to re-use content in different projects and different contexts, and make those topics accessible to other writing teams who might want to re-use them.
  • You need to establish a controlled vocabulary and taxonomy.
  • You want content validated for consistency.
  • You want automated publishing.

You probably do need DITA if:

  • You need to share content with other organisations.
  • Your content will need to last more than 30 years.
  • You want content to be stored in an open data standard, independent of any tool.
  • You don’t want to be tied into a specific authoring tool, content management system or publishing/rendering engine.
  • You need transclusion (where an element can replace itself with the content of a like element elsewhere) across a range of media.
  • You want to have a way of generalising back to a common standard.


Do you agree?

Please share your thoughts below.

Mankind – overcomplicating products for 1.8 million years

Olduvai stone chopping tool

In the radio series, A History of the World in 100 Objects, Neil MacGregor, Director of the British Museum, described the oldest man-made object in the museum – the Olduvai stone chopping tool. This was made approximately 1.8 million years ago in Tanzania, where the first humans originated.

MacGregor explained the tool has more than six chippings that sharpened this rock into a tool, when it only need two. He said:

“Those chips tell us that right from the beginning, we, unlike other animals, have wanted to make things more complicated than they need to be.”

Complexity, it appears, has been part of product design and manufacture right from the beginning. Did the need for user instructions follow shortly afterwards?

A technical communication user’s hierarchy of needs

At the TCUK 2015 conference, Rachel Johnston mentioned the idea of a content maturity model. We thought we’d take this idea and ask:

Could we develop a model that illustrates a hierarchy of needs for users of technical communication (and in particular, User Assistance)?

A model of what?

We suggest calling this model a technical communication user’s hierarchy of needs. This is because we’re considering the different points where a user interacts with technical communication content, the information they need, and value it gives to them.

It takes a similar approach to the content maturity model Rachel suggested (shown in the photo below), with the least mature organisations providing just the legal minimum, and most mature content systems contributing to branding and evangelism.

content maturity model diagram

A user’s hierarchy of needs also enables us to compare this model to similar models from content marketing and product design. For example, the categories in our model’s hierarchy roughly correspond to Peter Morville’s “User Experience honeycomb”, as well as the key elements in product design.

Continue reading

Reflections on the TCUK15 conference

I was one of the presenters at last week’s Technical Communication UK 2015 (TCUK) conference. TCUK is the Institute of Scientific and Technical Communicators’ (ISTC’s) annual conference for everyone involved in writing, editing, illustrating, delivering and publishing technical information. It’s an opportunity for Technical Communicators from the UK and mainland Europe to meet up and mingle, learn and present.

auditorium at tcuk 15 conference

Here are my reflections on the event.

Continue reading

The ContentHug interviews

I was asked to take part in the ContentHug series of interviews on technical communication and content strategy.

It was fun and challenging, going through the questions.

ContentHug’s Vinish Garg is interviewing a number of consultants involved in technical communication and content strategy, and asking them essentially the same questions. By reading the interviews, you can see where there are areas of agreement and where there are a variety of opinions. In general, there is a fair bit of consensus. They are worth reading.

Creating palaces of almost forgotten things

Museum of almost forgotten things brochure

This weekend, we went to the Fabularium on London’s South Bank, where the programme highlighted The Museum of Almost Forgotten Things. It struck me that this concept could also be applied to technical communication. The impetus to write things down, to document policies and procedures and to write user documentation for software written in a Sprint, is often due to organisations worrying that important information might be soon forgotten. Technical Authors often capture and record almost forgotten things. They might, however, object to the word “museum”, because they are working with how things are today much more than how things were in the past. So perhaps “palace” could be an alternative word to use.

Ben Haggerty, the storyteller whom we saw perform, started by trying to discover who we, the audience, were. He quoted a west African saying that there are four types of people in the world:

Those that know and know that they know. These are called teachers, and should be respected.

Those that know, but don’t know that they know. These people are asleep.

Those that don’t know, and know they don’t know. These people are students.

Those that don’t know, but don’t know they don’t know. And there are 630 of them sitting in the House of Commons on the other side of the Thames.

It’s interesting to see how close this old African saying is to competency models used in training today: unconscious incompetence, conscious incompetence, conscious competence and unconscious competence.

Common sense isn’t always common

Here’s some examples from Munich of what might seem to obvious and common sense to the one audience, but not to others.

Traffic lights that have four lights, with the symbols , O, I and K:

Munich traffic lights

Pedestrian crossing lights that have two people instead of one:

Munich traffic lights

The second set of lights is still comprehendible (hold the hand of the person next to you, whilst you’re waiting to cross the road 😉 ), but the first set didn’t make sense to even the (non-Bavarian) German members of our party.

The decline of the gerund in technical documentation?

Louise Downe, who works at the UK’s Government Digital Service, wrote a blog post (Good services are verbs, bad services are nouns), where she stated:

“After several rounds of user testing, the Home Office changed the name of ‘Immigration Health Surcharge’ to ‘check if you need to pay towards your health care in the UK’ – a service that allows visitors to the UK to pay for the cost of healthcare.”

Screenshot of Home office page, where  Heading uses "create"

Continue reading