On Outlining.

I found an article on outlining[1] that promises I will write faster if I outline more completely.

The author thinks of her outlines as a series of questions that she will answer in her article.

I'm used to outlining when I already have the answers I need.

The idea is that if these two things are combined, you'll have a complete outline.

I could see this being especially helpful when planning for an SME (subject matter expert) interview. If your outline for the interview contained both the questions you wanted answered, and some example answers to goad your SME into correcting you, you'd probably get really good results.

Planning your documentation in terms of the questions your users might have is also a good idea.

The article makes good use of whitespace.

[1] http://www.onespoonatatime.com/how-to-save-tons-of-writing-time-by-using-a-complete-outline

Serial comma

On the same vein as Tim's post, the serial comma is something of a problem. I have been taught (in the past and fairly recently), that the serial comma comes into effect only when more than two options are described. That is, if I write "Select a or b" or "Select a and b" the comma is not required.

However, the comma is required when either more than two options are available, or one of the options has two options. That is, you can have "Select a, b, or c" or "Select a or b, c, or d" or "Select a, b or c, and d" and all the other possible variations.

But now I am being told that I must have a comma at all times to ensure that there is no confusion. So, I find myself continously having to correct what I write to introduce that extra comma "You can select a, or b".

Personally, I do not agree with this option. Thoughts?

That or which?

That or which?

I'm working on fixing up some documentation for a release. I came across this:

"Before you begin, the export domain must be attached to the data center which contains the virtual machine to be exported."

I thought "which" looked awkward, but wanted to double check. I found this resource:

Using which and that correctly

Which says:
"Use which (surrounded by commas) if a group of words adds information. Use that if it limits the set of things you're talking about"

Seems simple enough. But not so fast.

My colleague informs me that this approach to "that and which" was popularized by Strunk and White in the 1920's. Before then, the words weren't used consistently as restrictive(that) and non-restrictive(which) clauses.

He didn't have a counter example, and I am happy to accept a simplified approach on this issue. In my edit, I substituted "that" for "which", and went to get a soda.

If someone reads this, and thinks of an example where this guideline doesn't work, please comment.

Did You Know: "Free Archived Seminars"

When I was poking around in the STC.org website this week I stumbled across an area that I know about, but often forget about--the "Free Archived Seminars". This is an area of the site that provides some really decent high-quality content seminars. This week I randomly selected a seminar to view called "Collaborating Around the World" and was surprised to discover that the presenter is an Australian living in the USA. Her presentation was really delightful and I found her content to be on-target and insightful. If you haven't checked out this section of the STC website I would suggest you take a few minutes and give it a try. Here are some of the topics covered just in this single presentation:

Mincom

Our team environment

Dealing with time zones

Dealing with cultures

Australian and US cultural differences

Creating a team culture

etc.

I can't wait to find the time to see what other content is available for me to learn from in this section of the STC.org website.

STC Presents :: Create Meaningful Online Experiences

The descriptive blurb says, "What makes one website memorable and another wholly forgettable? What drives you to return to a site repeatedly? The answers are often surprising and decidedly low-tech. This webinar will examine the concepts and intentions driving several compelling online experiences with a focus on uncovering ideas worth putting to work at your organization. You'll gain an understanding of elements that create meaning, an awareness of existing ideas and approaches worth stealing, and a knowledge of success measurement to apply to your own efforts." 6:00-7:00 AM Friday, 17 August, GMT+10.

This seminar is available to STC members for $59 (USD) so if you're interested, be sure and visit the STC Website to register.

Although I know nothing about this presenter, Patrick DiMichele, the list of "Honors and Awards" on his LinkedIn page makes me think he might have something valuable to share. If you decide to sit in on this session we hope you'll give us a report on it in one of our later Chapter meetings!