I spoke at the Congility (=”content agility”) conference, earlier in the week. It was a well run and interesting conference.
Here are my post-conference reflections.
Content strategy from two perspectives
Congility had a good mix of content strategy speakers from both the technical communications and the marketing fields. Paraphrasing Rick Yagodich’s presentation, the technical communicators can be criticised for building systems that create dull content efficiently, and the marketers can be criticised for creating great content inefficiently. So it’s good to learn from the two different perspectives.
I was talking to Tony Self about this “dull content produced efficiently” issue at the conference, and he argued that there have always been limitations. The manuals he worked on in 1979 as a trainee technical writer were printed in black and white, because that was more efficient and less expensive than colour. It’s also true that magazine adverts used to be in black and white, and use illustrations instead of colour photographs, due to time, technology and cost constraints.
Ideally, organisations will build a system that works for both sets of requirements, or at least offers interoperability between the marketing and techcomms content systems. As marketing content becomes more structured, we might find technical communicators working within a content system that’s been implemented by the Marketing department.
In my talk, I mentioned the growing importance of technical, enabling content in the process that turns prospects into customers. Research by Google found people read an average of 10.4 pieces of information before they decide to buy a product. This raises the importance of technical content in the role of marketing a product, and it might even mean techcomms will become part of the Marketing department.
Peering into the future
Some speakers took a look into the future for content. Google Glass and Augmented Reality were mentioned quite a few times, as was the Internet of Things and the increased use of video within the field of User Assistance. What’s unclear is who will creating this type of content – whether it will be technical communicators, programmers or a new type of professional.
Case studies
There were a number of very interesting case study presentations. It did seem that the decision to implement a structured authoring system was often driven by a publishing system that had fallen into chaos, or was becoming so complex (thanks to demands to translate content) that there was a danger of it falling into chaos. They’d built systems that could manage all the complexity of today, be ready for the challenges they may face in the future.
The value of content
I asked the audience in my presentation if any of them knew how many users/customers/prospects had read their content last week. Only one person put up their hand. Technical communicators still seem to measure their productivity and efficiency more than the value of their work.
Minimalism and reductionism
Quite a few speakers talked about reducing the number of words in text to the absolute minimum, as this would make localization and comprehension easier. If no-one measures the value of their output, how do do they know? No one seemed to question this or outline how to integrate user forums (and user generated text and videos) into their content strategy or systems.
Where you there? What are your reflections?
Please share your thoughts using the comments box below.
Hallo Ellis
Thanks so much for summarising the conference so nicely. This post is a great resource for those of us who couldn’t attend Congility.
The point about “dull content produced efficiently” is interesting. The conversation with Tony Self seems to have focused on the presentation side of things. But “dull” could also refer to the quality of the content itself. Our style is usually optimised for simplicity and consistency, which may be perceived as dullness.
Looking at the presentation side of things, the systems we use are interesting. Some of them, like wikis and CMSes, handle both the authoring and the presentation side of things. Many of those are moving towards a more attractive and engaging presentation, and offer integration with the more exciting web technologies that also help to attract readers and appear less “dull”.
Other technical authoring technologies, such as DITA, leave the choice of publication platform open. In other words, we are free to choose a less “dull” presentation here too.
So, is the accusation of “dullness” perhaps aimed squarely at the nature of the content rather than the presentation? 🙂
Cheers
Sarah
Thanks Sarah. One of the primary criticisms of Dita is the publishing capabilities – so presenting it in the way you can present content in a Web CMS is an issue.
I disagree with the characterisation that DITA is “dull content produced efficiently” on a number of levels.
Firstly, the separation of content and form approach doesn’t result in any “duller” content. The content is just separated from the presentation layer. That suggests that “dullness” has to do with the presentation, not with the content.
The main difference with DITA (and other separated approaches) is that formatting is automatic, not manual. This does indeed lead to less visually rich delivered documents, but the degree of “less richness” is debatable.
Most printed manuals have pretty boring presentation… or putting it more kindly, aesthetically limited. You know, A4, black text on white, standard columns, squares and rectangles, Arabic page numbers, consistent text size, single typeface, etc. Compare that to a brochure for a hip new clothes store. Or to a yachting enthusiast magazine. Those types of publications employ designers to make the product look good.
Technical publications teams rarely employ designers, because we just don’t have the budget. Our budget should be spent on making the content itself less dull, and making the presentation layer more efficient by automating it. This automation may actually allow for design to be introduced (if we subcontract a templating job to a designer), and potentially make our finished documents less dull.
Thanks Tony.
Implicit in Dita are the principles of minimalism, and there is a danger that writers can take the reduction of words to the extreme (mistaking minimalism for some form of extreme reductionism). Words that might be seen as superfluous can still have value by engaging the reader – making an affective connection. When you look at the changes made to the Mozilla Help, where they actually carried our A/B split testing to measure the value of the content, they found these extra words in the introductory pages resulted in a 13% improvement in the number of people reading the Help (rather than calling Support).
This isn’t unique to Dita. Many people are writing content, confident they are creating great content, without doing any testing or measurement of the value of their work.
I agree that the presentation layer should be automated, and that it should be separate from the content.
Can you point us towards any examples of Dita generated content that is presented in a way that compares with say WordPress or Drupal generated content?
Although you’ve moved the goal posts a bit, asking for DITA-sourced output that looks like WordPress or Drupal (when very little technical communication is managed on these platforms), here’s a site which is (so I’m told) dynamically transformed into HTML from DITA source.
http://www.hr.uottawa.ca/my-info/choose?
Mekon’s DITAweb framework, as demonstrated at Content Agility, is another example.
https://ditaweb.com/demo/
Thanks. The Mekon site looks like Yet Another Help File, although I suspect you could make it look more like a contemporary website design. The University of Ottawa site looks really good.
I notice Rahel Bailie has blogged on Dita for the Web, and what it might look like.
I did ask Joe Gollner last year his thoughts on the “DITA publishing is weak” claim, and his response was “harsh, but fair”.
The criticism lies not so much with DITA itself, but with the assumptions of the information model that lies underneath it and the current technology for publishing the content. There’s also the difficulty of getting novice writers to write in a structured way (an issue for lots of systems).
DITAweb is a framework, rather than a product, so when you implement it as the basis of your information delvery system, you choose what widgets it uses, where they are positioned, and how you would like the content to look. Which is pretty much the Drupal/WordPress model. The difference is that the content is created in a more systematic and efficient manner (structure, metadata, translatability, reuse, version control, filtering, etc).
I agree with Joe Gollner’s admission that DITA publishing is weak, but the reason for that is not any structural or methodological weakness in DITA. The reason is that “we” haven’t yet got our heads around how DITA can enable us to publish in entirely different ways. Our approach to DITA has generally been to replace HTML/RTF/FM file formats with DITA at the back end, and just tinker with the processing workflows and delivery models. For example, most DITA source gets output with a TOC. Why aren’t we using facets instead…. DITA makes this as easy to implement as a TOC. DITA allows us to generate diagrams from textual source… but who’s doing that? Instead, we’re using diagrams the same way we used them in WordPerfect. “We” (and I’m using a broad-brush “we” to mean the technical communication community) are a little bit limited at the moment because the publishing tools haven’t caught up with the publishing potential.
I think the idea that the DITA information model prevents “non-dull” content is a bit of a Furphy. Likewise, that getting novice writers to write with structure is difficult. The base concept information type in DITA is made up of paragraphs and lists in a very loose structure, just like a WordPress topic. Agreed, there is no indenting or font choices, but that’s vital to the separation of content and form. The task information type is a different kettle of fish, with a very strict structure. But that’s intended for procedures, which are going to always be “dull”. Even the most novice of writers can fill in an online form more easily than creating a document in Word. If we’re talking about novice technical writers, then they need to be trained in semantic markup and structured authoring, in the same way that they currently need to be trained in what a style guide is and how to use styles in FrameMaker.
Did you mean creates, rather than prevents?
(Furphy = Australian slang for a rumour, or an erroneous or improbable story)
Ah, I think there might be a few double-negatives in that sentence. Maybe even a quadruple-negative. A Furphy is a false rumour, so I was trying to say that the idea that DITA stops you creating interesting content is erroneous.
Hi, Ellis, This fascinates me:”Words that might be seen as superfluous can still have value by engaging the reader – making an affective connection. When you look at the changes made to the Mozilla Help, where they actually carried our A/B split testing to measure the value of the content, they found these extra words in the introductory pages resulted in a 13% improvement in the number of people reading the Help (rather than calling Support” Where can I read more? Are these words perhaps endearments? Does “love” trump “Mi duck?”
Hi Patrick.
We cover some of this in our whitepaper “the changing nature of content”, which you’ll find on the Adobe TCS site https://www.adobe.com/cfusion/entitlement/index.cfm?e=tcs_whitepaper. These links may also interest you:
http://justwriteclick.com/2010/08/10/writing-engaging-technical-documentation/
http://sumo.graymattergravy.com/slides/betterfm/
Plus there’s our advanced training course, where we spend a day on these types of techniques.