Words that aren’t words

Missed yesterday, sorry about that. I was trying to resolve a web development issue and was woefully unsuccessful.

Today’s topic relates to the way we (a global we as people) like to create new words to serve a new purpose. However, we also tend to create or commandeer words just to be different. For example:

  • incentivize — (v.) to add incentive to an activity; or motivate
  • ask — (n.) a request or a question; or request

I suppose, if it was incentivized, I would have searched for more words to complete the ask. But I didn’t. You get the point.

Unfortunately, because the English language is descriptive, as opposed to prescriptive (like French), we end up getting all kinds of new words and new usage based on conventional usage. So just by using the language differently (regardless of whether it’s necessary), we create new rules.

While I think that there should be a definitive resource for English language, I’m not going to expound that notion here; mostly because I think I’m in an incredibly small minority. What I will expound is the need for professional writers to adhere to some strict guidelines for language.

I believe a large part of the problem comes from text and online instant messaging, as well as email. Many people feel that these are shorthand communication media and don’t require the same adherence to proper language. The result is that this language usage migrates (quickly) to other forms of communication. (I actually heard someone use LOL while speaking with a friend!)

If we, as professional writers, make a habit of writing proper emails, and responding properly to poorly written emails, I think we’ll make some strides into correcting behaviour.

As well, when others start making up words, or using others’ made-up words, don’t use them. Find a reasonable alternative and stick with it. Double-check your spelling and grammar against specific resources (i.e., select a dictionary, usage guide and style manual and use only those). And use them all the time, whenever you write anything; not just when writing communication or documentation.

When using word-processing software, always use the spell-checker, but proofread as well. All too often mangers are responsible for supervision, and information is released to pubic audiences.

If anything, all this shows your dedication to your profession and should generally make it easier for you to edit your own work. Hopefully, it will push people to use their made-up words less often, and eventually not at all.

If you have any good made-up words, let me know!

Audience analysis

When a technical writer prepares to update or write new documentation, an audience analysis is probably one of the first things he does. Unfortunately, it involves a lot of guesswork. Does he want to interview users and get answers to his questions?

  • What does the audience already know?
  • What does the audience want to know?

Or can he proceed based on a few educated guesses?

What does the audience already know?

Really, does a user even know what he knows? How many interviews is a technical writer prepared to conduct to extract sufficient information from the audience?

What the technical writer is probably going to find out  is that some users are experts, some are novices and the rest are somewhere in between. So, how to write for the novice without condescending to the expert?

The easiest solution is simply to write for those in between: assume the user has seen the process and (a) either needs a short refresher or (b) will follow the documentation while performing the procedure. In either case, the documentation can be exactly the same.

What about other types of communications? The same process applies: the novice will need to read the communication in its entirety and the expert will be able to skim it for the important ideas.

What does the audience want to know?

But what information actually ends up in the documentation or communication? In a standard software user guide, for example:

  • What does the software do?
  • How to install or uninstall it?
  • How to configure it?
  • When to use its myriad functions?
  • What to do about error or warning messages?
  • Who to contact for support?

Yes, generally all of these questions need to be answered all the time.

But because the expert will probably know the background information, and because the novice won’t need it immediately to perform a procedure, it can be included in an appendix, if necessary. As well, by writing task-based procedures, all the users can follow the procedures to perform a specific task. An index will lead the user to the appropriate procedure related to a specific function. And a glossary will assist novices with unfamiliar terminology.

The audience analysis becomes much simpler once the basic concepts of the document are determined: a reasonable knowledge of the average user is sufficient to begin the documentation process. This should already be available based on the project and the reason for it.

Here are few resources for audience analysis:

The first post

Welcome to The Technical Writer Blog! As this is the first post, there’s not much to say. I will be posting roughly everyday (hopefully more often!), and including information about technical writing, communication and documentation, including language and grammar.

I’ve run across some other blogs that talk about poor usage in everyday life:

They may not be the best, but they’re fun. I’m not sure why the poor apostrophe gets so much attention, nor, indeed, why it’s so hard to use.

I’ve added the above blogs to the blogroll, but I’ll try to make sure it [my adding to the blogroll, and I guess the blogroll itself] doesn’t get out of control.

WordPress Themes