Parents spend years trying to teach their children to be polite, and some of us had to learn at school how to properly address an archbishop. Yet, it seems that advice on courteousness and politeness in technical communication is in short supply; most of us learn these skills through what is euphemistically called “on the job training.” With enough bruises on my back to demonstrate the amount and variety of my experience in this area (though not my skill), here are some of the things I’ve learned.
David Ogilvy was an advertising genius who distilled his successful concepts and techniques into a bestselling book I've just finished reading, called "Confessions of an Advertising Man". I wanted to read his book, because I often find it useful to look at other professions and ask whether their ideas could be applied to the world of technical authoring.
Having consistent terminology, and using that terminology consistently, is crucial. Terminology that isn’t consistent, and which isn’t used consistently, can cause more than just a little confusion. And documentation that doesn’t use that terminology consistently can cause more problems than it clears up. Not only with customers, but within your company and project as well.
In this post, technical writer Milan Davidovic that contributing to wikis can help novices build skills and a portfolio. And he offers a simple roadmap for doing that effectively.
Writing documentation isn't merely the act of pounding out dry prose. There is some creativity involved which comes from how you present the information, both textually and visually. The writing, though, needs to be easy to read, complete, concise, and to the point.
Many technical documents present information both graphically and verbally. While much is known about the verbal tools of technical professionals, technical graphics have been less fully examined. Here the drawings of a United States patent are examined revealing a system for organizing and presenting visual information that is analogous to commonly-used models for organizing and presenting verbal information.
Now it is very important to recognize the vital role of a technical writer and services expected to provide to justify the requirements of this profession. Since technical writer is a sub category of technical communication, that involves other categories involved in documentation, like content writer, software configuration manager, technical editor, information designer and many more.
Technical communication must ultimately serve the reader - there must be something that the writer can do to clarify the information and make reading part of the process that makes the product usable.
The official documentation for most apps or gadgets doesn’t always pack the information users need. It covers the basics, but it doesn’t go much further. Community documentation can fill that gap, but users need to do a lot of searching. Is there a way to effectively and efficiently combine the two?
This article contributes two arguments to the disciplinary conversation of technical communication with the aim of exploring leadership opportunities our field has in the field of information technology. The arguments assert that 1.) Writing is the core technology in any IT system, and all IT systems attempt to leverage the core strengths of writing to make these systems more valuable. 2.) Technical communicators have a central role to play in IT systems consonant with our core competencies: we attend to the balance of situated as opposed to generalized strategies and the balance of appeals to identity in writing about the practical use of technology, and we are well prepared to attend to these balances in other important arenas of IT discourse. Together, these two arguments are meant to begin or continue conversations—in workplace and academic contexts alike—that bring the issues of IT development and the future of technical communication closely together.
Though I have a degree in technical communication and have worked as a technical writer for four years, I still had no idea what should be taught in a technical writing classroom, or how one should go about teaching it. Before I ventured into the arena as an instructor, I wanted to find out what goes on in a technical writing classroom. Two types of practical research that I thought would provide some insight into technical writing instruction were: an observation of different technical communication classrooms; and a survey of various textbooks available for technical communication courses.
Although we look at the past with embarrassment about some of our practices, we often lack the foresight to see the present with the same degree of scrutiny. Years from now, we’ll look back at what we’re currently doing and not only blush, but feel remorse and wish we could get back what we lost.
This article is about better commenting practices for the purpose of—perhaps—helping some to better their programming practices. But before beginning, let me qualify the entire thing by saying that I am not a programmer—not the professional kind anyway. I have created small programs in the past for some of my employers, but that is not how I make my living. Therefore, I am not trying to teach principles of programming. I am only a writing teacher who happens to enjoy programming as a hobby. And while I cannot provide insight into better programming principles, I can offer guidance about writing those short pieces of text programmers always embed, but sometimes neglect. Helping students write better documents is, after all, my occupation; and believe it or not the principles I teach to write better papers are not that different from the principles needed to write better code.
For people of the present century, technology and its innovations are inevitable. Anything and everything witnessed around is an embodiment of technology. Without proper understanding of the artefacts or products the factor of comfortable existence becomes a burly issue. To address this issue of understanding complex technologies and to enlighten the folks with information a cluster of skilled, trained and prolific technical communicators has been implanted.
In the absence of safety concerns, I think that accuracy must win. Thus, as the information curator, you have a responsibility to correct inaccurate information. If the inaccuracy is truly dangerous, you may need to edit the post directly. Make sure that you disclosure what you've done with brackets.
Twitter can be a great tool, and can help people get answers quickly. However, when you have a question and need an answer, you probably ought to consider your question, and determine what channel is best suited for the type of answer you need. That may or may not be Twitter.
Although rhetoricians have studied the discourse practices of engineers, little is known about the production workers who must assemble engineering knowledge into functional products. This case study examines what happens when a production worker tried to improve manufacturing documentation, and how her success depended upon both her craft knowledge and the rhetorical skills she attributes to a Writing Across the Curriculum program she experienced in college.
A huge problem for projects is the lack of a common language between the developers and the users. When my colleague and I were preparing a presentation for an internal conference on this subject, he said something that has stuck with me. He said, “The goal of the project is to make the user successful.” I added to that: It’s not to write code or validate code. It’s not even to ship a product or make money (of course, this last one is especially true in a non-profit organization). At least, it shouldn’t be these things.
Technical writers are midwives who deliver the message to users. Experienced technical writers enable you to understand complex technical concepts easily. Based on personal experience, technical writers always put the reader first.