User:Shruti2014

Insert non-formatted text here

Overview
Technical writing is an art that must be mastered by all engineers if they are to be successful in communicating their ideas, concepts, and designs. As engineering students enter industry or graduate-level education, they must be prepared with effective professional communication skills if they are to be successful. This tutorial provides some basics about technical writing.

Why Engineers Need to Communicate Well
Working engineers have to communicate professionally in several ways. They must prepare on-the-job written work, both formal and informal. They are faced with the need to develop, prepare, and conduct presentations (sometimes impromptu) for supervisors, colleagues, customers, and others. Occasionally they must interact with the media. Further, they are frequently required to collaborate as subject-matter experts (SMEs) with professional technical writers.

It is also true that accomplished writers and speakers make better job candidates. There is an increased emphasis on communication in academia that translates into increased awareness from employers and graduate faculty as they seek to make selections.

As a practical matter, the processes of writing and speaking help transform people into better learners. This learning process involves analysis, organization, development, and iterative revisions that lead to the ultimate application.

Technical Writing Is About Managing Complexity
The basic task is to convey complex information clearly. The guidelines are to write clearly and directly, handle details and structure purposefully, and be professional and ethical.

The Process – Involves analyzing your Purpose and Audience

Purpose is the first consideration.

Why am I writing? What are my objectives? – To report my findings, to persuade my boss, to complain about faulty products or services, to instruct the unknowing, to recommend?

What situation or events have led to the writing? – Ongoing research, a need that affects me/my department, a recent problem that needs a prompt remedy, someone else's need to know?

'''What kind of document is needed, and has this been predetermined? –''' Report, proposal, letter, instruction manual? What expectations or requirements exist for document format? Audience is the most important consideration. Who will read my document? – Boss, co-workers, colleagues, customers, vendors? Why does this matter?
 * THE READER'S LEVEL OF UNDERSTANDING – How much can you take for granted? What needs to be explained and what does not? Is your reader a lay/non-expert reader? Will your reader be insulted by too much explanation (or too little)?
 * THE READER'S REACTION TO THE DOCUMENT – Can/will your reader take action based on your writing, and how will this action affect others? Will your reader follow your instructions for a timesensitive action, or is time not critical? Will your reader react emotionally, and should you safeguard against this somehow?
 * THE READER'S IMMEDIACY – Will your initial reader be your only reader, or will there be others? Will your document be fairly "short-lived," or will it live on as part of the company's documentation, and why is this significant?
 * THE READER'S PERCEPTION OF YOU – What does a document not suited to its reader reflect about its author? What are the possible consequences of this perception, and which one is the most grievous?

"[T]he reader [is] in serious trouble most of the time, a man floundering in a swamp....[I]t is the duty of anyone attempting to write English to drain this swamp quickly and get his man up on dry ground, or at least throw him a rope." — E.B. White, in his introduction to The Elements of Style

Precepts to Follow When Writing Technical Pieces
Strong communication skills are essential to a successful engineering career; developing these skills takes feedback, practice, and diligence. Writing is inherently a process; the most important parts of this process occur before we physically begin to write.

In the context of technical communications, a concise, direct, appropriately formal writing style is always preferable to wordy, overly complex prose. Content and mechanical precision and thoroughness are the responsibility of the writer.

Engineering audiences determine everything about the documents and presentations that the engineer creates, therefore, the author must write and present for his or her audiences, not for himself or herself. Numbers and other data are not self-explanatory and cannot speak for themselves; they must be carried and explained by text.

Regardless of the circumstances that produce them, written documents often serve as documentation; as such, they live on after their composition and can reflect a great deal about the author, situation, and organization. The details that the writer includes and the clarity with which these are expressed have a direct impact on the usefulness of the document and its reflection on everyone involved.

Twelve Basic Guidelines for Technical Writing
These guidelines provide a simple check list when writing technical pieces. If they are used, they will improve the quality of the finished product, improving the writer’s chance of success.
 * 1) Always use the simplest, most accurate word, phrase, design, or graphic. Never use two words where one will do.


 * 1) Always strive for an attractive, consistent, well-spaced design. The good first impression that this creates is invaluable.


 * 1) Be thorough. Readers won’t mind additional details if your design allows for navigating around them.


 * 1) Fill a document’s section only with the information that should logically be there.


 * 1) Make sure all sentences in a paragraph lead into each other and that they fully support the topic sentence. These connections should be obvious.


 * 1) Refer to yourself cautiously. Instilling a sense of yourself can help both your writing and your reader but not if your presence obtrudes or shifts the document’s focus.


 * 1) Use passive voice only with good reason.

Documenting the User Interface
Understanding the user interface can be a confusing experience for customers. By using a consistent set of terminology and style, you can help customers navigate the product user interface successfully. Once customers become familiar with this system, they can jump seamlessly between content about different products. This chapter contains the following sections: Screen Terminology

• Dialog Boxes and Property Sheets

• Unnamed Buttons

• Menus and Commands

• Screen Terminology • Control Panel • Mouse Terminology

• Messages

• Key Names

• Command Syntax

• File Names and Extensions

•	Screen Terminology

o	Dialog Boxes and Property Sheets

?	Menus