http://tc.eserver.org/publisher/Technical_Communication_Center A listing of works published by Technical Communication Center in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Technical_Communication_Center http://tc.eserver.org/34884.html http://tc.eserver.org/34884.html “Misplaced modifier” is a frequently committed logical error that even the most prominent publications fall for occasionally. Solution? Move the modifier clause right next to the subject of the sentence. http://tc.eserver.org/34862.html http://tc.eserver.org/34862.html Once you take an interest in technical communication and documentation you’ll quickly discover that’s it’s an “endless country,” really. There is so much to learn and track since both the market and the technology changes constantly. But this does not mean that you can learn things randomly and become a successful technical communicator. Actually there’s a better way that I call the “Learning Pyramid” which requires you establish a wide base of learning first and keep on building the upper layers on top of such a strong foundation. Each layer of this pyramid supports the more specialized layer established on top it. http://tc.eserver.org/34863.html http://tc.eserver.org/34863.html Capturing the essence of a topic is the heart and soul of good writing and editing. If you cannot tell what the main idea is, you cannot write it either. And if you cannot write it, how would you expect your readers to get it? So it all starts with you. Thankfully, it is not mysterious process. Here are two techniques that you can use to weed out the irrelevant details from your core idea. http://tc.eserver.org/34864.html http://tc.eserver.org/34864.html I am well aware of the irritating, hair-tearing frustration Word gives you when it won’t do what you want it to. Here’s a series of mini-articles showing you how to ‘get a grip’ on the program and make it do what you want, not what it ‘thinks’ you want. http://tc.eserver.org/34784.html http://tc.eserver.org/34784.html DocBook is a set of tools for implementing XML (Extended Markup Language)-based structured documentation. It is developed back in 1991 and is widely used today by those technical writers who generate single-sourced documentation. It is especially well suited for software, hardware and networking documentation. http://tc.eserver.org/34785.html http://tc.eserver.org/34785.html Try right-branching sentences in your technical documents for higher comprehension. Right-branching sentences start with the subject, follow it with primary verb (or sometimes the other way around if the verb is in imperative/order mode), and then end with modifiers and other relevant information. What branches off to the right of the subject and the verb is all the additional information you want to get across. http://tc.eserver.org/34786.html http://tc.eserver.org/34786.html It’s not easy to estimate how long a copy writing job will take due to the many factors involved in the estimation. http://tc.eserver.org/34687.html http://tc.eserver.org/34687.html At times, though, a writer is a bit overwhelmed at the start-of-work meeting. He becomes passive and takes in everything the client lays out without asking for more. That can result in some information that’s very important to the writer being missed. http://tc.eserver.org/34432.html http://tc.eserver.org/34432.html As technical writers, we’re much better off when we write in a way that follows the dictates of Standard Written English (SWE). We can believe all we want that one person’s way of writing is just as good as another. And, in private use, it is. But we know perfectly well that a person who writes the kind of material we do who doesn’t have what’s generally considered “good” language skills won’t be considered a professional - and won’t get work. http://tc.eserver.org/34433.html http://tc.eserver.org/34433.html If we say that it was mainly because of the Windows operating system that a computer could become a personal computer it would not be an exaggeration. The revolution is still on. Windows is far beyond what a common man presently knows and uses. http://tc.eserver.org/34434.html http://tc.eserver.org/34434.html A technical writer is a professional writer who designs, writes, creates, maintains and updates technical documentation including online help, user guidance, white papers, design specifications, system manuals and other documents. A technical writer should possess good research techniques, good sound of language and excellent writing skills. Apart from this one needs to have the following five skills. http://tc.eserver.org/34416.html http://tc.eserver.org/34416.html Knowing your document’s intended reading audience before you begin writing will always help you write more effective documentation. There are three simple questions you should always ask before you start writing. http://tc.eserver.org/34403.html http://tc.eserver.org/34403.html If you’re a generalist, as most tech writers are, you write about many things in a variety of media with a number of objectives. Each new job involves determining who your audience is, what their needs are, and how your product or service can satisfy those needs. Then you need to recognize, understand, and adjust your writing so one time it appeals to the camper and the next time to the business owner. http://tc.eserver.org/34386.html http://tc.eserver.org/34386.html When seeking freelance copywriters, many buyers specify that their only interest is in writers who speak English as a native language. Frequently buyers will request writers from a particular country such as the USA, the UK, Canada or Australia. This overlooks the fact that English is spoken as a first or second language in many countries. In fact, except for Mandarin Chinese, English is the most spoken language in the world. http://tc.eserver.org/34387.html http://tc.eserver.org/34387.html The most effective and powerful resumes provide analytical, precise detail about your background and achievements. In fact, resume writing has a strong correlation to technical writing in that both styles demand extreme precision. In fact, most readers of your resume will assume that what you show on paper correlates strongly to what you can do for your next employer. http://tc.eserver.org/34112.html http://tc.eserver.org/34112.html The more skilled and experienced the readers are, the more they hate to be told in minute detail what to do. The more skilled and experienced the readers are, the more they like Checklists instead of detailed procedural steps. http://tc.eserver.org/34113.html http://tc.eserver.org/34113.html Organize your writing so that it becomes very clear what kind of cause-and-effect relationship exists between different elements of your argument. http://tc.eserver.org/34114.html http://tc.eserver.org/34114.html You can use the “Hamburger Paradigm” of writing not only for technical articles and copy but for other types of communications as well, ranging from emails to criticism. http://tc.eserver.org/34030.html http://tc.eserver.org/34030.html Most hiring managers, and I am no exception, take a couple of passes when reviewing résumés. The first pass eliminates people who are clearly not what I am looking for. I try to answer two questions: first, are this person’s qualifications even in the ballpark for the job, and second, can he or she write at least well enough to create a competent résumé? Answering the first of these questions is not hard, but it does require that you understand the job requirements thoroughly and read the résumé closely. http://tc.eserver.org/34032.html http://tc.eserver.org/34032.html 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. http://tc.eserver.org/34034.html http://tc.eserver.org/34034.html Web writing is one of those assignments that technical writers do well due to their organized approach to technical information. But web writing differs from regular user guide and procedural writing in some important respects. The Web is a fast place. People usually don’t have the time to go through long essays. http://tc.eserver.org/34035.html http://tc.eserver.org/34035.html You might perhaps be considering whether to become a technical writer or not. You might be wondering: “What kind of a job technical writing is exactly and what does the future hold?” I can tell you right away that, at its most fundamental level, technical writing is safe and comfortable office work. http://tc.eserver.org/34036.html http://tc.eserver.org/34036.html XML, that is, Extended Markup Language, is the future of technical writing. There are TWO important reasons why that is so: XML is at the heart of “single sourcing” movement; and XML is a documentation manager’s dream since writing once and publishing many times drops unit production costs tremendously. http://tc.eserver.org/34037.html http://tc.eserver.org/34037.html As a technical writer you’ve heard this piece of sage writing advice a thousand times: you should stay away from jargon and write as you speak. It’s basic. Strunk & White said so, didn’t they? It’s true. But is this rule true ALL the time, unconditionally? No, I’m afraid it is not. Life has its exceptions. And so does this “rule.” http://tc.eserver.org/34039.html http://tc.eserver.org/34039.html Bulleted lists are important in technical writing. They summarize information in a manner that is easy to read and absorb. Use them whenever you can to get your information across quickly. Bullets are ideal for things-to-do, equipment, sets, collections, cooking ingredients, and all kinds of other lists. http://tc.eserver.org/34019.html http://tc.eserver.org/34019.html Most technical writers would include at least a few images to illustrate a point, or screen shots that accompany the description of a certain step-by-step procedure, etc. Organizing such images can really become a problem, especially when you have dozens and hundreds of them. Finding, editing, and importing them can quickly become a logistical nightmare, especially when a technical writer is working under a deadline pressure. Here are four ideas to organize and name your images for higher productivity. http://tc.eserver.org/34020.html http://tc.eserver.org/34020.html Have you considered writing White Papers for your clients, or offering them to your own prospective customers as a lead-generating device? If you operate in a technical field, I think you should definitely consider a White Paper. You can either write one ourself or have someone else write it for you. http://tc.eserver.org/34021.html http://tc.eserver.org/34021.html A technical writer will periodically need to interview Subject Matter Experts (SME) to gather information about a technical document. More often that not, and especially within the context of software development, most SMEs are engineers and software developers. But they can also be mechanical, electrical and other types of engineers, hardware installers, network engineers, testers, site foremen, call center engineers, field technicians, sales or marketing people, local dealers, etc. One cardinal rule of interviewing an SME is to do your homework well, in advance. http://tc.eserver.org/34022.html http://tc.eserver.org/34022.html Consistency of a technical documentation is what creates that subliminal sense of trust and confidence in the end-users. Someone once quipped: “it ain’t technical documentation if it ain’t boring.” This of course is not true since I always found technical documents very interesting indeed. I’m the sort of geekish person who can marvel at a well-designed user’s manual for hours and appreciate its beauty and all the effort and thinking that went into its production. I imagine how happy people would be when they use that manual and solve their problems and that, believe it or not, makes me happy as well. That’s the main reason why I’m in this business. http://tc.eserver.org/34023.html http://tc.eserver.org/34023.html Technical writing has a number of moral and ethical standards that a professional technical writer needs to comply with. Violate them at your own peril, by risking the sudden demise of your career. Here are some of these issues. http://tc.eserver.org/34024.html http://tc.eserver.org/34024.html Although I love using the proprietary software that I’ve mentioned in the first sentence, I enjoy using open source software as well since some of them are actually better than the paid software in some respects. http://tc.eserver.org/34025.html http://tc.eserver.org/34025.html Technical writing has its mechanical aspects that need to be mastered. A good technical writer must know how to use English effectively as well as various software products to produce acceptable technical documents. But I wish technical writing were all about that. The hardest part comes before one even sits down in front of a computer to type the first word. The hardest part in documenting anything is organizing the information in a way that makes sense from the user’s point of view. Otherwise a technical document suddenly looks irrelevant. http://tc.eserver.org/34026.html http://tc.eserver.org/34026.html Money paid to qualified technical writers and translators in a localization project is money spent very well indeed. Why? Because the worst thing for a project is to have the customers or end users switch to another product since they either cannot understand the instructions and the way an interface works, or the localized copy contains embarrassing mistakes that damage the brand name and image. http://tc.eserver.org/34027.html http://tc.eserver.org/34027.html Using the structured features requires advanced training and you probably won’t need them anyways unless you’re doing any “single sourcing” (which is the topic of yet another article). For example if you were doing any XML-based authoring or “database publishing” then you would definitely need to learn how to use the FrameMaker’s structured interface. However, there is an easy way to imitate structured documentation while you are still in the unstructured mode. This is one case in which you can have your cake (unstructured FM) and take a bite out of it too (by enjoying one selected feature of structured documentation). http://tc.eserver.org/34028.html http://tc.eserver.org/34028.html Here are seven time-tested design recommendations culled from my 20 years of experience as a professional writer, page layout and information designer. http://tc.eserver.org/34029.html http://tc.eserver.org/34029.html Adobe FrameMaker is the information design platform of choice for most professional technical writers and technical communicators across the globe. Like all powerful software applications, FrameMaker also has a lot of features and configuration possibilities. One of those features is the ability to create new paragraph styles. Each paragraph style in FrameMaker is represented by a “Paragraph Tag.” So to create a new formatting style you actually create a “tag.” Here is how you can create a new paragraph style/tag for your FrameMaker (FM) document.