For this post, I am going to move away from proofreading and write a little about style sheets and why they can be really helpful when you are editing any piece of writing.
Style sheets can be as casual as a few quick notes jotted down on a piece of paper, such as quick points to keep in mind (like to remember to capitalize the first letter after a bullet) or they can be more elaborate tables or even a full-out guide.
At the community newspaper where I work, we use a style sheet that is about four or five pages long. It is meant to capture writing style that is different from the standard practices that we follow (e.g., Canadian spelling, CP style). For example, we use email instead of the suggested e-mail. Also, there are a number of business names that we have written down so that we can get the proper spelling right. Other general style decisions are recorded here too — like referring to people by their full name first and last name on subsequent reference.
I try to keep the style sheet as up-to-date as possible and I refer to it a lot. The thing about style sheets is that they can be subjective; once you make a decision about how you will treat an element of writing, following the style sheet will make sure that you are consistent throughout your article or publication.
Here is one example of a style sheet that I found online:
Here are two links about style sheets that provide some useful information:
Here are a few ideas to help you proofread text that you have written yourself:
- Take some time to give yourself space from the text before you proofread — for example, overnight or even a day or two
- Print the text in a different font or larger text so that it appears different to your eye
- Read out loud (or say the words out loud in your head)
- Proofread the text backwards (one or two pages at a time)
When proofreading the work of others, if possible, I usually read the text over once so that I have the gist of what the writing is about. That way, I don’t end up concentrating on the meaning of the text when I should be paying more attention to the words on the page.
There are also a few areas where errors are likely to hide, like in headings, tables, numerical sequences, alphabetical lists, bracket or quotation mark twins, to name just a few. If you have time, a good idea is to prepare a checklist of things to look for that you can consult while you are proofreading.
Here are some helpful links about proofreading:
Proofreading is an important last step in the writing process. Both technical writers and editors need to be careful proofreaders, both of their own work and that of others. If work is full of grammatical errors or typos that should have been caught earlier in the publishing process, then even if the writing is technically accurate and well-researched, it loses its credibility with the reader.
Although true proofreading is really meant to happen once the document has come back from layout and is in its final form (a final check of the proofs), I think it is important to know and use the principles of proofreading after a document has been copy edited and the changes have been incorporated. Even if there is not enough time to do multiple passes of the document, a final proofread will be very useful in catching errors.
The Chicago Manual of Style is a good reference to consult for learning the common proofreading marks. I think these marks are very useful to know — they really are universal symbols that should be understood by all proofreaders. Here is a link to its site:
My next post will discuss some helpful proofreading techniques.
This is the first entry in my blog about technical editing. I have never used WordPress before and am starting this blog as part of an assignment for my web-based documentation course.
I was a little confused by the process at first; when I tried to set up my blog I seemed to be caught in a loop of Steps 1 to 3. Once I realized that I had to confirm my email address first, then I was able to post new entries.
I want to write about technical editing because it is an aspect of technical communication that I find quite interesting. Much of what we do as technical writers is to some extent technical editing — taking content from functional specifications and translating it into language that typical users can understand. Keeping the audience in mind is always important. If the language is not geared towards the people who are reading the material, the documentation experience will be frustrating and disappointing for the user.
Here is a link to the Technical Editing Special Interest Group (SIG) — a part of the STC. It is an excellent group to join if you are interested in technical editing: