By: Barry Millman

Overview

Many organizations produce in-house tools or modify commercially-available tools for their own use. These tools should get documented so they are of use to others in the organization.

If this documentation is not created or is poorly written, it costs you twice:

• The first cost (attributed to any poor user document) is the cost of answering the Users’ questions (technical support).
• The second cost, arises from the lost time of your employees trying to understand the poor User Document.

Psychological costs also affect both the external and the in-house User.

The first cost: Technical support

This is the cost you incur whenever you produce poor (or no) User Documents. It arises for any User when he/she needs technical support. For external Users, the cost is your technical support staff, toll-free telephone lines, etc.

For internal Users the cost is the time spent by the developer or modifier of the tool to answer the questions of his/her fellow employee. This is an expensive technical support cost…these people are usually paid more than your technical support staff. Thus this first cost is even greater for poor in-house documentation than for shoddy documentation released to the public.

The second cost: Users’ time and resources

For Users outside your company, the second cost is assumed by the Users themselves or their employers. These confused Users are expending their company’s time: the time lost trying to get the product to work, and the time spent dealing with your technical support.

For your in-house Users, this cost is borne by your company. It is your employee–on your time– that is wasting your company resources trying to use an arcane product or document. Here is where your deficient in-house documentation costs you twice.

Psychological costs affect all readers

In addition to these time and monetary costs, there are the psychological costs wreaked by poor User Documentation.

For frustrated Users outside your company, your poor documentation results in a negative perception of your company and its products. This may result in loss of business.

For users inside your company, the psychological cost is decreased employee morale, as evidenced from these possible statements:

• Our company produced this junk?
• These people are not a sharp as I thought they were.
• If other employees can produce this confusing stuff, then I can work at that same level.

Thus the ill will outside your company can cost you future sales; the ill will inside your company can cost in decreased employee morale.

Solution: Informal reviews

Once someone writes a User Document for an in-house tool, that document should be informally reviewed.

Self-review

The author can perform the first review on his/her own.

Use your word processor’s spelling checker to correct common errors. You can use the word processor’s grammar checker, however most of these are inaccurate.

Before doing this review, let the document sit for a day or two. This will help you forget what you meant in your unclear writing. When you do the review and you find yourself asking “what did I mean here?” you will have found a place in the document that needs revision.

When doing the review, imagine you are user of the tool and reader of the document. Imagine the tasks that the tool user wants to do. Does the document enable the Reader to find what he/she needs? Is the writing accurate (correctly describes the tool), clear, and complete? Make the changes that would improve the document.

External review

Then, if possible, use an external reviewer (inside your company). To do this, the writer should:

1. Find a potential User of the tool. This should be someone who is not already familiar with the tool, and as similar to the target audience of the tool as reasonable.
2. Have that reviewer use the document to guide him/her in use of the tool. Solicit comments on the document. Note the suggested changes, additions, deletions, clarifications requested by the reviewer. Some questions to ask might include:
   • Does the document tell you what you need to know?
   • Is it easy to find what you need in the document?
   • Does the document answer your questions? If not, what questions are unanswered?
   • Is the document easy to follow? If not, where are the problem areas?
3. The writer should make changes as necessary.

If you cannot perform this “semiformal” review, then get anyone other than yourself to simply read the document, and make suggestions for improvement.

Caution

Make sure that the review process does not become an inhibition to those writing User Documentation for in-house Users. Stress a cooperative—not adversarial—mechanism whose result is quality work. Do not try to create the perfect User Document.

About the Author:

Barry Millman, Ph.D., has a Bachelor of Science in Electrical Engineering (1966, Carnegie Institute of Technology) and an M.Sc. and Ph.D. in Psychology (Human Information Processing, University of Calgary). He has been a consultant for over 25 years, an instructor, course developer, and award-winning speaker. For the past seven years he has been researching and creating resources to help organizations create great User Documents.

Visit: http://www.greatuserdocs.com/ for resources to help you create the User Documents that your Product needs and your Users deserve.

Visit http://www.greatuserdocs.com/ReadingRoom.htm for more articles like this one.

Article Source: ArticlesBase.com – How Poor In-house User Documents Cost you Twice & What to Do About it

by Barry Millman

Overview

In your User Documentation, you direct your Reader to perform tasks with your product. If you don’t tell your Reader what to expect when performing those tasks, you will have a baffled Reader, resulting in dissatisfaction and expensive calls to technical support.

Example: Reverse osmosis water filter

I bought and installed a Reverse Osmosis water filter. The instructions told me to fill, and then empty (the instructions foolishly used the term dump, which would have caused the destruction of the system) the tank.

The filter had a capacity of about 100 gallons per day. Thus I expected the initial fill (4.5 gallon tank) to take less than one hour. After about an hour the tank was still filling. Worried, I called the technical support. I was told that it takes about two hours for the tank to fill.

One line in the User Documentation would have eliminated that call: “The tank initially takes 2 hours to fill.” Not knowing what to expect I, and perhaps other Users, wasted the time and money to call the technical support line.

Example: Upgrading a router’s software

I had some problems with my Cable/DSL (Internet-Ethernet) router. The internal control panel made it easy to check for and download updates to the internal software. The system told me that it would take a few minutes to check for updates (good), but it did not tell me how long the update would take to perform once I downloaded the file.

Not telling the User what to expect in terms of time is a mistake. I started the update and after a few minutes of operation (was it working?) I canceled the process. I re-started it again, and decided to wait longer to see what happened. It took a few minutes longer, and successfully completed.

It would only take a simple phrase such as “the software update can take up to five minutes to complete” to reduce the User’s anxiety.

Progress indicators (as displayed in a windowing environment) are often useless. Some go beyond 100%, others are logarithmic: they move quickly in the early processing and wait, seemingly at the end, for a long time while processing is completing. Consider making progress indicators relate to the time of operation, not number of files.

Some progress/activity indicators have nothing to do with the program they are associated with. I have used virus checkers that have abnormally terminated, yet the activity indicator kept on moving. Make sure that progress/activity indicators do reflect activity of the associated program.

File downloads do it

Telling the User what to expect is not a new concept. If you have ever downloaded files, the download site will often tell how long the file will take to download, based upon your Internet connection.

Example: Your product’s indicators

While most examples of telling the User what to expect deals with the time needed to complete an activity, others can be related to the indicators and performance of the product.

I have a small smart battery charger that has a red light for each of the battery positions. Unfortunately, the operation of these lights is impossible to understand, and there is no description of how they work.

Here’s what happens. When you first insert the battery, the light illuminates. A short while later (the charging still has many hours to go), the light goes off. Sometime toward the end of the charging cycle the light may go on again.

This is clearly confusing to the User. The User’s expectation is that when the light goes out, the charging is completed. This would result in a lot of User frustration, as Users would try to use “charged” batteries that were not charged. The developers of the battery charger should explain the operation of these displays.

The bottom line

Tell the Users what to expect as they use your product. Often this information is the amount of time it will take for an operation to complete. For other products, you may have to tell the User what the indicators mean.

Don’t leave your document Readers confused or left to figure things out on their own. Doing so will reduce your Users’ comfort with your product, and increase your technical support costs.

About the Author:

Barry Millman, Ph.D., has a Bachelor of Science in Electrical Engineering (1966, Carnegie Institute of Technology) and an M.Sc. and Ph.D. in Psychology (Human Information Processing, University of Calgary). He has been a consultant for over 25 years, an instructor, course developer, and award-winning speaker. For the past seven years he has been researching and creating resources to help organizations create great User Documents.

Visit: http://www.greatuserdocs.com/ for resources to help you create the User Documents that your Product needs and your Users deserve.

Visit http://www.greatuserdocs.com/ReadingRoom.htm for more articles like this one.

Article Source: ArticlesBase.com – Great Technical Writing: Tell your Users What to Expect

by Barry Millman

Overview

Incomplete User Documents disappoint your Readers. Two attitudes of many Technical Writers result in incomplete User Documents. These two attitudes are:

• Everyone Knows That, and
• The User Can Figure It Out

This article describes these attitudes and presents methods for overcoming them. The result is more effective User Documents and more satisfied Users.

1. Everyone Knows That

The Everyone Knows That attitude makes assumptions about your Reader’s knowledge. These assumptions cause your Reader grief.

Here’s an example of a possible Everyone Knows That. Do you know this:

Tomatoes. Most of us keep them in a refrigerator. However, storing them in a refrigerator will ruin the taste and nutrition of tomatoes. Tomatoes should be stored on a kitchen counter at room temperature, until they are cut. Once cut, tomatoes should then be stored in the refrigerator.

Does everyone know that? What do you assume that everyone knows about your product?

Sometimes your User Documents have to overcome previous User experience. Everyone thinks that they know how to properly (safely) shut off a barbecue…they don’t! The safe shutdown method is described in most barbecue User Documents, but it is not “advertised” (forcefully presented) in the User Documents.

It’s rarely true that Everyone Knows That. Just because you find something to be obvious, it does not mean everyone knows that something.

Here’s another example: How do you use a (combined product — two-in-one) shampoo and hair conditioner? When shampooing, the shampoo is massaged into the scalp and immediately rinsed. When conditioning the hair, the conditioner is massaged into the hair, and remains on the hair for about two minutes. Now, what do the Users do for the combined product: rinse quickly, or let the product remain in the hair?

If you have the Everyone Knows That attitude when you write, you will tend to leave out needed material from your User Document. You will be doing a disservice to your Readers, and to your writing.

When in doubt whether everyone knows something, assume that they do not. Then,

• add some text explaining the topic, or
• tell the Reader where to find information that will explain the topic

Another Caution

Be careful about assuming that just because you explained something earlier in your User Document, your Reader will remember (or even have read) that information. It is rare for Users to read product documentation from start to finish.

When in doubt, add a reference to that earlier (background) information. Tell your Reader where to find it, or provide a link to it if your document is electronic.

Here’s a Thought Experiment: You are a User of products: How often do you read the product documentation from start to finish? If you always do, then ask some other people. (The great thing about this fact — that Users do not read the documentation from start to finish — is that it results in great flexibility in writing, formatting and editing the product documentation.)

2. The User Can Figure It Out

The User does not want to have to figure things out. The User is not reading a mystery novel or any other literature, where he/she wants to think about what is happening.

When someone uses your product, they are using it to meet their own needs. Your product may be central to your life, but to your Users, your product is a means to an end. And they do not want to have to decipher your product documentation.

Here’s a simple example. An e-mail tells you to call someone, but the message leaves out the phone number. You are expected to find the phone number on your own. The writer probably knew the phone number, but left it out. This information oversight gets expensive within a company when the e-mail is sent to many employees…each looking up the phone number on his/her own.

My favorite pet peeve: dates. Within recent memory we “survived” the Year-2000 transition. Yet we still write dates sloppily. We use “06” for a year, instead of “2006.” When we see things like “07/11/04” what is the date it is referring to? Is it November 4, 2007, April 11, 2007, or some other permutation of the numbers. The standards for the format of dates vary around the world. This is an example of both assumptions:

• everyone knows that (because there is a “standard” date format — there is not), and
• the User can figure it out (by seeing if my other dates provide clues to the format)

Don’t leave things for the User/Reader to figure out for themselves. It takes you only a few moments to include the material your Reader needs, and will save many Readers many hours in figuring things out.

Do It:

The writing literature tells you to know your Reader. Here is where you use that knowledge to improve your writing.

Either

• find someone who is like your intended Reader, or
• do your best to act like your intended Reader (you can do it if you need to)

In reading and evaluating the document, look for places where

• the writing assumes that everyone knows that
• the writing expects the Reader to be able to figure it out
• the writing makes jumps that your Reader cannot follow
• the writing makes the assumption that the Reader has read and remembered the entire document

Fix these places. It only takes a few words or sentences.

Everyone will be happier.

About the Author:

Barry Millman, Ph.D., has been a consultant for over 25 years, an instructor, course developer, and award-winning speaker. For the past seven years he has been researching and creating resources to help organizations create great User Documents. Visit: http://www.greatuserdocs.com/ for resources to help you create the content and access that your Users want and need.

Article Source: ArticlesBase.com – Great Technical Writing: Banish These Two Attitudes

Author: Barry Millman

Overview

The User-Product Life Cycle (U-PLC) is a powerful tool for the User Document writer. Use the U-PLC to generate the high-level topics for your User Document.

The User-Product Life Cycle (U-PLC)

Usually, when we think of a Product Life Cycle, we think in terms of the development and production of the Product itself. When writing User Documentation, consider the U-PLC to help you generate all the topics necessary for a complete document. User Documentation should support your Users in all of their interactions with the product.

The User-Product Life Cycle refers to the full range of interactions between the User and the Product itself. This is more than simply “how to use the product.” As you will see below, Use the Product is only one stage in the U-PLC.

Stages in the U-PLC

Here are the stages in the U-PLC (assuming that the User as acquired the Product):

Transport the Product to its working location

Unpack the Product

Transport and Unpacking of the product are listed here just for completeness. These are currently displayed on the packaging itself, usually in pictorial form, and do a good job.

Overall knowledge about the Product.

This is information that is presented to the User early in the User Documents.

Topics here include safety, legal, and disclaimers related to the product.

The description of the product should indicate how the product may change the way that the User currently does things. For example, an analog voice recorder will require the User to listen to all the stored items to find a particular one; a digital voice recorder will enable the User to quickly jump from one message to another.

Set up or Install the Product

Environments

It is important for the writer to think of the various environments where the product will exist. For example, how should a computer program be installed in a Windows, Mac, or Linux environment?

Environments includes other things that the product must work with. For example, how should a DVD player be installed in a system currently composed of a TV and a VCR? How about installation to a TV & VCR system where the TV has only one video input?

User Capabilities

The capabilities required for the User to set up the product are also important. Since the assumptions related to the User for set up may be different from the assumptions about the User in using the product, the wise writer will present the skills (and perhaps regulations) needed to set up the product. A section entitled Can You Set Up This Product? will enable the User to make the decision about whether to set the product up themselves, or find outside help.

For example, suppose the product is an electrical light dimmer that is intended to replace the light switch in the User’s home. Using the product merely requires adjusting the dimmer’s single control to set the desired light level. Installing the product requires experience with home electrical wiring–does the User have these capabilities?

Sometimes, the limitation may be legal. In some jurisdictions — Quebec, Canada, for example — only qualified electricians are permitted to install or modify electrical circuits in the home. Thus in Quebec, the general User of the dimmer will not be able to (legally) install the light dimmer.

Use the Product

This component is the focus of most User Documentation. It should contain at least these three sub-topics:

Starting the product

Actual Use of the product

For most products Actual Use is the central focus of the User Document.

Ideally, this should be divided into basic or common product functions, and advanced functions. A good example is photo-editing software. Most Users want to crop, rotate, and adjust the brightness and contrast of the image. These are basic functions. More advanced functions might be combining the parts of one picture with another.

Shutting down the product

Is there any maintenance to be done at shut down? List it here and in the Maintain section.

Maintain the Product

Consider breaking this down into time periods, such as: after each use, weekly, monthly, yearly, as applicable.

Move the Product

For a computer software program, how the User should move the program and its data to another computer; computer users often upgrade their computer hardware. While it is often assumed that the User should re-install the product on the new computer, there always is the question about moving the data related to the product: where is it located, and how should it be moved so the newly-installed program can recognize it on the new computer?

For a physical product, are there any special considerations in moving the Product to another location?

Discard the Product or its By-Products

Here I would like to mention only selling the used product. It might be wise to mention that by keeping the User Manual, the seller may find it easier to sell, and possibly get a higher price, for the used product.

Using the U-PLC in Your Writing

As you generate the topics for your User Document make sure that you keep the U-PLC in mind. Ensure that you include topics in your User Document Outline to assist your User in all phases of the U-PLC.

Great User Documents can assist in the U-PLC section that I did not present here: acquisition of the product. Your marketing department may be able to use your Great User Document as part of its marketing campaign.

About the Author:

Barry Millman, Ph.D., has a Bachelor of Science in Electrical Engineering (1966, Carnegie Institute of Technology) and an M.Sc. and Ph.D. in Psychology (Human Information Processing, University of Calgary). He has been a consultant for over 25 years, an instructor, course developer, and award-winning speaker. For the past seven years he has been researching and creating resources to help organizations create great User Documents.

Visit: http://www.greatuserdocs.com/ for resources to help you create the User Documents that your Product needs and your Users deserve.

Visit http://www.greatuserdocs.com/ReadingRoom.htm for more articles like this one.

Article Source: ArticlesBase.com – Great Technical Writing: the User-product Life Cycle – a Documentation Tool

Author: Ugur Akinci

Specification (spec) sheets are like maps for the captain of a ship or the blueprints for an architect. No project can start without first putting the specs on paper.

Here are two spec sheets with which a technical writer should be familiar:

Design specs – This is a document that builds on and follows closely the “functional specs” document. It basically describes what a product should look like when it is manufactured. It takes all the functions and detailed features specified in the functional specs sheet and translates them into a visual language.

For example, if the functional specs describe a configuration function, the design specs describe the button or the navigational link that should launch the configuration interface; what it’s colors and fonts should be; where exactly the fields and buttons should be placed on the dialog boxes; etc. Design specs may also specify a product’s maintenance schedule and the service requirements, etc.

Testing specs – This document specifies the unit and system integration testing that needs to be performed on the product before it is released to the market. This document sometimes also includes the testing scenarios (or scripts) that the test engineers should follow step-by-step to reveal the weaknesses and discover the bugs before consumers can find them.

Technical writers sometimes contribute directly by writing such testing scripts and actually participating in the tests as well. Testing specs and the testing results are precious since they reveal for a technical writer all the vulnerable points of a product and become the input for the Release Notes that accompany every major release of a product, especially in the software industry.

If you are interested to read more about technical writing as a career and how it can help you earn a steady living, visit http://www.learntechnicalwriting.com. You might be pleasantly surprised with what you’ll find out. Join the thousands who are already helped and inspired by this information provided by a Fortune 500 Senior Technical Writer. Visit today and claim your free report “How Much Do Technical Writers Make?”

About the author

Dr. Ugur Akinci is a Fortune 500 Sr. Technical Communicator http://www.technicalcommunicationcenter.com/

Article Source: http://EzineArticles.com/?expert=Ugur_Akinci
http://EzineArticles.com/?Technical-Writing—Why-Should-a-Technical-Writer-Be-Familiar-With-Design-Specs-and-Testing-Specs?&id=1894071

Author: Warren Wong

When speaking or writing English, it is important to make the subjects and the verb agree. Let’s go over some rules using basic sentences. These rules will help you choose the correct verb based on the subject.

Rule #1: Subject usually left of verb

Before you know which verb to use, first you need to know what the subject is! As a general rule, the subject is usually immediately to the left of the verb.

Example: That tree grows fast.

Here, the subject is immediately to the left of the verb. The verb is “grows”, making the subject “tree”.

Example: Sometimes dogs bark for fun.

The verb here is “bark”. As you can see, the subject, “dogs”, is immediately to the left.

There are exceptions to this rule. One big signal of a sentence where the verb comes before the subject is when the sentence starts with “There”.

Example: There are apples everywhere.

“Apples” is the subject. The verb, “are”, comes before the subject.

Rule #2: “Or” use singular, “and” use plural

This is for sentences with two or more subjects. If the subjects are connected with the word “or”, you want to use a singular verb. If they are connected with the word “and”, use a plural verb.

Example: Tom or Sally is picking it up at noon.

Our two subjects, “Tom” and “Sally”, are connected by the word “or”. Because of this, our verb needs to be singular (is)

Example: Tom and Sally are picking it up at noon.

By connecting our two subjects with “and”, we now use a plural verb (are).

In these examples, the subjects were singular. What happens if one of the subjects is plural?

Rule #3: When in doubt, verb agrees with nearest subject

When a singular and a plural noun are connected by the word “or”, the verb should agree with the nearest subject. Remember, “are” is used with plural while “is” is used with singular.

Example: The players or the coach is in the gym.

Example: The coach or the players are in the gym.

Let’s look at two examples that use verbs different than “is” and “are”.

Example: Tom or the cats run for dear life.

Example: The cats or Tom runs for dear life.

Rule #4: Don’t become confused of the subject

This can be a tricky thing to remember. Some sentences have a phrase after the subject but before the verb. These phrases can make identifying the subject an adventure. In the below examples, the subject and the verb are in italics. Notice how the words in between could change the verb usage if they were falsely identified as the subject.

Example: The quarterback, not to mention the rest of his teammates, is worried about tonight’s game.

Example: My neighbor with all the birds is running for Sheriff.

Example: The dogs who watch the cat are getting tired.

Example: That girl who likes the flowers jogs twice per day.

Example: One of the trees is dying.

Rule #5: Everybody is singular

Although they sound plural, subjects such as everybody, anybody, no one, somebody, nobody, each, either, and neither are singular and use singular verbs.

Example: Everybody who came tonight is to be commended.

Example: Anybody is welcome to attend.

Example: Nobody I love came to my party.

Example: Either will do.

Example: Each of these cars is a fine choice.

As you work towards mastering English, there will be times of frustration. But don’t give up! Just remember, practice makes perfect.

About the Author

Warren Wong writes for 1-language.com, a website dedicated to helping people Learn English.

Article Source: Articles Engine

The field of content writing serves as a very important feature in a website. The main reason people visit the site is to search for information on different goods and services. Audiences will be satisfied if they get informative and satisfactory content on one’s site. Besides this, a site needs to be well designed as well with information-rich content in order to drive more traffic.

Easy and simple language is the prerequisite of any content. There are a few pointers that need to be reminded at all costs in order to excel in the field of content writing. The first and foremost point is to ensure that the language of the content is in accordance with audiences for whom the articles, reviews or blogs are meant.

For example, if a content writer intends to write a promotional article, then he needs to know the nature and services offered by that particular business and its technical terms in order to make the best promotional style content. Also, a very simple and easy to understand language needs to be used in writing content for the sites so that even the lay man can easily get to know what the content is all about. The writer needs to think from the place of the reader and offer complete information.

Essentials of content writing – authenticity, organization and numbering.

Organization of content is also very crucial and includes proper designing and formatting of the information gathered from various sources. The writer can write an entire article in a single paragraph or can even make the content easy to read by arranging the headings. The relevancy of pointers needs to be properly handled so that the audiences can analyze distinction of paragraphs.

Numbering and bulleting needs to be used in the content to highlight the most important points. This will automatically make the article effective along with breaking the visual monotony.

It is wise to use the conversational language as it helps the readers to feel more involved in content thereby motivating them to continue reading the article.

In addition, the authenticity and originality of the content needs to be considered wisely because offering wrong or prejudiced information to readers can in turn provide negative or incomplete impact.

Needless to say, to be a successful and popular content writer, it is very imperative to have that passion and flair to write. Until the writer is extremely passionate about his or her job, they can produce only mundane and dull content. so, follow these simple and beneficial tips in order to write exceptional content for the targeted audiences.

About the Author

Visit sem-infotech.com for content writing services, ppc management and professional seo services.

Article source: http://www.articler.com/

Author: Brian Scott

If you have specialized knowledge other than how to be a great writer, then technical writing may be for you.

Technical writing combines your writing talent with a specific area of expertise, such as IT, graphic design, education, engineering, the automotive industry, etc. You could be writing for others who are already familiar with the field, or you could be writing to teach others.

How much does technical writing pay?

Technical writing freelancers often get paid very well, anywhere from $40 to $100 per hour or more. Technical writers command a higher rate of pay because it takes much more than polished writing skills to do the job.

Where can I find technical writing jobs?

The Internet is the ideal resource, especially if you’re just getting started. Check out websites like computerjobs.com, IFreelance.com, or rentacoder.com. These sites offer many postings by companies seeking freelance technical writers in a variety of industries.

I also recommend you post your resume on an employment site like CareerBuilder.com or Workopolis.com. Because you have a specialized skill set, know that there will be people actively looking for you. Having your resume on this type of website will greatly increase your chances of getting a well-paid technical writing gig.

Another technique is to do some brainstorming. Ask yourself if you have a specialized skill set or knowledge base. If so, what companies are in your area that could use a writer with skills like yours? Contact those businesses directly with your resume and a letter explaining how difficult it can be to find a good technical writer and that you’re available to help with any upcoming projects they may have.

What type of work will I be doing?

In IT, technical writers are often creating software or hardware manuals from scratch, or writing about coding. In the education field, you may be writing textbooks or creating PowerPoint slides for online learning programs. You could also be writing assembly manuals for machines, preparing reports for a pharmaceutical company, or creating do-it-yourself manuals for home repairs, etc.

In any technical writing job, you’ll need to have good writing and communication skills on top of your area of expertise. Technical writing projects are often collaborative, meaning you’ll have to deal with other people and complete the project as a team. Even if you’re working alone, your client will want to know how you’re progressing and whether you’re on track with what he or she is looking for. Expect lots of communication, either over the Internet or by phone.

How do I properly respond to an ad for a technical writer?

To maximize your chances of success, your response should include:

• A note about how valuable you feel the company is
• A summary of your qualifications in the field of expertise
• An overview of your superior writing ability
• Any related experience you may have

This response could be in a cover letter accompanying your resume or in your bid on a freelancing website. Read the sample ad below to see if you could make a compelling candidate:

We are an online learning company specializing in business skills. We teach administrators, HR people, etc. to effectively coach employees and streamline day-to-day business. We design online courses and downloadable presentations. We need a writer to help us with our upcoming courses for next year.

In order to make maximum impact, your response needs to hit each of the four points above. For example, you might respond like so:

Dear Sir/Madam,

I’ve taken a look at your website and I must say that your material is very impressive! It’s clear that you provide a lot of value to the businesses that use your services, and I would welcome the opportunity to join your team.

I hold a Bachelor of Commerce with a Human Resources designation. Throughout my education I designed various studies of employee behavior. Recently, I’ve been working as a consultant helping companies optimize employee productivity. I believe my skills may be of benefit to your company.

In addition, I am an accomplished writer. I have written articles, reports, and web content. My clients are always pleased with my work because it is grammatically flawless, concise, and easily accessible to readers.

Thank you for considering me for this position.

Sincerely, (name)

That’s it! Just remember that you have a unique combination of highly sought-after skills, and you’ll have your first technical writing job in no time.

About the Author:
Brian Scott is a full-time freelance writer with over a decade of experience. He finds many of his paid freelance technical writing jobs at Online Writing Jobs ( http://www.online-writing-jobs.com ), a free jobboard that lets you search thousands of freelance writing jobs.

Article Source: ArticlesBase.com – All About Freelance Technical Writing Jobs

Author: Tom Aaron

Writing is an art that demands writers master many different skills. Editing writing, correcting grammar, and using rich punctuation are some of these skills. Punctuation may be the least respected skill. Were Rodney Dangerfield to write of punctuation, he might say, “Punctuation is like me. It don’t get no respect.” When we think of punctuation, we may only think of punctuation marks, but punctuation is much more. Anything used in written language that is not a letter or number is punctuation. This means punctuation marks, spaces between words, and indentation are all part of punctuation. If we turn to Wikipedia, we can find a definition of punctuation. Wikipedia says, “Punctuation marks are symbols that correspond to neither phonemes (sounds) of a language nor to lexemes (words and phrases), but which serve to indicate the structure and organization of writing, as well as intonation and pauses to be observed when reading it aloud.”

We enrich our punctuation the same way we improve our writing. The above paragraph is the first version of a rough draft. Let’s edit it and see how we can improve the punctuation.

The art of writing demands writers master many different skills including editing, correcting grammar, and enriching punctuation. Punctuation may be the least respected skill. Were Rodney Dangerfield to write of punctuation, he might say: “Punctuation is like me. It don’t get no respect.” Punctuation goes beyond punctuation marks; anything in written language outside of letters and numbers is punctuation.

Punctuation marks, spaces between words, and indentation are all punctuation. Wikipedia defines punctuation: “Punctuation marks are symbols that correspond to neither phonemes (sounds) of a language nor to lexemes (words and phrases), but which serve to indicate the structure and organization of writing, as well as intonation and pauses to be observed when reading it aloud.”

Let’s look at two differences between the first and second versions.

1. The number of paragraphs

The first version had one long paragraph, which became two paragraphs in the second version. Paragraphing is part of punctuation. A paragraph can be as short as one sentence or as long as several pages. A one-sentence paragraph, however, is unusual outside dialogue. Longer paragraphs are hard on readers. Breaking a long paragraph into two or more smaller paragraphs makes reading easier.

2. Variety in punctuation marks

The first version used only periods and commas; the second version added colons and semicolons. Punctuational variety enriches the writing. Many people use an extremely limited repertoire of punctuation marks: periods and commas. Use variety in punctuation marks to differentiate your writing from everyday writing without this rich variety.

We would also like to show additional ways to use punctuation:

1. Colons can emphasize contrast.

We waited all day for Godot to show up: He never arrived.

2. Ellipsis emphasize that there is more.

We ate apple bars with whipped cream, lemon bars with nuts, marshmallow bars, meltaway chocolate bars….

Improving your punctuation is fairly easy; remember the colon and the semicolon. When you read, notice the punctuation. See how you can add ellipsis, exclamation points, dashes, and more. Observe, learn and improve your writing.

Still, we don’t want you to overwhelm your readers with punctuation. Thinking of punctuation as a piece of chocolate cake might help. One piece of chocolate cake may taste like heaven; two pieces may just be too much heaven. Using exclamation points, dashes, and ellipses too often may overwhelm your readers and begin to interfere with their reading of your writing.

About the Author:

This article is from Aaron Language Services at
http://www.aaronlanguage.com/
We provide English writing services to a primarily Japanese clientele. If you are an experienced editor, specializing in medicine or the hard sciences, please contact us via personnel on the menu on the left side of our top page.

Article Source: ArticlesBase.com – Enrich your punctuation and improve your writing

For the record, I work at Starbucks part-time to cover my bills and also to get out of my basement home office for a little while. I’ve learned a lot about coffee and people, but I’ve also learned a little more about language.

There are a number of conventions that Starbucks’ uses to ensure consistency from store to store. I’m going to discuss calling beverages (i.e., once made, the barista calls the drink for the customer to pick up) :

• Iced Double Tall Vanilla Non-fat Latte
• Grande Sugar-free Vanilla Caramel Macchiato
• Venti Non-fat One Splenda Dry Cappuccino
• Tall Caramel No Whip White Mocha

I may be revealing some corporate secrets here and Starbucks will perhaps ask me to cease-and-desist, but there is a consistent order for calling beverages:

1. Number of beverages (e.g., customer ordered two of the same drink)
2. Type of cup (e.g., personal; hot or cold)
3. Decaffeinated
4. Shot quantity (i.e., the number of espresso shots)
5. Size (i.e., Short, Tall, Grande, Venti)
6. Flavouring
7. Milk
8. Customization
9. Beverage name

There are default options to each of the nine items that the barista doesn’t need to call, making the calling significantly easier. However, there also beverage names and brand names that need to be called that duplicate other items being called:

• Iced Tall Iced Coffee
• Grande Coffee Frappuccino Blended Coffee
• Venti Chai Crème Frappuccino Blended Crème

I happened to pop over to the McDonalds for a quick snack while working last night and came to an interesting realization about my double cheeseburger: at Starbucks it would probably need to be a double cheese double burger. The bacon double cheeseburger would be a double cheese with bacon double burger. A quarter pounder with cheese with no pickles would be a cheese no pickle quarter pounder.

One would hope that reason would be a factor in calling beverages, reducing the redundancy:

• Tall Iced Coffee
• Grande Blended Coffee Frappuccino
• Venti Chai Blended Crème Frappuccino

Just my opinion. Thanks for listening.

Image © Serghei Starus | Dreamstime.com