I had a twitter exchange a while back that got me thinking about DITA, structured writing, and the impact of tools on the perception of technical communicators. The basic question was whether structured writing in general and DITA specifically are “dumbing down” technical communication, leading to a devaluation of the field.
I end up straddling the fence here. The short answer is “no, I don’t think DITA is dumbing down technical communication.” However, introduction of technologies like DITA, if not handled well, could lead to a devaluation of the field. The danger I see is that if managers misunderstand DITA and modular technology, they may conclude that DITA will allow them to hire less-experienced, less-skilled, and less-expensive writers, which could lead to a de facto dumbing down (or a train wreck, depending on your point of view).
| Tweets |
| BkwdGreenComet: @richardhamilton (1) Writers of DITA-based documents are filling in forms. Doc arch and org is already “solved.” |
| BkwdGreenComet: @richardhamilton (2) Web output from DITA will predominate, thus formatting options are limited vs traditional book output. |
| BkwdGreenComet: @richardhamilton (3) Prose for transitions and topic “context” is expunged to encourage content reuse. |
| BkwdGreenComet: @richardhamilton (4) TCer no longer need be expert on a complete sw product, only a piece. -> fragmentation of knowledge |
| BkwdGreenComet: @richardhamilton (5) Parts of sw product doc that gets most rewrite attention (the UI) requires least techn expertise. |
The sidebar contains a set of tweets from Paul Sholar, better known on twitter as @BkwdGreenComet. Paul, who was kind enough to let me quote his tweets, is a thoughtful and careful commentator, so I take his thoughts seriously. He gives five reasons he sees DITA, and by implication structured writing, dumbing-down technical communication. My tweets, which in any case are not nearly as thoughtful as his, are lost in the twitter-verse because I waited too long to retrieve them, but I’ll do my best to recreate my thoughts here.
Overall, I agree with most of Paul’s specific comments, with a caveat. I think some of them work primarily as a statement of “what managers think.” Of course, since “what managers think” often leads to “how managers act,” his points are worth taking seriously. Let’s take a look at them one by one:
(1) Writers of DITA-based documents are filling in forms. Doc arch and org is already “solved.”
If you are “just the writer,” then you may end up in a job where it seems like you are just filling in forms, but someone still has to create a documentation architecture and organization, even if you are working in the DITA world. If you avoid being involved with the doc architecture, then you may get slotted into a position where you seem to be just filling in forms, but even the form filler needs to understand the information he or she is placing in the form.
(2) Web output from DITA will predominate, thus formatting options are limited vs traditional book output.
I agree that web output will predominate, along with help systems, but I don’t think print, or print analogs like PDFs, will disappear. Also, you can make a pretty good argument that web output has at least as wide a range of formatting options as print, even though those options don’t overlap 100%.
What really limits formatting options is that modular writing separates formatting from content, and often takes away the formatting job from the writers. While that may seem like a step backwards in terms of the skills writers need, I don’t believe it is. After all, in most corporate contexts the style is set and the job of the writer is simply to comply with that style. So, in practice formatting is often simply a rote exercise in force-fitting content into a corporate style using a WYSIWYG tool. Not by any means the most challenging skill for most technical communicators, and not one that will garner a lot of respect from managers.
Incidentally, that doesn’t mean there is no place for carefully designed and formatted content. Some content, for example quick reference cards or documents where you need to communicate complex ideas through graphic means, requires a high level of skill. However, that’s not the kind of content DITA is intended for.
(3) Prose for transitions and topic “context” is expunged to encourage content reuse.
Yup, though I would argue that this makes it harder to write in DITA, not easier. Sometimes you just need a transition, and even the DITA TC recognizes that as witnessed by the existence of the DITA publisher’s specialization, which contains some “connective tissue” for transitions.
(4) TCer no longer need be expert on a complete sw product, only a piece. -> fragmentation of knowledge
Here I have to disagree. You still need to be an expert on what you are writing about. If a technology like DITA makes you more productive (a debate I’ll leave for the future), then shouldn’t you be able to cover more territory, not less? Therefore, you might need to become expert in more areas, not fewer. Of course, a badly managed project may lead to writers being expected to cobble together documentation for some part of a product with little or no understanding of the whole, but I wouldn’t let the pathological case make the rule.
(5) Parts of sw product doc that gets most rewrite attention (the UI) requires least techn expertise.
This is a very interesting point that I’ve never fully considered, and which has merit. However, I don’t think that problem can be laid at the feet of DITA or modular documentation. That’s going to happen regardless of your methodology or tools.
So, what does it all add up to? I think the key is understanding what technology can and can’t do. There are at least two broad categories of technology that managers often confuse. The first is technology that replaces a particular skill. For example, the cash register at a McDonalds has technology that relieves cashiers from doing math, so they can hire people who are not skilled in math. The second is technology that allows a skilled practitioner to be more productive. For example, the computer makes it possible to write and edit text much more easily than a typewriter, but it won’t make a bad writer better.
To the extent that DITA works as a technology, it clearly works in the second category. But, if managers think it also works in the first category, they will naturally try to hire less skilled writers, with bad results for both their companies and the field of technical communication. That’s where I think Paul is headed in his points, and it’s where I agree with him. Our challenge as technical communicators is to make sure our managers understand the distinction and help them see how DITA, while a potentially useful technology and methodology, is not the equivalent of a MacDonalds cash register for writers.
Thanks, Paul, for letting me deconstruct your tweets.
Re: the “devaluation of the field” — how does *society* suffer? Occupational fields come and go; what’s the big picture concern here?
Milan,
I mean devaluation in a literal sense. That is, companies deciding to pay less for the services of people in that occupational field. I won’t claim that society suffers, but I will claim that technical communicators could be faced with a job market where their services are perceived as having less value than before.
Thanks for the comment.
These are great points. I’d like to hear your thoughts on how those of us in the DITA community can craft our messages to avoid the pitfall you mentioned — namely that managers will misunderstand DITA and modular technology and that they’ll seek less expensive, less skilled writers.
Not sure it’s fair to say that DITA is “dumbing down” the craft of technical communication as much as it is “speeding up” the process of publishing better-quality documentation (to multiple endpoints). Good/valuable/expensive writers will continue to be in high demand for orgs whose customers demand well-constructed documentation. DITA doesn’t make “doc design” decisions, it merely prevents writers from breaking style. A bad writer can write a perfectly “legal” document that isn’t complete, concise, or accurate, but it will still “look” good. A good writer leverages the time savers built into a structured authoring environment and churns out documentation that not only looks good, but is complete, concise, and accurate, and the writer has done it in a fraction of the time that it would have taken using non-structured authoring tools.
At the end of the day, the customer will or won’t demand great documentation– the success of the dev effort will hinge on its ability to address the customer’s demands. If the field is being devalued, it’s being devalued by the customer, not the type of authoring environment. If it’s being devalued by the customer, then that might be a sign that the user experience designed by the developers is rendering “great” documentation obsolete. I’ve always maintained that the best-designed software requires the least documentation, and I think that’s becoming more widely recognized. Better software keeps the user’s nose out of the documentation, and with fewer noses in the documentation, companies can save money on writers and/or tech support staff.
Something to consider: We might be seeing fewer jobs for mediocre writers because companies can churn out more and better documentation with a small staff of great writers and a structured authoring environment. In this paradigm, salaries remain constant or even improve some for the top 25% of professional writers. I think we’re just seeing the development of a much more competitive job market for technical communicators, even after high tech fully recovers.
I agree with Wallis. It’s not the technology that will lead to fewer jobs for writers, but what those writers bring to the mix. As a writer becomes less of a “form filler” and more of a asset to product development by making sure that the customers spend less time in the documentation. This can be done many ways: by making sure the interface is more intuitive, by making sure the any messages from the software are clear and concise, and by making sure that any necessary documentation is clear and concise also. The modularity is important to help integrate the information more closely to the product.
As for “connective tissue”, even without the publishing specialization, you just need to write the connective prose for those outputs that require them. DITA doesn’t prevent you from having untyped topics used for this sort of thing, the philosophy just discourages it. That said, there’s nothing that prevents you from creating those topics for use only in a book format of the information and using a different DITA map for the online. You can repurpose the base set of topics to whatever output format you want and tailor it to a degree.
This article, and the comment from Wallis Sholar, has gotten me thinking. More here: http://www.sdiglobalsolutions.com/Default.aspx?tabid=77&articleType=ArticleView&articleId=45
I don’t agree that DITA does anything to ensure “higher quality” documentation or to produce documentation that “look good”–probably quite the contrary due to the paucity of formatting control provided by XSL-FO, compared with the previous generation of print-oriented desktop publishing tools such as FrameMaker. Rather DITA is a means to enforce a particular three-class structuring scheme for text. The quality of documentation comes from its fitness for its purpose. Regarding “devaluing” of documentation, I would say this is the marketplace’s response to low-quality documentation. Low-quality documentation tends to correlate with poorly designed products. Low-quality documentation also tends to correlate with less skilled technical writers, regardless of product quality. My main concern with DITA, and with the topic-based model for authoring documentation, is that the scope of the tech writer’s required knowledge shrinks. There is no longer the need to know the great sweep of the product’s intended use. That knowledge migrates strongly back into the product development team; the old TWs must now consider moving to product development as a “usability” expert who may or may not have expertise in the product’s functional domain. My understanding today is that “usability” means mostly a person who focuses on web page design and screen layout, not functional workflow; I hope I’m wrong about that. If I’m not wrong, I see a long future ahead of poorly designed computer products with dumbed-down technical writers struggling to write topics that, as a set, don’t come close to meeting the customer’s needs.
@Richard — I get “devaluation of the field”, but I don’t think that documentation quality necessarily suffers because of it. It could, but it doesn’t have to.
Milan,
Absolutely true. A lot of this discussion has nothing at all to do with the quality of documentation. It’s all about perception. Do managers “perceive” that DITA makes it possible to hire cheaper writers? Do writers perceive that DITA will narrow their field or put them in a writing straitjacket?
That doesn’t mean the discussion isn’t relevant, but it does take it away from the core of what technical communicators are supposedly paid to do.
Pingback: Weekly links roundup by Communications from DMN