Category: Processes

Posted on

Welcome to My World

Don W. Benesh

Background

My writing career developed from many years of writing training material (instructor guides, training schedules, handouts, etc.) after not being provided what I considered adequate material while working as a trainer. In addition to being a trainer, I spent some time as project manager, where I also wrote my own operating procedures, project plans, proposals, and business plans—for the same reason. By doing all this writing, I developed better than average skills as a writer, but only in support of my primary fields of interest—or so I thought.

During an interview about 10 years ago, the conversation migrated to training; when asked about the material I used, I mentioned I wrote my own—and I happened to have samples with me. The interviewer was more interested and impressed with my writing skills than my project management background. She suggested I look into technical writing opportunities and said she would be doing me a disservice hiring me as a project manager when I write “better than candidates coming into the office claiming to be a technical writer.” I thanked her, but had no idea what a technical writer was and didn’t want to appear uninformed by asking.

I searched “technical writing” on a few of the Internet job boards and discovered endless opportunities, but still had no idea what distinguished technical writing skills from all the writing I had done over the years. So I took a commercial technical writing course (about 150 hours) and became a Certified Technical Writer.

The course focused on technical writing best practices. By the end of the training, students developed a portfolio of help files, hardware and software user guides, and some Web development work. For me, the course wrapped up what I had been doing over the years into a neat package and a new career. WOW—I do that!

What I took away from the class was “best practices” for the work I had done previously, including parallel construction, consistency, and readability (not to mention the certificate and new portfolio). I was immediately hired as a trainer for a new company because I was also “a certified technical writer.” I had almost two years at that company as a senior trainer before the collapse of the dot-com boom forced layoffs.

New Career

With this background and experience I secured a new job where I was initially hired as a technical writer where I anticipated doing what might typically be expected of a technical writer—work with SMEs and write hardware, software, and network technical documents.

I was introduced around the office as the new technical writer (I discovered I was the only technical writer) and then given a completed manual. I was sent an e-mail with the soft copy of the manual and instructions to “sort of clean it up and fix anything that isn’t appropriate from a technical writer’s point of view.” When inquiring about a style guide, I was told (with a slight grin and chuckle), “that’s part of our problem, we don’t have one.” At the end of the first week, I had spent just over 30 hours on a manual of about 35 pages and figured that was all I could do. But my boss was extremely happy with the results. (Isn’t that all we really need to do … keep the boss happy?)

At the beginning of my second week I was given a stack (about 40 or so) of already written manuals and told to “clean them up.” Whoa, that’s a year’s worth of work! (Remember, I had just spent about 30 hours on one manual.) And “by the way, they are due in three weeks.” After about 200 hours they still needed work, but they were better. (Anyway, they were in on time—that was a hellish three weeks!)

By the third month I had more than 150 manuals cross my desk and accepted the fact that I would not be writing manuals, but editing—sometimes very substantially, when I had the time.

Over the next few months the company’s reputation for quality manuals grew—the client was most impressed—and senior management began to realize the need for the service I provided.

Building a Technical Publications Department

I believe my success as an editor was due to several factors: I was the only technical writer (nothing to discuss—what I said went); as a past project manager I was used to making decisions on the fly and moving on; and I started a technical writer’s tips bulletin.

From the manuals on my desk, I compiled a list of names (engineers/authors) and created a distribution list for my almost daily tips. Each tip addressed one topic with examples of what I have seen (incorrect) and what I want to see (correct). I also quoted sources—typically The Chicago Manual of Style, but also other references focused on technical writing, anything I could find to support what I wanted to see.

To encourage people to read these bulletins, I offered lunch to anyone who could find an error within the bulletin and regularly left an error to be discovered. I also have an odd sense of humor that I injected into the tips; such as, “Any questions? Yes, you in the back row … very good question!” then proceeding to provide an answer to my imaginary question. Judging by the comments I received, those on my distribution list enjoyed getting my tips and actually read them—and the manuals coming to my desk started improving.

After comments started coming back from our client about the improvement of our manuals, senior management began to take notice. I was asked what else could be done to improve the manuals. I suggested hiring a few more technical writers or sending all the authors to a technical writing course, or at least a workshop introducing them to technical writing best practices. A few days later I was asked if I could arrange such a workshop.

I contacted my technical writing mentor, who no longer taught the 20-week course but did provide on-site workshops—both a 1-day and 2-day outline. We contracted for a 2-day session and a few months later a 1-day session; we had about 12–16 people attend each workshop.

After the first year my boss was extremely impressed with my results, expressed with the comment: “Look at all you’ve done and you did it without stepping on any toes, or ticking anyone off. You are really well liked.”

Technical writers became an essential part of the project team. When the company secured two new projects, I was involved in hiring technical writers for the new projects. Later I recruited two temps for the project I was on; one was released after the 6-week contract, while the other was kept on permanently.

The first year I had one manager who pretty much left me to do what I knew needed to be done. After his promotion, I and the document controller (an administrative position responsible for distribution of all incoming and outgoing correspondence) were passed around to no fewer than six managers over the next 12–15 months. Finally, my last manager, upon leaving, recommended I take over the team I had pretty much created and virtually led—by this time, three technical writers and the document controller. The new project manager agreed and a new cost center was created—Technical Publications.

I stressed that documentation that goes to our client should get the same consideration as a four-color glossy sales brochure. I preached that there are two aspects to document quality: technical accuracy and literary presentation. While the engineers are responsible for technical accuracy, the technical publications team is responsible for literary presentation. Technical writers must keep in mind that our finished product is more than just a software or hardware specification; it represents and reflects the quality of the specifications.

After two years I finally had the time to actually write a manual (well, I was hired as a technical writer, wasn’t I?) and the original tech tip bulletins (about 75 tips) were compiled and became our style guide.

For almost six years, I have focused on setting a higher standard for our client documentation and the company in general. The first group of 40 manuals crossed my desk about 4 times, each time getting a little better. Comments from outside the office went from “great product, but lousy documentation” to “very impressive manuals…better than the other contractor” (an actual quote from one of our clients.)

Although I started out as a trainer and project manager, now I consider myself a technical writer/editor.

Posted on

Thoughts on Copyediting, Outsourcing, and the Technical Communication Profession

Russell Willerton

In July 2008, Business Week published an article by Nandini Lakshman called “Copyediting? Ship the Work Out to India(external link).” This article focuses on Mindworks Global Media, an Indian company that handles copyediting, layout, and reporting tasks for several American newspapers.

When Mindworks started, the company took on Indian clients. Over the past several years, however, the company has taken on more U.S. clients as readership of print publications has declined and cost-cutting efforts have increased.

Nandini writes that outsourcing work to India helps keep publications in business. She quotes Mindworks CEO Tony Joseph, who said editorial outsourcing “helps [publishers] improve efficiencies in editorial packaging and reallocate resources to reporting and writing.” Mindworks told Nandini that the company helps publications cut costs 35% to 40%.

I posted a query to STCTESIG-L on July 11—primarily out of curiosity—to ask if anyone was familiar with copyediting of technical publications being outsourced to India. (Clearly, such a question reflects the fact that I live and work in the U.S.) Virginia Janzig, Ben Jimenez, and Marie Highby cited examples of copyediting being done by or in tandem with employees in India. Gururaj B. S. and Sankara Rajanala pointed out that while many editors work for Indian companies, work done by Indian companies is not always outsourced work.

We know that native speakers of a language often reach a level of fluency in that language that can be difficult for others to achieve. Said Jennifer Collister, working in the U.S. for a company founded by Indians, “When I’m editing pieces of the proposals, I can tell just by the writing style who is a native English speaker and who isn’t. However, the non-native English speakers get their point across but are just making grammatical and sentence structure mistakes.”

I suspect that this not-quite-native fluency in English contributes to a reduced level of confidence many U.S.-based writers might have in work done by editors whose native language is not English. Janice Gelb’s comments reflect such sentiments: “The cost of hiring an inexperienced or less competent employee (and I hasten to add that I am not speaking specifically of employees in India) often appears to be less in strict monetary output but in fact does cost the employer in the long run. These costs are both in real dollars (cost of redoing unacceptable material, increased cost of translation, increased volume of support calls, and so on) and intangibles such as customer product satisfaction and perception of corporate concern with quality.”

However, a detailed post from Sankara Rajanala (affirmed on the list by Mike Boyd), provided a different view. I provide these excerpts.

“It is not true that non-native speakers can never do as well as native speakers, especially when it comes to writing and editing. Eminent examples of this are Joseph Conrad and Vladmir Nabakov. I am deliberately omitting Indian authors…. Recently, I was on a conference call with a lot of new ‘faces’ (new to me). The next day I was asking a friend who was also on the call (from a different location) who the American on the call was; he said everyone is an Indian: turns out, one was based in the U.S. for a long while and I mistook him for an American…. No one can defend outright ungrammatical use of English but there are a lot of Indianisms that make our use of English colorful (to be avoided in technical documents for sure) and the name of the game is accommodation….
Not so long ago American English itself was dubbed as Americanisms, until H. L. Mencken got into the act. Right now, there are many Indians who proudly say ‘we are like this only’. But on the job, we diligently follow the norms of whichever language (Am, Brit) we are supposed to be writing in.”

Don Cunningham, professor emeritus at Auburn University, wrote that recent trends in outsourcing reflect on the state of the technical communication as a whole. “If we do not market ourselves and our profession effectively we will likely lose a significant amount of work to those who are willing to work for less. And this is not totally a geographical/locational issue.”

Adrienne Maxie pointed out that jobs do not necessarily belong in any one country. She asks, “What if we changed the way we looked at ‘our jobs’? Technically, the jobs don’t belong to ‘us’; rather they belong to the employer who then contracts with us to provide a specific task in exchange for a monetary value. Since the jobs do not belong to us as writers, editors, etc., then the employer can contract with whomever he or she decides can provide the most output for the least amount of money.”

Ram Venkatraman’s comments (in excerpts here) reflect a similar view:

“The other day, while holidaying in a remote Indian town, I met three young Frenchmen. Two of them had just completed their engineering degrees and secured internship in an Indian company. The third young man is expecting to complete his degree in networking technologies sometime next year and took my business card and promised to get in touch with me when he is ready to take up an internship. This is what students in India did when they did not have opportunity in their homeland decades ago. That is what I did….Now, while I totally understand the concerns of folks whose jobs might migrate to other countries where cheaper labor is available, the big picture is a historical transformation that has been shaping up for centuries. Like the three Frenchmen, people may move to places where there are opportunities. Living and earning in India can provide the same lifestyle as earning and living in Germany. Millions of people around the globe do precisely do that. My family moved to study in US more than a decade ago. Then, one fine day we moved back to India because the opportunity was there. If the opportunity moves to Timbuktu, I will be packing the bags again.”

This discussion reminded me that technical communication is one of the many facets of the global economy, and that technical communication tasks can be done from any spot on the globe. Wherever we find ourselves, we must demonstrate and articulate the value we bring to our employers and their consumers. Standing still will ensure we get left behind.

Posted on

The Impact of XML on Technical Editing

Justin Baker

I remember hearing a lot of chatter at the beginning of this decade about something called XML. I remember hearing about the unknown implications for editors: Would the paradigm of structured documentation and single-sourcing models make editors all but obsolete? I saw myself in a museum behind thick glass. Because of this thing called XML, were we all doomed to go the way of the Gutenberg press?

Well, hardly.

I’ve learned a little about XML over the last seven years, and I feel a little more at ease. To understand XML’s impact on technical editing, let’s first look at a brief overview of the major editing phases of linear-based documentation. We will then examine the nature of XML before finally moving on to how XML affects technical editing.

Linear-based documentation (traditionally called paper-based documentation), has three major editing phases in my own mental editing model: (1) Knowledge Editing, (2) Language Editing, and (3) Layout Editing.

  • Knowledge Editing refers to the technical subject matter in a document both in verbal form (words) as well as in visual form (images). I divide Knowledge Editing into four sublevels: Knowledge Accuracy, Knowledge Completeness, Knowledge Logic, and Knowledge Hierarchy. The first two editing sublevels ensure that the subject matter is accurate and complete. The third editing sublevel ensures that the basic logic of the subject matter is sound, and the fourth editing sublevel ensures that the 1.0, 1.1, 1.1.1 hierarchy of the subject matter is sensible.
  • Language Editing refers to the technical subject matter in a document both in verbal form and visual form. Language Editing focuses on the exposition of the knowledge through words and images. Language Editing encompasses sentence structure, grammar, diction, punctuation, spelling, and character mechanics (font and display attributes). Language Editing focuses on the particular standard visual elements to be used in any given type of illustration. For example, for network diagrams, some companies might want to consistently use the same network-server icon. Language Editing ensures that both the verbal language and the visual language are standardized.
  • Layout Editing focuses on the following document areas:
    • Industry-standard, large-scale document page layout patterns (for example, a traditional template for a specific industry project plan)
    • Text and illustration spacing
    • Large-scale font formatting (small-scale, or individual, font formatting is part of character mechanics under Language Editing)
    • Miscellaneous layout mechanisms such as running headers, page numbers, and hyperlinks

Now that I have laid the editing foundation for this examination, let’s examine the nature of XML before we see how it affects the editing model.

XML (eXtensible Markup Language) is a metadata language that allows you to tag a chunk of text with labels that explain the nature of that chunk of text. XML promotes the use of tags that indicate “this is a name” or “this is an inventory part.” XML also controls the structure of a document to a large degree. Using the same set of labels, or XML tags, you can dictate the pattern of particular chunks of text. Perhaps you simply have a set of XML tags that are “heading” and “paragraph.” You can dictate rules for the structure of the document such as a paragraph must always appear right after a heading or a figure can never appear without a caption. The library of XML tags and the organizational rules for their use within a specific document is referred to as a document type definition (DTD) or an XML schema. So, we have tags that describe the nature of chunks of text within a document, and we have restrictions about how the document can be structured.

For the purposes of this article, there is at least one more way that XML can control a document: layout. A complimentary standard of XML called the XML Stylesheet Language (XSL) can dictate how particular XML tags are displayed. While XML focuses on describing the nature of text, XSL dictates whether a chunk of text appears bolded, or centered, or whatever. With XML and XSL, the nature of text and the formatting of text are kept completely separate.

So how does XML affect technical editing? Well, XML doesn’t control every aspect of technical editing to the point that you and I are relegated to the role of spellchecker, but XML does take a significant amount of control away from the technical editor.

How Does XML Affect Knowledge Editing? XML cannot control the accuracy or completeness of text. Unless XML is instilled with artificial intelligence in the future, it never can, and it never will. However, XML does control knowledge logic and hierarchy to a degree. For example, an XML DTD can control whether chunks of text tagged with a paragraph tag can occur after chunks of text tagged with a heading tag. However, XML cannot control the logic and hierarchy within the tagged chunks of text.

The XML DTD may be able to control the structural logic of the text to some rudimentary degree (for example, the pattern of tagged text must be heading-paragraph-heading-paragraph-subparagraph), but it cannot control the substantive logic within a paragraphs or within a sentence. You could have what is called a well-formed XML document, in which the pattern of heading text chunks and paragraph text chunks satisfies the rules of the XML DTD, but those text chunks could contain complete gibberish, and the XML DTD would not know the difference.

How Does XML Affect Language Editing? XML has the least control in this area. You can tag a chunk of text with a paragraph tag, but that tagging cannot control the sentence structure, grammar, diction, punctuation, or spelling. You can still write a horribly structured sentence, and the XML DTD would never know the difference. Bad spelling could also be rampant in an XML document. As part of the style rules in the related XSL, the character mechanics can be controlled: headings can be made to be a particular font size, case, etc.

How Does XML Affect Layout Editing? This is where XML dominates technical editing across the board. Everything within the layout editing can be controlled by the DTD and the DTD-related XSL: industry-standard, large-scale document page layout patterns; specific text and illustration spacing; large-scale font formatting; and miscellaneous layout mechanisms such as running headers, page numbers, and hyperlinks. With a document developed using XML, the technical editor doesn’t need to focus on these layout aspects. XML allows the technical editor to focus on knowledge and language.

As you can see, XML does not relegate technical editors to the trash bin of technical documentation history. Even with the restrictions of XML, technical writers have a lot of room to maneuver, and therefore a lot of room to make mistakes. Where there are mistakes, there are technical editors. Technical editors are still needed to edit for accuracy and completeness, and to a large degree, a human brain is still needed to ensure correct logic and hierarchy. All the traditional language skills are still needed. Layout is governed largely by XML, but, for those of you who always loathed setting margins and making text bold at a 14-point font size, your day of deliverance has come. Until an XML language is developed with an artificial intelligence that can recognize the illogical structure within any given sentence or that two sentences have been turned around, a technical editor will be needed.

Posted on

Editing DITA Topics: The Changing Role of the Technical Editor in the Age of DITA and Topic-Based Authoring

Michelle Carey, Michelle Corbin, and Shannon Rouiller

Can we live without books? Certainly, we can’t live without those wonderful novels that we pick up at the airport. But we can and should replace the book with a more useful vehicle to deliver technical information, and, as editors, we can learn to help create and edit the content for this new information delivery vehicle.
In the past, technical editors worried mostly about the meaning and appearance of the text in printed books or online help. We focused on margins, font sizes and types, line spacing, grammar, punctuation, and the clarity and organization of the text. However, much has changed in technical documentation. Although we never forget the importance of clear language and style, we have shifted much of our attention to a new paradigm: topic-based authoring.

With Darwin Information Typing Architecture (DITA) and topic-based authoring, we focus first on the external text that the users read, but we must also focus on the DITA XML elements and technology that are used to produce that external text. This new focus on DITA elements and technology has re-created the role of the technical editor in the age of topic-based authoring.

Learning the DITA XML elements and technology

Editors must now focus on the content in a different way and must also review the XML elements that writers use to create that content. DITA XML elements identify content for what it is, not for what it should look like. Editors must help writers use DITA elements properly because using the correct DITA elements can ensure that search engines return more precise results for searches or help users filter through lots of information. By understanding and using the tools and technology that produce the text, we can communicate more effectively with our writers. If we use the names of elements and attributes to explain the change that needs to be made to improve the text, writers are more likely to use elements consistently.

Editors must also work with authoring tool developers to ensure that DITA contains the most appropriate semantic elements and that the DITA elements generate the appropriate highlighting (bold, italic, monospace type, and so on). One of the current challenges for editors and writers is knowing what DITA element to use for which type of content. For example, DITA has an element called <apiname>, but should we use that element for all content about APIs, such as methods, classes, and packages? Separate elements do not exist for methods and classes. Editors can step in and ask the tool developers to create more specialized API elements, such as <apiMethod> and <apiClass>.

Editing topics

In addition to strong writing at the sentence level, an effective topic should meet certain criteria. Editors should look for:

  • A precise title
    One topic collection from one product might be displayed with other collections from other products. Therefore, topic titles must often be more precise to distinguish them from other similar information. For example, many software products have information about security. You cannot simply title those topics “Security.” A better title might be “Database security” or “Configuring ACLs for database security.”
  • Useful content
    At IBM, editors try to ensure that topics are not used simply as navigation devices, but that they contain some useful content. Also, we ensure that each topic’s content is independent of other topics.
  • One or more links to other topics
    Users should never be stranded in a topic. You can use linking, indexes, and tables of contents to ensure that users get to the right information quickly and easily.

 

Editing topic collections versus books

Users of software and hardware products typically require the right information at the right time. Users no longer sit in their living rooms next to the fire and read the manual. They want easy to read, useful information that will help them complete some task right now. To accommodate our users’ expectations, we must create self-contained, reusable topics that can be packaged in small or large collections.

In addition to editing a topic, we must also edit collections of topics. Editing topic collections is not the same as editing book chapters. What’s changed for editors is that many of us rarely edit books as linear sets of information. We don’t look at how one chapter flows to another or how chapters build on previous chapters. We also no longer assume that users read the first chapter and work their way to the final chapter. For example, many technical manuals use transitions such as “The previous chapter showed you how to create profiles. This chapter focuses on editing profiles.” Such a transition never makes sense in a set of topics because we cannot assume that users read linearly or arrived at the topic through some predefined sequence. What topic writers might use instead of the transition is an imperative to the user to do a prerequisite task of, say, creating profiles. However, the topic writer cannot assume that users have read the topic about creating profiles.

Think of topics as buoys floating in a sea. The buoys are connected to other buoys, but not necessarily in any particular order. Books are typically written as if they were train cars connected linearly. We don’t want to make users get on the train and have to walk through each train car to find the right nugget of information. The editor’s job is to ensure that we provide the buoys, or topics, that users need and that the buoys are easy to find. Also, users must be able to jump from one buoy to the next whenever they need to.

To make topics easy to find in the collections, editors need to help arrange topic collections and topics within collections in ways that make the most sense to users. For example, topic collections might be organized by product or by user goals (such as administering or troubleshooting).

Picking our battles: Focus on the rules

When you are struggling to convert libraries to topics and reorganize a mountain of information, smaller things such as whether a list is compact can seem much less important to you. White space, font choices, widows, orphans, and transitions don’t matter as much in an online, topic-based world. You find that you can let go of many of your old pet peeves, and that can be liberating.

Although we were able to let go of many pet peeves, we found that others needed to be championed. In cases where DITA doesn’t provide what we need, editors must play a key role as the advocates for needed changes to DITA. We can submit requirements to DITA, or find workarounds, or sometimes both. At first, we were tempted to submit requirements for all sorts of esoteric issues. We soon found that without a business case, requirements were not going to be accepted. We quickly learned to pick our battles and submit requirements only when prudent.

For example, we submitted a requirement to add a new element inside the <steps> element for task topics. No element was available for the “To” statement to introduce a set of steps. For purposes of clarity and reinforcement, we want to introduce steps with a statement that indicates what the steps are for, such as “To print the report:”. But there is no place to put the “To” statement so that it can be part of the <steps> element. Because we were not willing to wait for that requirement to be addressed, we came up with a workaround to add the “To” statement as the last paragraph of the <context> element in the task topic. We don’t like the workaround because it separates the “To” statement from the list of steps, and therefore does not support clean reuse of the <steps> element. But we had to do something in the interim while we waited for the requirement to be addressed.

Short descriptions: Focus on the content

Change of focus spans more than just DITA requirements and restrictions. The move to DITA and topic architecture has made us question our content: Is the content pertinent to the topic? Or was it just put there to make the book flow? Do users really need it? If they don’t need it, then why are we writing it, translating it, and maintaining it?

With topics, we need topic introductions, not transitions. In the days before DITA, we rarely thought of section introductions as standard. But we’ve discovered that an effective short description can focus a topic more clearly than a title alone can. The short description should state the main point of the topic and provide useful information. For example, suppose you create a topic with a title “Links in DITA.” Instead of starting with a short description that says “This topic is about linking in DITA,” you can start with a short description that says “DITA supports inline links, related links, and map-generated links.” In this way, you are stating the main point of the topic and providing useful information that is not already found in the title of the topic.

Short descriptions are also key retrievability aids because they can appear in search results, as hover text for links, or underneath child links. Writing one or two sentences that serve all these purposes well is difficult, and so editors must provide guidelines and examples to help our writers create effective short descriptions.

Best practices for editing DITA topics

As editors, we must work with writers, with information architects, and with user experience professionals to focus on topic-based authoring from the top down and the bottom up. We must understand and work with the technology while still delivering a complete information experience based on solid information architecture principles. Here are some best practices for editing DITA topics that we collected:

  • Create self-contained topics that are easily moved from one area of the information set to another and that don’t rely on other topics to make sense (after all, topics can be linked to other topics to provide that additional information).
  • Edit the overall navigation structures for the topic collections to ensure that the topic collections are grouped in a way that makes sense for your users.
  • Learn enough about DITA to ensure that the content is represented semantically by the correct XML elements, thereby making you, your writers, and your information more effective and efficient. Also, ensure that the DITA element generates the appropriate highlighting that your style guidelines suggest.
  • Compare the rules of DITA with the rules of your style guides and know where to draw the line for both rule sets.
  • Focus on the content—the content that makes the most impact and the most sense to your users.

DITA offers new opportunities for editors to improve the user experience with information. Editors are becoming leaders in driving the movement to topic-based authoring. After all, books are out; topics are in!

** IBM is a trademark of International Business Machines Corporation in the United States, other countries, or both.

Editor’s Note: This article originally appeared in the December 2007 issue of Best Practices: A Publication of The Center for Information-Development Management (Volumn 9, Issue 6, p. 129, 133-135). You can subscribe to the hardcopy newsletter or sign up for a free e-newsletter at the Center for Information-Development Management Web site:
http://www.infomanagementcenter.com/publications.htm(external link).
Posted on

Keeping up with the Joneses (or Is It Joneses’s?)

Justin Baker

It’s important to keep up with your fellow technical communicators; one should be up-to-date on all of the latest advances in the technical-communication profession. But sometimes we can get too caught up in the latest professional advancements—XML, DITA, information architecture, online help systems, metatags, user-interface eye tracking, etc.

Among all of these sophisticated, bewildering advancements, verbal text (words and paragraphs) is still one of the basic building blocks of technical communication, and good grammar is what makes verbal text solid and valuable. As a result, a good grammar refresher is needed from time to time.

There are many educational tools that can provide such a refresher. One tool that I have found particularly helpful is the Bedford/St. Martin’s Exercise Central 2.0 Web site (http://bcs.bedfordstmartins.com/exercisecentral/(external link)). As you may know, Bedford St. Martin’s publishes the informative Handbook of Technical Writing. When you access the Exercise Central 2.0 home page, you will notice that you have to log on to the Web site. To do so, you need to sign up as a either a student or an instructor—don’t let this deter you. Sign up as a student. If you don’t log in, only limited content will be available to you. (Note: I contacted the Web site’s staff to determine if use of their Web site by common users is a violation of their policy; a staff member stated that it is not against their policy for the Web site to be used by someone who is neither a student nor an instructor.)

Once you are logged in to Exercise Central 2.0, it will be important to note the Tutorials and Exercises hyperlinks under the Web site’s banner at the top. These sections will provide you the educational meat you’re looking for. (The Diagnostic and Scorecard sections are primarily for students and instructors who need to view reports of exercise scores.) The Tutorials section gives you a great refresher on common grammar rules (in addition to usage and style issues), so take that first if you are particularly rusty on grammar. After you have taken the tutorials, the Exercise section allows you to test your grammar knowledge. The exercises are usually 10 questions each with easy option clicks to speed each exercise along. Simply click Submit once you are done with the questions, and you immediately get your score. Exercise Central 2.0 is a very lean, easy method for exercising your grammar knowledge.

Another tool that I have found particularly helpful is Diana Hacker’s Grammar Exercises Web site (http://bcs.bedfordstmartins.com/rewriting/ge3.html(external link)), which is related to Hacker’s book A Writer’s Reference published by Bedford/St. Martin’s. Again, these exercises serve as a refresher on more than just grammar (if you consider grammar in its strictest definition: how words and phrases function in relation to one another to form a coherent language); exercises on usage and style (word choice and sentence style) are also present. Unlike Exercise Central 2.0, these grammar exercises do not require registration. You are prompted to provide a name each time to sign on, but, technically, you don’t even have to do that. Once you have selected an exercise from the exercise menu, either type a name (any name), and click Begin, or don’t provide a name, and click Begin. Diana Hacker’s Grammar Exercises has a slightly more contemporary instructional design with the employment of hyperlinks rather than option buttons, but the overall design is the same—10 questions with easy answering for a streamlined educational experience.

Sometimes our heads can get lost in the proverbial clouds of technical advancements, especially publishing-format advancements. It’s important to periodically ground ourselves and remember some of the basics of our profession. Those basic building blocks include verbal text and grammar. Bedford/St. Martin’s Exercise Central 2.0 and Diana Hacker’s Grammar Exercises can help you get reacquainted with those building blocks.