Skip to main content

Word Processing Essential Skills

For the last couple of days I have been reformatting and revising a Word document I created and then passed along to colleagues. Unfortunately the colleagues used "brute force" to alter the formatting of the document. This formatting method rendered the automatic table of contents, title page fields, and indices useless.

Brute force formatting is when you override the style of a paragraph or word to match another style's appearance. For example, instead of changing a "Normal" paragraph to "Heading 2" for a section, the editor of the document simply increased the size of the text and applied "bold-italic" font attributes. As a result, headings created this way did not appear in the table of contents.

Such formatting was applied throughout the document. In once case, a bullet list appeared in the table of contents because the style was "Heading 3" — with brute force formatting to make the text appear like the "List Paragraph" style.

I was frustrated. I cannot fathom professional writers, especially ones with tech industry contracts, not using Microsoft Word features properly.

Microsoft Word, Corel WordPerfect, Adobe InDesign, Apple Pages, and most other text-based applications use "styles" to control the visual appearance of elements and document automation features. Every HTML/XML editor makes extensive use of tag styles and classes. Not using styles reflects poor writing habits. You cannot create effective and compliant DITA, ePub, or HTML documents without understanding styles.

There are things I find (or don't find) in the documents I receive to edit that bother me. The following list are some of the more annoying "bad habits" that increase the time I must spend repairing a document:
  • Misuse of styles or missing styles to indicate chapters, sections, and subsections.
  • Spaces and tables to align text that should be positioned with tabs.
  • Manually created tables of content, page numbers, and indices.
  • Forced page breaks using blank lines instead of actual page breaks.
  • Inconsistent spacing after punctuation, even though Word can check spaces.

We should teach students to use tools properly, in addition to writing well. Some of my colleagues argue that we need to focus solely on the words, not how they appear on the page, but the document design itself is a rhetorical act. A document's appearance and accuracy affects how the document is perceived.

The skills of organizing a document "properly" for software to automatically create tables of content, indices, and other features, forces the writer to consider the organization of ideas in the document. A table of contents is an outline. The indices are forms of "idea clouds" or "tag frequency" lists. When you think about how a document functions, you are also analyzing its effectiveness.

I received a paper with page numbers out of order. That implies a lack of organization and preparation. Yes, using a typewriter or writing by hand could result in the same problem. Still, a word processor will number the pages for you — and the order is always in series (unless you did something unusually creative with the fields). Copying and pasting manually numbered pages is obvious when you forget to renumber them.

Using "carriage returns" to force page breaks leads to other problems. I've received papers from students in which the page numbers slowly drifted down the pages. By page ten or so, the number was three inches down the page. Text meant for one page carried over to the next. This happens when the writer adds content to an earlier page without realizing the extra lines "cascade" from page to page. One more reason to use page numbers in headers or footers.

Teaching automatic formatting features actually relieves writers from considering things like the drifting page number issue. When a word processor does the "grunt work" of formatting complex elements, especially contents and indices, hours and hours are saved. If you consider learning these features in light of the time they set free for thinking about the content, it is hard to argue against mastering basic word processing skills.
Enhanced by Zemanta

Comments

  1. Forced page brakes using blank lines instead of actual page breaks.

    Did you want to change the word "brakes" to breaks?

    ReplyDelete

Post a Comment

Popular posts from this blog

MarsEdit and Blogging

MarsEdit (Photo credit: Wikipedia ) Mailing posts to blogs, a practice I adopted in 2005, allows a blogger like me to store copies of draft posts within email. If Blogger , WordPress, or the blogging platform of the moment crashes or for some other reason eats my posts, at least I have the original drafts of most entries. I find having such a nicely organized archive convenient — much easier than remembering to archive posts from Blogger or WordPress to my computer. With this post, I am testing MarsEdit from Red Sweater Software based on recent reviews, including an overview on 9to5Mac . Composing posts an email offers a fast way to prepare draft blogs, but the email does not always work well if you want to include basic formatting, images, and links to online resources. Submitting to Blogger via Apple Mail often produced complex HTML with unnecessary font and paragraph formatting styles. Problems with rich text led me to convert blog entries to plaintext in Apple Mail

Learning to Program

Late last night I installed the update to Apple's OS X programming tool suite, Xcode 4. This summer, in my "free" time I intend to work my way through my old copy of Teach Yourself C and the several Objective-C books I own. While I do play with various languages and tools, from AppleScript to PHP, I've never managed to master Objective-C — which is something I want to do. As I've written several times, knowing simple coding techniques is a practical skill and one that helps learn problem solving strategies. Even my use of AppleScript and Visual Basic for Applications (VBA) on a regular basis helps remind me to tackle problems in distinct steps, with clear objectives from step to step. There are many free programming tools that students should be encouraged to try. On OS X, the first two tools I suggest to non-technical students are Automator and AppleScript. These tools allow you to automate tasks on OS X, similar to the batch files of DOS or the macros of Wor

Learning to Code: Comments Count

I like comments in computer programming source code. I've never been the programmer to claim, "My code doesn't need comments." Maybe it is because I've always worked on so many projects that I need comments  to remind me what I was thinking when I entered the source code into the text editor. Most programmers end up in a similar situation. They look at a function and wonder, "Why did I do it this way?" Tangent : I also like comments in my "human" writing projects. One of the sad consequences of moving to digital media is that we might lose all the little marginalia authors and editors leave on manuscript drafts. That thought, the desire to preserve my notes, is worthy of its own blog post — so watch for a post on writing software and notes. Here are my rules for comments: Source code files should begin with identifying comments and an update log. Functions, subroutines, and blocks of code should have at least one descriptive comment.