A directory of resources inthe field of technical communication.

Akinci, Ugur

23 found.

About this Site | Advanced Search | Localization | Site Maps
 

 

1.
#34021

The Cardinal Rule of Interviewing a Subject Matter Expert (SME) For a Document

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Interviewing>Technical Writing>SMEs

2.
#37020

Eliminate Phrases that Start With "in" from your Technical Documents

There are a number of filler phrases in English that start with “in.” You can improve the readability of your technical documents by eliminating such phrases and using much shorter equivalents.

Akinci, Ugur. Technical Communication Center (2010). Articles>Writing>Diction>Minimalism

3.
#38392

Four Ideas to Organize Your Technical Document Images

Most technical documents would have 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 you’re working under a deadline pressure. Here are several ideas to organize and name your images for higher productivity.

Akinci, Ugur. Technical Communication Center (2011). Articles>Graphic Design>Technical Illustration

4.
#34019

Four Ideas to Organize Your Technical Document Images and Screen Shots

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Graphic Design>Technical Illustration>Screen Captures

5.
#34112

How to Avoid Unnecessary Granularity

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Writing>Technical Writing

6.
#34023

How to Comply With Moral and Ethical Standards in Technical Documentation

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Documentation>Technical Writing>Ethics

7.
#34022

How to Format Your Technical Documents Consistently With a Template

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Document Design>Style Sheets>Technical Writing

8.
#36706

How to Prepare and Do Research For a Technical Document Before Writing It?

There are many preparatory steps in technical writing that you as a writer need to take before actually sitting down and start writing a technical document. Here are 7 issues you need to consider in the pre-production phase of your documentation project.

Akinci, Ugur. Technical Communication Center (2010). Articles>Documentation>Research>Technical Writing

9.
#37609

How to Review a Grant Proposal

Reviewing grant proposals properly is as critical a function as writing them. What good is it to spend six months on a grant proposal only to have it trashed in the hands of an irresponsible reviewer? Never forget that when you review a proposal you sometimes hold the career of another person in your hands. So focus, pay attention, and try to be as constructive and informative as you can — and pray that someone else will show the same courtesy and responsibility towards your proposal.

Akinci, Ugur. Technical Communication Center (2010). Articles>Grants>Proposals>Assessment

10.
#34027

How to Structure FrameMaker Paragraphs While Using the Unstructured Interface

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).

Akinci, Ugur. Technical Communication Center (2009). Articles>Document Design>Technical Writing>Adobe FrameMaker

11.
#34039

How to Use the Bulleted Lists Properly in Your Technical Document?

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Documentation>Style Guides>Technical Writing

12.
#34387

Resume Power Tip: Think Technical Writing

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.

Akinci, Ugur. Technical Communication Center (2009). Careers>Resumes>Writing>Technical Writing

13.
#34028

Seven Time-Tested Principles to Design a Cover For a Technical Document

Here are seven time-tested design recommendations culled from my 20 years of experience as a professional writer, page layout and information designer.

Akinci, Ugur. Technical Communication Center (2008). Articles>Document Design>Technical Writing

14.
#37718

Seven Ways to Avoid Misunderstandings When Writing for an International Audience

Technical communicators are increasingly catering to an international audience due to the expansion of the global market place. Such a development requires a new vigilance when writing technical documents in order to minimize inadvertent cross-cultural misunderstandings. Here are 7 things to watch for when writing for an international audience.

Akinci, Ugur. Indus (2010). Articles>Writing>Technical Writing>International

15.
#37951

Six Different Ways to Distribute Large Technical Documents

Large files have always been a distribution headache for technical writers. PDF files, book files of all kinds, PPT files need to be planned and generated always with an eye towards their distribution. If your files are too big to send around, review and approval processes will be jeopardized. Here are six different ways to distribute your large files.

Akinci, Ugur. Technical Communication Center (2011). Articles>Documentation

16.
#37021

Technical Writer Discovers the Joys of Virtual Machines

Imagine this: You need your own private configuration of a couple of servers running on a specific operating system, so that you can document the awesome ways that the servers and apps talk to each other. Setting them up is a pain and takes a lot of time. Besides which, there’s the minor problem that your own computer runs a different operating system. What if someone could simply copy a folder from their machine to yours, and you could click a couple of buttons to say: Take that setup, make it mine and let me run it from here on in. That’s what a VM (virtual machine) does for you.

Akinci, Ugur. Technical Communication Center (2010). Articles>Documentation>Technical Writing>Technology

17.
#34024

Top 3 Open Source Software You Can Use to Write and Design Technical Documents

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Software>Technical Writing>Open Source

18.
#37481

Uses Case -- Revitalize Your Technical Communication Career in the Pre-Writing Phase

The first few years of a typical technical communication career are great. You’re full of enthusiasm for your well-paying job and happy to generate one user manual after another. Yet after 5 or 10 years some of us hit a plateau. All of a sudden, the same job is not nearly as much fun. At that point you might want to extend and expand your career in two different directions.

Akinci, Ugur. Technical Communication Center (2010). Careers>Writing>Technical Writing

19.
#34037

When Should You Definitely Use Jargon in a Technical Document?

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.”

Akinci, Ugur. Technical Communication Center (2009). Articles>Writing>Diction>Technical Writing

20.
#34020

White Papers: How Vista Print Signed Up 5,000 Subscribers in 60 Days

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Writing>Technical Writing>White Papers

21.
#34026

Why Qualified Translators Are a Must in Product Localization and Translation?

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.

Akinci, Ugur. Technical Communication Center (2008). Articles>Language>Localization>Technical Translation

22.
#34036

Why the Future of Documentation Belongs to Extended Markup Language?

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Documentation>XML>Planning

23.
#34025

Wurman’s LATCH Model of Information Organization For Technical Documentation

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Information Design>Documentation>Technical Writing

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon