5 Things That Will Never Change Despite Technological Changes in Technical Writing
© Ugur Akinci
The technology of technical writing is changing really fast. But the thing is we don’t really need to keep up with all of it, depending on where we stand in the overall landscape of technical communications.
Or let me put it this way: there are things that will never change as long as humans communicate with each other to solve their problems. Some aspects of communication are so basic they will be what they are as long as the world stands, whether you use HTML5 or not; whether you use DITA topics or not; whether you single-source for “mobile platforms” or not, etc.
1) RELEVANCE. The art of deciding how to tailor a block of text (a word, a sentence, sentence, a topic, a paragraph or a page, or a whole book – doesn’t matter) appropriately for its audience will never change. And, like most permanent things about writing, this is part art, part science. Part smart thinking, part experience, one-third good luck, and one-fifth “writing voodoo” since we writers never have access to perfect surveys and field data.
2) CONSISTENCY. The right hand must know what the left is doing. If you call an item “widget” on line 1, you cannot call the same object “tridget” a few lines down the text. If you say “see Figure 39”, a) Figure 39 must exist, b) Figure 39 must be what you promise it will be. Whether you write a 1,000-word guide or a ten-word DITA topic, what you write must make sense logically. It has to be consistent to communicate well.
3) ERROR-FREE LANGUAGE. No matter which language you write in, you cannot have spelling errors, missing punctuation marks, over-done punctuation marks (‼‼‼), run-on sentences, emotional or anthropomorphic language, inappropriate verbs and adjectives, etc. Your subjects must agree with your verbs (in English). Your verb conjugations must agree with your subjects (Turkish and Latin). Your propositional contractions and liaisons must agree with the gender and case of your subjects/nouns (French). Whether you know how to use Flash or Map-IDs has nothing to do with knowing how to write clearly, with no grammatical or spelling errors.
4) PERSUASION. The ten-thousand year old art of persuasion and rhetoric will not die just because there is another hand-held gadget in the market today. We need to argue our case clearly and persuasively, whether we do it in a single sentence or a whole volume of prose profusely illustrated with multi-media and YouTube video clips. We must know how to get to the heart of what is important, make our case, and get out as soon as possible. We need to be the masters of what in screenwriting is called “get in late – get out early” scene-writing method. If we cannot separate the “wheat” from the “chaff” (to use an ancient agrarian metaphor), or “urgent” from “spam,” we will fail as technical communicators no matter which latest technology we use.
5) MARKETING and SALES. The last but not the least of all is the great and timeless art of marketing, sales, and what was in another century called “horse trading.” To succeed in this life as technical writers we need to know how to price our product, how to approach others and get to say them “yes,” how to build up our own little house whether we work as freelancers or a for a company. Getting along well with others is the heart of success in life and as technical writers we also need to master that whether we use the latest Apple lap top or work with “apps” from our powerful new smartphone and iPad.
Life is changing fast. Soon some of us will end up looking more like engineers than writers. But all of us must master and keep practicing the above five skills if we also want to continue to communicate successfully and survive in the years and decades ahead.
Great article, Ugur!
I think sometimes we get so caught up in the latest gadget or tool that we sometimes forget that the fundamentals of writing still apply and without that making, it ‘look pretty’ isn’t going to help.
I keep thinking about the end user in this case. If the end user can’t understand and use what we provide it won’t matter what technology we’ve used. We will have failed as communicators.
I’m wondering, in the context of workflow, if tools and technology should be one of the last things we consider. Develop the content and then worry about how to present it. What do you think?
Sandy, thanks for your feedback! I think the following two roles will separate further and further in the future: 1) The content writers, 2) Format developers/engineers. However, I still think we traditional writers must at least have a general idea about the direction in which the technology is heading so that we’ll know the correct (i.e., efficient and most profitable) way to write our “topics” and localization-ready documents. But having said that, I don’t believe that we can (or nor should we expected to) keep up with every new twist and turn in the technological maze — just like a “format engineer” should not be expected to write well and get to the core of a subject quickly and communicate it with appropriate words and multi-media support materials. That’s my current take on the “skill-set bifurcation” that I see taking place in our field today.
Great article. I found your premise very relevant to a discussion going on here, http://dlvr.it/cjyjT (sorry for linking). I think that your perspective adds to the discussion about technology and writing and I would be interested to hear your take on it.
Fer, thanks for your comment! Alan Pringle is someone I follow and respect. And in general I agree with what he is saying in the article you’ve linked to (thanks). I agree (see my previous comment to Sandy’s feedback) that we tech writers should do more than just reading and following a “style book”. Those days are long gone. Now we should also know enough about the new technologies to write in a style that would provide appropriate input to the next stage in the documentation process (which I assume to be some sort of single-sourcing and/or localization process). I don’t think there is anything the “format engineers” can do to make our jobs any easier. But we definitely have to generate content in a way to be a seamless part of “the team.” On the other hand, I also think that the skill-set bifurcation in technical communications is real and will continue into the future.
Further to Ugur’s statement : “I think the following two roles will separate further and further in the future: 1) The content writers, 2) Format developers/engineers.”, you might be interested in reading JoAnn Hackos’s recent article about “Getting Started with DITA”: http://t.co/qAmn8cw.
She clearly makes the difference between Technical Writers (i.e. Content providers) and DITA developers:
“Let’s start by explaining that the DITA specification, especially the 2010 1.2 specification, is not intended for end-users and is not a learning tool”
…”committee members decided that the audience for the specification should be developers. With that in mind, the main body of the specification was rewritten to focus on the technical architecture so that the development community, including product developers and inhouse technical experts, could better understand the details.”
With regard to authoring for DITA, you might consider Tony Self’s “DITA Style Guide”.
Marie-Louise, thanks for the informative feedback. I couldn’t agree with Hackos more. Very pertinent link. I’ll also check out Tony Self’s “DITA Style Guide”. Thank you. Ugur
Hi Ugur,
I’ve only just come to this blog, (although I have been reading the posts I receive in the inbox) and I already find it quite a treasure!
Thanks!
Nikhil Khandekar
I truly appreciate this article post.Really thank you! Want more.
You’re welcome William. Take good care! Ugur