2005 Summer Writer’s Conferences: Chenango Valley Writers’ Conference

Chenango Valley Writers’ Conference

When:
June 19 – 25, 2005

Where:
Colgate University is located in Hamilton, New York. The campus is a nationally known jewel of intellectual achievement and physical beauty. Central New York State is James Fenimore Cooper country, canal country and antiques country.

What:
Bring a story, a book in progress, some poems or a novel, and work with us on developing narrative strategies, verse techniques and methods of research. Members of the publishing profession will be here to discuss marketplace tactics.

Who:

Instructors:
Jennifer Brice
Kelly Cherry
Justin Cronin
Karen Novak
Bruce Smith
David Thoreen

Guest Readers:
Peter Balakian
Rick Reiken

Conference Director:
Matthew Leone

Web:
http://people.colgate.edu/cvwritersconference/

About.com Veteran is Starting a New Site

I have never been a big fan of About.com. While they have some very useful information, I have a problem with any site that tries to keep users on their pages, even when they click a link to another site.

The one great thing About.com had going for it was Anne Wayman and her section on Freelance Writing. Anne always gave solid advice and she constantly kept people updated on new freelance opportunities. Well, Anne and About.com have, to put it nicely, parted ways. About.com probably doesn’t know what they’ve lost, but I do. Anne was a great resource.

The good news is that Anne has left About.com, but she hasn’t left the Internet. She is already on the job, posting new writing opportunities. Check out her new site, the aptly named aboutfreelancewriting.com.

Document Hack (A Technical Writer’s Journal): Life without Editors

Technical editors are great. Technical editors point out problems and they identify mistakes. A good technical editor can make almost any document better. They provide a key component of the document review cycle and ensure that document quality is maintained.

Some editors are little more than proofreaders. They look for spelling errors, grammar errors and typographical errors; they rarely spot larger problems. Other editors take a more structural approach. Comprehensive editors look at the overall document and try to find any way in which it can be improved. They determine if the data is accurate and the instructions are complete. They look for better ways to deliver the information. For example, they decide whether one piece of information should precede another or if a graphic is needed to make the information clearer. There are all sorts of editors with various levels of skills and differing styles. You should take advantage of any editor and cherish a truly talented one.

Unfortunately, you may not always have a good technical editor (or even a good proofreader) available. Many companies that know they need technical writers don’t know that they need technical editors, or they simply don’t want to bother with the expense. At about half of my contracts, there has been no editor and no review process. At some companies, I was able to find other writers to look at my documentation. At other companies, I had to resort to using whoever was available and seemed to have a grasp of the English language.

Every technical writer needs an editor or at least a proofreader to review their work. No matter how strong your writing and grammar skills are, there will be room for improvement. Even if there isn’t, it is good to have someone there to confirm it. Writers have blind spots. When writers edit their own work, they often miss errors because they hear the narrative in their head rather than see the actual writing on the page. An editor with a fresh set of eyes doesn’t have that problem. They aren’t focused on what you think you wrote, but rather on what you actually put on the page.

If you are in the position of working without a technical editor, here are some steps you can take to reduce documentation errors:

• Create an informal editing team. Pick the people who are most likely to have good writing/editing skills and get them to look at your documents. Don’t waste their time, however, only use them once you have polished the document and you are confident that you have removed all the errors you can find.
• Increase your proofreading skills. A great guide to document editing is Line by Line – How to Edit Your Own Writing by Claire Kehrwald Cook. It is a guide to both proofreading and document analysis.
• Create an editorial/proofreading checklist to follow for every document. Include separate checks for grammar, spelling, punctuation, fact-checking, graphics review, and page layout.
• Create your own style guide. Keep an ongoing list of spellings, acronyms, abbreviations, capitalization and key definitions. Also include any sections of content that are frequently repeated, such as warnings and product descriptions. Make sure your usage is the same across each document and for all documents. For example, do you use e-mail or email? Some companies provide you with a style guide. If your company does, use it, but also make it a starting-point for your personal style guide.
• Read your document backwards. Start with the last sentence and work your way to the first.
• When possible, let a document sit for a day or longer between the writing process and the editing process. The longer you wait, the fresher your perspective will be when you start the editing process.

Document Hack (A Technical Writer’s Journal): Marketing and the Technical Writer

At this point in my career, I have contracted for many different companies, both large and small. Only one of those companies had their technical writers work closely with the marketing team. At most jobs, I never met the marketing team. This is unfortunate, because a well-written technical document should be considered to be a marketing tool as much as an informational tool.

At the company that did coordinate marketing and technical documentation, the teams worked side by side. They were literally seated within a few feet of each other. The work environment at this company didn’t have separate cubicles, but rather cubicles that contained entire groups. This created its own problems, but from a team-orientation approach, it kept people working together whether they liked it or not.

This company provided phone and Internet chat support for thousands of customers. It had several call centers, and probably employed more people for support than for any other segment of the company. Because of this, they paid close attention to what people called about, and they acted quickly to put solutions to problems on the web-site as quickly as possible. The company actively tracked the number of calls on every subject. This was a remarkable thing to me as a technical writer. At most companies, I rarely got any feedback from the customers about my efforts. At this company, I often knew within an hour whether or not my work had yielded positive results.

The department I worked in maintained two separate web-based help systems. One was a help system for technical problems and the other was a help system for purchasing/sales related problems. The second area was under the control of the marketing department, but I wrote the copy for both help systems. Occasionally, there were arguments over what could be said on either site, because, from a marketing point of view there were certain things they were willing to admit were problems and other things they tried to pass off as “features”.

The marketing department hated to admit anything was actually wrong with the product, even when the problem was clear. Because of this, I sometimes had to put my creative writing skills to work more than my technical skills. While this could make assignments difficult, the choice itself was intelligent. Any documentation created for a company and read by customers or press should be considered a marketing and public relations document, no matter what the primary purpose of the document is. Bad documentation can drive customers to other products, a fact that far too few companies recognize.

As I’ve said, however, this company’s coordination between marketing and documentation was an exception. It recognized the value of technical documentation AND it understood the marketing component of technical documentation. A few other companies I have contracted for took the time to introduce me to marketing, but I never worked directly with them. At many of my contracts I didn’t meet the people in marketing at all. This became a major issue at one company, when a product I spent a year working on was scrapped because marketing (once they were involved) determined that there wasn’t a sufficient market to justify trying to sell the product. Had the marketing department been a part of product development from the beginning, they would either have figured out a way to make the business model work or (more likely) the project would have been scrapped much earlier.

Generally, lack of communication between marketing and documentation doesn’t have such severe ramifications, but the case for communication is clear. Good communications with marketing can help with the following:

• Setting project goals
• Coordinating document presentation and writing style
• Identifying concerns on either side
• Identifying marketing opportunities
• Tracking product satisfaction

Try to meet the people in marketing whenever possible, and do your best to get their input on projects. Try to get your hands on the marketing materials for your product and determine how you can best match your documentation style to their marketing style without compromising quality on your side. When company politics allow for it, try to bring documentation and marketing together on projects.

If you are a contractor, many of these issues will be out of your control. Contractors rarely get the opportunity to set policy. You should still try to forge connections whenever possible. The primary goal for a technical writer should be creating quality documentation. Working with marketing is one way to help achieve that goal.

Next Page »