http://tc.eserver.org/authors/Akinci,_Ugur A bibliography of works by Akinci, Ugur 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/Akinci,_Ugur 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/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.