by Virginia Janzig 

I attended the STC Summit for the first time in about 10 years. In addition to being a presenter in the Editing Progression, I attended many of the sessions that were offered, and spent worthwhile time in the vendor showcase, especially the bookstore.

Three things stand out to me.

First, the organizers had clearly paid attention to the comments received about prior conferences. The conference was more focused on writing and editing, and much less on tools. And the variety of different kinds of writing topics was tremendous: everything from processes and procedures and structured language to highly technical online documentation.

Having recently taken a job in a courseware development group, an area about which I know very little, I was pleased to find more than one session on instructional design. The two I attended were quite helpful.

The editing progression had several presenters on a wide range of topics, and it was well attended. A couple of other sessions on language were also well attended and useful, as well as entertaining. And our language is nothing if not entertaining.

Second, several sessions on various topics provided information for both beginning and advanced writers. Assessing an audience and its needs is always a challenging task, but I think that the organizers and presenters did an excellent job of delivering to both ends of the spectrum.

Third, I was especially glad to see sessions on careers, not only what kinds of careers are available in the technical documentation arena, but also how to progress in a career: what opportunities to look for, how to build skills, and how to present yourself (not just your resume) in a professional and business-like manner.

The Minneapolis Convention Center was a great venue, and the city had a lot to offer. There were plenty of rooms for all of the sessions (although a few of the most popular were standing room only), and the vendor showcase area had refreshments and Internet access. The incredible walkways made it really easy to get from hotels to the convention center and to lots of other businesses.

In closing, I was pleased to see how many young people attended the conference. Clearly, technical documentation is perceived as a legitimate career and career path, and, if we can help persuade the U.S. Department of Labor to update its definition of this job, then I think that the STC and technical documentation as a whole will benefit, and the technical community will be well served.

by Meredith Kinder

From May 14 – 16, 2007, I attended the 54^th Annual Conference of the STC (Society of Technical Communication) in Minneapolis, Minnesota. At the Lone Writer SIG (Special Interest Group) progression session titled “Out of the Solitudes: Progressions of STC’s Lone Writer Community,” Jerry Franklin led a discussion on the essentials of self-editing documentation. The following is the checklist he suggests using when self-editing.

Put distance between you and the document. If you have a long deadline, take a day or two without looking at it. If you have a short deadline, take 30 minutes away from it where you don’t look at it or think about it. Watch the Sopranos, swim the English Channel, or work on another project: just put it down for an extended amount of time.

Take on the genre of Mr./Ms. Proofreader. Remove yourself physically to play this role: if you write in an office, take it home. If you write at home, take it to a coffee shop. If you write on screen, print it out, and vice versa. You’re more likely to see errors if you reposition the way you see the text. Furthermore, when proofreading:

• On the first pass, read slowly for cohesiveness.
• On the second pass, proof for formatting.
• On the third pass, read it out loud. Agonize over it. This phase is time-consuming, but absorbing it will increase your changes of finding a typo and errors.

Use a style guide. For best results, use both yours and an industry-style guide or other type of published ones (such as MicroSoft, Chicago, etc.). When you use a style guide, you don’t have to make decisions while editing—they have already been made for you. A style guide saves you time in the end.

Rely on other sources. Look at what industry leaders are doing. If you are in software, look at what Oracle is doing. If you are a small shop, make your documents look like the big guys.

Have non-SMEs (Subject Matter Experts) review your document. Others in your company can give a different perspective from someone who is not down in the details. Since non-SMEs should probably not be a techies, they’re likely to approach it from an editorial standpoint. Even if not all of their feedback is useful, they will find some good nuggets for you. So how do you persuade  non-SMEs to help you out? Have a document review day/morning with cookies and colored pens and bring in hard-copy documentation. Let them read and mark it up.

Take advantage of free or cheap assistance. Students are hungry for real world experience, and will do good work for $15/.hr. Editing or proofreading gives them experience and items to put on their resume. This approach will require managing and a small time commitment, but it could be worth it in the end.

My last plea and request for assistance worked so well (audio editing expertise materialized), I thought I’d try again!

We are really enjoying our new blog, which is presented with WordPress, but we would like to play around with the look and feel of the site and the blog.  This requires some CSS experience, or at least comfort with working with CSS in the WordPress environment.

This task might be as simple as finding the appropriate existing theme within WordPress for us to use, it might be as simple as tweaking the theme that we are using now, or it might be completely revamping and designing our own theme that we want.

Please contact me at corbinm@us.ibm.com if you are interested in helping us improve the look and feel of our WordPress-based Web site and blog.

a general impression of a journal article
by Michelle Corbin

I recently re-read the journal article “The Technical Editor as Diplomat:  Linguistic Strategies for Balancing Clarity and Politeness” by Mackiewicz and Riley (Technical Communication, Volume 50, Number 1, February 2003, pp. 83-94).  This article discusses 8 different strategies, based on linguistics research, for balancing clarity and politeness when making editing comments, in the hopes of building and enhancing the author-editor relationship.  Although I do not agree with all of the strategies and conclusions that the authors make, I did find it a fascinating article – one that made me actually think about and try to articulate my own thoughts on the role that politeness plays when I make my editing comments. 

Although this is not a recently published article, I thought it might be nice to use it to kick off this new type of newsletter article in the Technical Editing SIG blog/newsletter.  We receive so much information that it is difficult to know what to take the time to read, and the SIG is trying to help you make a decision as to whether to read an article or not – we want to entice and encourage you to read these articles (and who knows, maybe join a conversation about them on the blog or in our discussion list!). 

Do you remember reading this article?  Did this entice you into reading it (or re-reading it)?  Do you have some thoughts about this article?  Please consider sharing them on our blog or as part of our discussion list (I decided to cross-post this to both places, in hopes of encouraging cross-reading/cross-participation in our blog and discussion lists.  ). 

By Pat Moell, co-manager, Technical Editing SIG

I enjoyed meeting so many of you at the STC Conference in Minneapolis in May. We have such an enthusiastic group of editors in the Technical Editing SIG. Thanks to all of you who helped make our SIG presence at the conference a success, and thanks to those of you who signed up for volunteer duties beyond the conference.

I noticed several trends at the conference, a couple of them seemingly in contradiction with each other. One trend is that we have become a Google-centric global community in which quality is determined by the relevance and timeliness of the information rather than by the quality of the writing. In our wiki environment where many can contribute to the content, misspelled words and poor grammar are more easily tolerated as long as the information is accurate and meets the user’s immediate needs.

Almost directly opposite of that trend and meeting a different need is the trend toward tightly controlled English, toward defined terms that each have one meaning. The push for this controlled English is the cost of translation. As more companies become global, they take seriously the need to reduce the proliferation of words in a document. One speaker said that we really only need to use about 500 words in our vocabulary to get most points across. He predicted intriguingly that if we used these 500 words consistently, eventually we would not need to do translations. The world would learn these 500 English words, and we’d have them in common as a global community.

Another trend is the convergence of authoring and translation. The May 2007 issue of Intercom has an article on this subject: “Closing the Content Gap: Converging Authoring and Translation.” There were several presentations at the conference on ways of unifying the authoring, editing, and deployment of multilingual content. Pierre Cadieux had a stimulating presentation with graphics that showed the workflow of an integrated authoring and translation system. Such visuals can help organizations determine where their own multilingual processes and content management systems are lacking.

Related to this trend is the trend toward globalizing graphics. HP, for example, has worked hard in this area to make sure that its graphics are understood everywhere and are not offensive anywhere. Sometimes, it’s true, a picture is worth a thousand words and can save a lot in translation costs. At other times, unless the graphic is going to serve a useful, nonredundant purpose, words are better. Show the task and not the object.

Yet another trend is the technical communicator’s increasing involvement in helping create user interfaces instead of just describing them. User assistance and user interfaces are converging. One goal is to reduce the need for documentation.

I felt that the quality of presentations was very high this year. Every session that I attended was worthwhile and informative. And our Technical Editing progression was also enlightening. I particularly enjoyed the discussion of the editor as information architect.

See you in Philadelphia next year!

by Michelle Corbin, co-manager 

Hello SIG members!  It’s been a week since I returned home from the Technical Communication Summit, and I have recovered from the time away from the office and I wanted to share a few tidbits from the conference.

We attended leadership day on Sunday, and gathered invaluable information that will help us plan our next set of activities.  I learned a great definition of leadership from incoming president, Linda Oestreich:  “Leadership is the ability to cause others to act in desired ways for the benefit of the organization.”  Ultimately, each community leader was encouraged to determine what we wanted to do from year to year, and then just go do it;  that is, don’t do everything and don’t do what you think you “should” do, but just do what your members want you to do and do what your volunteers sign up to do.  So, Technical Editing SIG members, what do you want us to do? 

We had a very interesting keynote speaker, Simon Singh, who spoke about the making of his documentary about a mathematician solving the proof for an age-old mathematical equation. Although the specifics and details about that mathematical equation did not stick, I did take away two things from listening to his experiences – first, when choosing to edit something, you must consider the audience and context and make sure that it is right, and second, the technical accuracy of your content is critical as you run the risk of losing your audience’s trust.

A very popular session this year (as in past years) was “The Myths and Trends in the Changing English Language.”They talked through several common issues, such as ending a sentence with a preposition, use of the serial comma, and passive voice.  As a fellow “word nerd,” this session was a light-hearted treat, where I got to learn what “snarky” meant.  My one golden nugget from this session was to be reminded that “goodwill is more important than being right.”  As editors, we sometimes need the goodwill more than the rightness of a rule or guideline.

The Technical Editing SIG had its own session of progression table topics — all about editing!  Many thanks to our moderator, Diane Feldman, who helped coordinate these topics with the help of you, our SIG members!  Each table was full each time, and everyone seemed to really engage in the conversations.  Perhaps each presenter might consider summarizing their session in an article for our blog and newsletter! 

The closing keynote speaker (yes, we got two keynotes this year) was Ze Frank, who told two great stories about the designs of airline safety cards and about “accelerated anxiety” and the changing landscape of how everyone wants to join the media conversation – the explosion of blogs, MySpace, YouTube, etc.  He is a designer at heart, but an excellent communicator through his designs.  I laughed out loud frequently and left the conference with a smile on my face.

Although I attended other technical sessions, which I might try to summarize in other posts or articles, I wanted to highlight these above from my experience at the conference.   Did you attend the conference?  What was your favorite session?  Please consider sharing your experiences with our other SIG members!

Tom Johnson is the author and creator of the Tech Writer Voices podcasts, available at http://www.techwritervoices.com.  His most recent contributions are interviews of people at the STC Conference in Minneapolis, which are 5-10 minutes in length.  Other podcasts are longer, but almost always quite interesting. You can download them, play them directly on the site, or subscribe to the feed.

By Justin Baker, Senior Member

Reprinted from “Capital Letter,” the newsletter of the Washington, D.C. chapter of STC, by permission of author and editor.

What’s in a name? A lot. As technical editors, we know the importance of ensuring that the text we edit is clear. If we are performing developmental editing or copy (language) editing, we know that concepts must be expressed in such a way that the reader does not have to stop and figure out what is being said. We know that the more times a reader has to stop in a text to figure something out, the less the chance that the reader will leave the text with a solid understanding.

There are many elements to look for when editing a text at the development level or language level. One of these elements is terminology. The precise use of terminology is important. The more precise the terms, the more economical and efficient the text (Strunk and White, anyone?). The precise use of terms keeps text uncluttered and makes language more interesting to read and, in some cases, more valuable: the precise use of terms can make a text pregnant with meaning.

All of this, of course, applies to technical terms as well. Sometimes technical terms are misused. Other times a concept or model outgrows the original terms that were used to describe it. This is the case with the terms paper-based documentation and online documentation. These terms have been established in the technical-communication lexicon for years. The logic of their meaning was clear at the time that they emerged in the 1980s and early 90s: in addition to the centuries-old paper document, we also now had documentation on a computer (online). But these terms came into existence before the World Wide Web became dominant and hypertext became the norm for online documents, therefore eschewing the traditional linear, narrative structure.

In the days when text-based interfaces still existed, online documentation was much like paper-based documentation: it had a linear, narrative structure with traditional cross-references that did not lead a reader off on an entirely different path from the original text. At the time, it made sense to use the terms paper-based documentation and online documentation, because the only difference between the two was in their output: one was on paper, and the other was on a computer.

In the 1990s, the World Wide Web became a huge presence in the world of documentation. Because of hyperlinks, the term online documentation began to primarily mean a document that was not necessarily read in linear fashion. The term began to refer to the structure of a document, rather than the medium in which it was published. But the newer, predominant definition of online documentation conflicted with the older definition, which still existed.

These conflicting definitions have opened up a can of worms. Is it online documentation only if it has a hyperlinked structure? Is it online documentation if it is a document designed for print but posted to a Web site as a PDF document? Then there’s the quandary of whether a Web site that is printed out on paper is paper-based documentation or still online documentation.

From this confusion emerges the idea that perhaps it is not best to define a document by its published form. Perhaps it would be better to define a document by its structure—linear documentation or Web-based documentation. If you publish a traditional report on paper or post it to a Web site as a PDF document, it still has a linear structure. Even if you print an HTML document published on a Web site, that document still has a Web structure with hyperlinks, and the author’s intention is that readers will carve out their own narrative (logical) path. One could argue that the Web-based structure of the document is no longer present once it has been printed on paper, since you can’t click a hyperlink on a piece of paper. This is why I have included the author’s intention as part of the definition; if the author intends for readers to carve out their own narrative path, then the document still possesses a Web-based structure. And I argue that this contrasts with a traditional text that has many footnotes. The author of such a text intends for the reader to read in a primarily linear fashion, even if that reader skips ahead to other chapters. The text is still linear.

As technical editors and as members of a technical communication society, we may never be able to turn the tide of usage in the general business community. However, we should strive to use the most accurate terminology, at least within our own profession and communities. Electrical engineers strive to use the most precise terms in their field because it makes their communication more efficient. As technical editors and communicators, we must ensure that such precise language is used in all disciplines in which our work is based.

It is time to change the terms used to describe the different models of documentation. No more paper-based and online. It’s time for linear documentation and Web-based documentation. We as technical editors with our proverbial red pens have the power to help steer this change.

Justin Baker has been a technical writer and editor for nine years. You can reach him at bakerjustin@earthlink.net.

The Executive Director of STC sent out a survey late last week, asking for your input and feedback about the STC publications — the journal (Technical Communication), the magazine (Intercom), and other communications.  Please take a few moments to complete this survey!

Attached below is the e-mail announcement from STC:

*************************

The STC Board of Directors wants your input for its meeting on May 11th and 12th. Please take a moment to answer the questions at http://www.stc.org/stcmembers/surveys/pubsSurvey01.asp.

As you may recall, the Board has adopted a new information gathering process called Knowledge-Based Governance. Just before a Board meeting, the Board asks STC members questions that are related to topics that will be discussed during the Board meeting. For the upcoming meeting, the Board will begin discussing possible changes to the publications options offered as part of membership in STC. Please share your thoughts with the Board by participating in the survey.

The Board will use the survey results to prepare for discussions and decisions. This practice reflects a belief that a well-informed decision-making process, including significant input from Society members, is critical for a successful organization.

To make sure your voice is heard, we need your input by 12:00 Midnight (EDT) Tuesday, May 8, 2007. This will enable us to compile and consider STC members’ responses in time for the meeting.

We look forward to receiving your input. Thank you.
Susan Burton, CAE
Executive Director
Society for Technical Communication
susan@stc.org
STC fosters industry-leading technical communication by stimulating information exchange, cultivating educational programs, recognizing outstanding contributions, partnering with other organizations, funding research, and promoting the profession.

Hi everyone.  The SIG is slowly but surely venturing into the brave new world of technologies, and has run into a few snags along the way.  We have this great new blog-driven Web site and Newsletter, and we have started holding quarterly membership meetings, with an audio recording of those meetings.

Unfortunately, we have run into some technical difficulties with our audio recording.  We received a WAV file, which is over 60 MB in size, and are having difficulties posting it to our Web site.  Additionally, it would be really nice to cut out the up-front welcome, introductions, and ramblings and just focus on the really interesting part of the technical program. 

Doubly unfortunately, I have zero experience at working with audio recordings.  I knew to request one, and I have it, but I am stuck with how to best edit, manage, and deliver it to you our members.  So, I am sending up a flare, calling all audio gurus to step forward and help us get past these technical difficulties and provide the audio recording of our April 2007 membership meeting to all of our members.

Any takers?