Technical Writing, a form of technical communication, is a style of formal writing and business communication, used in fields as diverse as computer hardware and software, chemistry, the aerospace industry, robotics, finance, consumer electronics, and biotechnology. Good technical writing clarifies technical jargon; that is, it presents useful information that is clear and easy to understand for the intended audience.
The Method M blog for technical writers, marketing staff, product managers and others who spend hours each week creating documents. This blog is dedicated to helping you work more efficiently and create better documents.
Policy writing and procedure writing is challenging because of the mechanics involved. Words must be carefully chosen; nuances must be considered. Understanding the mechanics of writing these documents is critical; however, an often overlooked aspect should be dealt with before the first word is written. How can policy and procedure writing tiptoe around the elephant in the room that everyone is trying to ignore?
Microsoft’s Visual SourceSafe was not created with technical communicators in mind. It was created for engineers writing software source code. But it is successfully used by technical writers in offices around the world to control documentation.
Technical writing is one of those jobs in which you're constantly learning. New tools, new techniques, new methodologies. No one knows it all. That's especially true for the new technical communicator. If you've graduated from a writing and rhetoric course or a technical writing course, you have a pretty good grounding in craft. But you're really only at the base of the mountain. There's still a lot to learn, and if you keep your eyes and ears and mind open then you can quickly pick up what you need to know.
Passion, though, is a funny thing. It's easy to become passionate about something. But the fire of that passion can also be easily dimmed or extinguished, often due to circumstances that are beyond your control. Throughout your career, you'll definitely find your passion waxing and waning. But holding on to that passion and nurturing it will make you a better technical communicator.
So you've just started out as a technical communicator, or you've been on the job for a year or two. And you've decided that maybe, just maybe, technical communication is the career for you and you're in it for the long haul. Now what? Think about the future and how you want your career to develop.
A friend asked the going rate for author's royalties on a technical or trade paperback, so I asked some people what they received. A few wrote back with extremely enlightening and fascinating comments. I passed these notes on to other authors, and received yet more interesting reading back. I have now edited all these comments down a bit, mostly taking out the names of authors and publishers and removing publisher specific comments.
The readability of technical writing, and technical manuals in particular, especially for second language readers, can be noticeably improved by pairing Theme with Given and Rheme with New. This allows for faster processing of text and easier access to the "method of development" of the text. Typical Theme-Rheme patterns are described, and the notion of the "point of a text" is introduced. These concepts are applied to technical writing and the reader is then invited to evaluate the improvements in readability in a small sample of texts.
'It's all in the manual.' How many times have you heard that - or said it in frustration? After all, when you are the person who wrote the manual, you know that all the answers are there. But time and again readers can't find what they need to know, or don't understand the material. Before you blame the reader, look again at how you've presented the material.
This podcast is a recording of a presentation I gave to students at the Missouri State University technical writing conference on April 23, 2010. With this presentation, because the audience was students, I focused mainly on the changing roles technical communicators are playing. My basic premise is that many IT environments have an assumption that “anyone can write.” Because of this assumption, technical writers are changing their roles, becoming hybrids with additional skill sets, or moving beyond the basics of writing in order to provide both value and find fulfillment.
This article is based on my presentation at the Institute of Scientific and Technical Communicators' annual conference in October, 2006. Every now and then, there is a change in the value of what technical authors deliver. These are moments when organisations pay attention to technical documentation. This is because they recognise that these changes mean they can create something that will be of real value to the business and to their customers. In recent years, there have been three "waves of interestingness". The first wave was the introduction of Windows Help (WinHelp). The second major wave was the introduction of the Internet and intranets. This was a time when organisations looked at how they could transfer large amounts of information from paper to online. They were faced with issues such as how users could access and understand all this information easily - issues that technical communicators deal with on a day-to-day basis. I believe we're just about to approach the new wave, which we have called "Tech Writing 2.0".
When the idea of culture is expanded to include institutional relationships extending beyond the walls of one organization, technical writing researchers can address relationships between our power/knowledge system and multiculturalism, postmodernism, gender, conflict, and ethics within professional communication. This article contrasts ideas of culture in social constructionist and cultural study research designs, addressing how each type of design impacts issues that can be analyzed in research studies. Implications for objectivity and validity in speculative cultural study research are also explored. Finally, since articulation of a coherent theoretical foundation is crucial to limiting a cultural study, this article suggests how technical writing can be constituted as an object of study according to five (of many possible) poststructural concepts: the object of inquiry as discursive, the object as practice within a cultural context, the object as practice within a historical context, the object as ordered by language, and the object in relationship with the one who studies it.
My concern for US writers is that they fail to grasp the momentum that counties like India have established and the high quality of university graduates they are now producing. In the next 10-15 years, IT jobs which can be replicated offshore/offsite to lower costs will be embraced more aggressively. US companies have little choice but to do this.
With all the talk about Web 2.0 and the attendant technologies, are readers actually being better served by documentation now than they were in the past?
To a non-practitioner, the art of technical writing is a nebulous pursuit to be avoided at all costs. The territory is ripe with jargon and Rube Goldberg devices that are not to be trusted. Besides, who in their right mind would want to be a "Technical Writer" (whatever that is)? But to the artisan, technology and language are the subject and medium in which we create our masterworks.
My advice for those wish to become writers: Write! Write! Write! I have always maintained that great writers are born, and professional writers are made. In the born writers there is an unquenchable thirst for writing, a passion for writing. Writing is a mission. Writing is the soul of the person. The professional writer does it for a living. There is a deadline and the writer can churn out the required number of words.
The Association of Teachers of Technical Writing was formed in 1973 to encourage dialogue among teachers of technical communication and to develop technical communication as an academic discipline. ATTW today has approximately 1,000 members and includes both graduate and undergraduate students of technical communication as well as professional technical communicators in business and industry.
Documents fail for many reasons. One common mistake is to adopt a ‘one size fits all’ approach to your audience. This works only when generic material, usually of a non-technical nature.