Every minute of every day, more and more words appear on the Web. It's easy—almost too easy—to publish online, yet Web pages need the same scrutiny as pages that come between covers; in fact, they need more. Why?
First, e-mail and text messages notwithstanding, the rules of writing really do reach into cyberspace. Readers can be just as confused by a misplaced comma or a tangled transition on a Web page as on a book page. And because speed is often paramount in posting on the Web, errors born of haste are all the more likely. So an editorial eye becomes that much more necessary for Web content, for both the reader's sake and the author's image.
Second, Web pages have things book pages do not, and those things need to look right and work correctly. The functional and interactive elements that appear on Web pages need to be checked and verified every bit as much as the words that go with them and for the same reasons—to prevent confusion, frustration, and misunderstanding. Doing so is what makes editing or proofreading for the Web a special task.
You can't mark changes directly on a Web page, but that doesn't mean errors need escape. There are several ways to catch and correct them, some fairly lowtech, and some a bit higher. When working with Web pages, you can do some things offline and others with an Internet connection.
To test and verify interactive elements, you'll naturally need to view them online. You can pick up errors in text and note changes to it while viewing it "live" too, but you don't have to. For text, there are alternatives.
For instance, you can make a hard-copy printout of a Web page and mark corrections manually. Or, using an application like SnagIt, you can capture a screen and insert it in another file, such as a Word, PDF, or PowerPoint file, and use many of the editing tools supplied by those applications.
With this range of options, you'll probably note editorial changes—whether they apply to text or to interactive elements—in one of three ways:
• On a hard-copy printout of the page
• On a separate electronic reporting form
• In an electronic file created from a screen capture
A few pointers about each of these methods will help you handle Web pages smoothly and efficiently, however you review them.
If you're working on hard copy, with printouts of several different screens, be sure to number the pages manually if page numbers don't already appear. You'll often return your corrections by fax, so mark changes very clearly, using standard editorial marks (see Chapter 2 for samples). Place any queries directly on the page, not too close to the edge. In fax transmission, material on page edges is sometimes lost or illegible.
If there isn't room to write everything clearly on the printout, create a separate sheet for changes and queries and simply note on the hard copy of the Web page where the insertion or change belongs. On the separate changes/queries sheet, clearly indicate the Web page to which they apply and the location on the page where each change belongs. One way to do that is to number the changes and place corresponding numbers on the Web page printout.
If you want to, you can also record needed changes on an electronic or printed-out reporting form.
Sometimes clients prefer to receive changes and queries via e-mail, rather than on hard-copy printouts of Web pages. When they do, an electronic reporting form (like the one at the end of this chapter) can be a real convenience.
When reporting needed changes on an electronic form, it's vital to clearly indicate both the exact change to be made and the location of each change. Include the name of the page or a page identifier. And if you're using page numbers as identifiers, be sure everyone working on the project agrees about what a "page" is. Sometimes authors and Web developers define them differently. If no other identification method is specified, use the page's address (its URL), which is located on the address bar of your Web browser. If the address bar isn't showing, make it visible using the menu options on your browser's toolbar (in Internet Explorer, View > Toolbars > Address Bar).
Then specify the paragraph and line, but keep in mind that on different computer screens the lines may display differently. To avoid confusion, instead of saying, for example, "p. 4, line 3, delete the," you might say, "p. 4, line 3, change look at the him to look at him."
If you find the same error appearing on several screens, you can enter the needed change just once on the form, the first time you note the error, then copy and paste the change into all other appropriate spots on the form.
Tip
To make the reporting form (a Word file) easily accessible as you work, minimize it and keep it a click away at the bottom of your screen.
When using a screen capture application such as SnagIt, you can easily capture an entire Web page (what is showing on the screen and even what is not showing), or you can capture any element of any size on the page—text or art. You can even capture pages that scroll.
You then have the choice of printing out the screen captures and marking your changes on the hard-copy printouts. Or, as we mentioned earlier, you can insert the captures into another application, such as Word, Acrobat, or PowerPoint. At that point you can use the editing tools those applications contain to comment on the screen capture. Note we don't say mark up the screen capture; screen captures may contain words, but they're treated as images and cannot be edited directly.
If you will be returning changes electronically, be sure the file that contains your corrections is named to accurately describe the page you're commenting on, using either a specified locator method or the URL of the page, as noted earlier.
Tip
As in any editorial task, it's very helpful to review Web pages in stages—text first, then other elements, one by one. If you look at all headings, all navigation buttons, all banners, etc., in isolation, you'll be far less likely to become distracted or miss things. (For more on helpful editorial procedures, see Chapter 2.)
Elsewhere in this book we've discussed what to look for as you review general text. All that applies to Web text too. Words need to communicate effectively, wherever they appear. So the 3 Cs covered in Part Two—Is It Correct?, Is It Consistent?, Is It Clear (and Compelling)?—all apply to Web text as much as they do to any other writing. But in Web content a few of them need extra attention:
There's correct, and then there's correct on the Web. Heads up for:
Punctuation. In particular, pay close attention to em dashes, en dashes, hyphens, apostrophes, and quotation marks. These don't always convert correctly from a word processing program into Web content. With the improvement of conversion software, this isn't as big a problem as it used to be, but these marks—as well as symbols such as mathematical operators, degree symbols, and so on—often appear incorrectly or are dropped altogether. Keep an eagle eye out for them.
Tip
In the world of word processing, apostrophes and quotation marks can be curly (smart) or straight (not dumb, exactly, just noncommittal). In Web materials especially, you often see both styles in the same document. Stay alert to be sure these tiny marks are all either Mensa material or average Joes.
Figures, Graphs, and Art. If text was originally written to appear in print materials, "location" terms may have been used that don't apply in Web content, such as "See the graph at left" or "the table on page 62." If all the content is freshly minted for the Web, and none of it was imported from other applications, you shouldn't see locators like these. But if any bits or pieces came from other sources, some inappropriate locator terms may remain. Until you read it, that is.
Web Links. Obviously, you'll find many more Web links in Web content than in other electronic copy. You or someone else should click every single link to make sure it does what—or goes where—it should.
As you check links, keep in mind what linked text to review and what linked text not to. Links may be to pages or elements within the project you're reviewing, and those probably are your responsibility. But links may also be to any other location on the Web, and it's not your job to proofread all of cyberspace. Be sure you're clear on which part of it you are responsible for.
Tip
Every time you review a page, check tables of contents and indexes. Why? It's easy when adding or deleting content to forget to change their associated links.
Normally, consistency is a cornerstone of effective writing. In most writing, style that varies serves only to confuse. But on the Web, there's an area where style gets a freer rein, with no harm done: e-learning, including online quizzes.
Web content in general and online courses in particular often have multiple authors. So do print learning materials, but in e-learning content it can seem like a cast of thousands.
An e-learning site, for example, might have courses on many topics, each written by a collection of different authors, possibly edited by different instructional designers and reviewed again by subject matter experts. Those are a lot of cooks for the e-learning stew. It's a little unrealistic to make them all toe the same stylistic line.
If you're checking e-learning courses or any other kind of online quizzes or exercises for consistency, you'll probably need to make some things uniform but be able to let some things go. To find out which are which, be sure to check with whoever has asked you to do the work.
For example, a client may want to make sure that ranges of dates always contain an en dash, not a hyphen (2003–2005, not 2003-2005), but may not be concerned if one author says the thirties and another says the '30s. Or the client may not be concerned if one author writes in active voice and another writes in passive voice. Keep detailed notes about these items on your style sheet.
Like any other text, Web content needs to be clear, but what's considered clear on the Web is sometimes different from what's considered clear in more strait-laced places.
People who write Web copy presume that readers of online content want things faster, shorter, and sometimes more casually presented—much like advertising copy. Shortened or abbreviated phrasing that you might query in a book or manual might be just fine (or preferable) for an online venue.
Formal: Take $50 off two or more CD towers. It's pricing that gives you more for less.
Informal/casual: Take $50 off two or more CD towers. More-Is-Less pricing.
If casual is the consistent style of the writing, go with the flow and don't try to force the material into a more academic or formal style. At the same time, as always, if you ever feel that text is confusing, awkward, ambiguous, or just doesn't make sense, be sure to query it; or, if you're working beyond the level of proofreading, suggest changes as appropriate.
Although many Web writers use a casual or shortened style, they (and you) need to remember something important: if you're writing for the Web, you're writing for a global audience. The Internet is blind to borders, and if content is online, anyone, anywhere, can access it. And when they do, even if they speak English, they might be stumped by American slang or shorthand phrasing. Writers and editors for the Web need to keep in mind that any kind of casual phrasing, humor, slang, or other nonstandard writing runs the risk of confusing global audiences. (See "Writing for the World" in Chapter 5 for more.)
Shortened with slang: We're on call 24/7. ("On call" may not be understood everywhere, and a slash does not mean the same thing in different languages.)
Globally understood or easily translated: We're available anytime you telephone or e-mail.
Substitute standard phrasing for slang or abbreviations, or, if it's not your job to "fix" content, and you find text you think might stymie a global audience, either contact the client/author to ask if he or she would like you to note places you think might be changed, or include your thoughts in a cover note instead of marking the changes or adding queries in the document.
In reviewing Web content, this is a subject that takes off into new editorial territory; the checklist at the end of this chapter will guide you through it. It goes far beyond the 3 Cs to address the way a Web page looks and works. Although not all-inclusive, the checklist covers the main areas to watch while reviewing the function of a Web page, as well as some tasks beyond the scope of most editing or proofreading. Those extra items would normally be considered QA (quality assurance) tasks. But when budgets are tight, editors are often asked to do double duty and may wind up reviewing some QA items, so we've included them.
Most of what appears in the Checklist for Web Editing is self-explanatory, but some areas merit a little discussion:
Browser Testing. Sometimes it seems as if computer components and software stay current for minutes rather than months or years. Blink, and a new version is available. Web browsers may have a little better shelf life, but only a little. People change and update their browsers constantly.
That means it's important to verify that the Web content you're reviewing appears as it was meant to in a variety of browsers and a variety of versions. It's not always the responsibility of the proofreader or editor to test Web material in different browsers, but if you're asked to do it and you have the technology, Web surfers everywhere will thank you.
For PC people, Internet Explorer is the most-used browser, although Netscape has its fans. For Mac users, Safari is the leader, followed by Firefox. If you have different browsers available, opening Web pages in them may alert you to features that work in one but not another. With luck, your pages will work beautifully in all of them. If they don't, note what works differently from browser to browser. Fixing these items may involve nothing more than the developer or Web-master tweaking a bit of code.
Content Text. In addition to watching for details—such as punctuation marks—that don't convert accurately to the Web, pay close attention to the placement of text on the page. Graphics can end up obscuring text.
Tip
Always review a Web page at full size, making sure it fills your whole screen. Sometimes text is obscured only because the page is reduced so much there isn't room for all the text to show. The default display size (small or large) for text in your browser can also affect how Web items display. If features or text on the page overlap or display incompletely, try a different type size setting before assuming the problem lies with the page. (To reset the type size, go to View > Text Size.)
Downloads. Many Web sites give the reader an opportunity to download software and additional material (often as PDF files). As a rule, the editor or proofreader is expected to make sure the download takes the reader to the correct download location—but is not responsible (as mentioned earlier, under "Web Links") for proofreading the downloads themselves. It's a good idea to verify this with your client, however. Remember one of the golden rules of any kind of editing: Never assume.
Dynamic and Interactive Features. These are the things on the Web that grab your attention or give you something to do with your mouse besides scroll. There are so many of them, nudging you for notice, that they could fill a book by themselves. So let's define some terms:
• Static text is text that doesn't move—like the words on this page.
• Dynamic text or graphics do move. These could be pictures that rotate, animations, and so on. Dynamic text may move, but the user has no control over it and does not affect it in any way.
• Interactive features are those the user has some control over or can manipulate to get a response.
A Help menu is one simple example of an interactive feature. When you ask a question within a Help feature, such as how to format a table, it comes back with instructions or options for you, based on what you asked.
Another example is a multiple-choice online quiz. You are generally asked a question (What's the longest river in Uganda?), and based on the answer you choose, you may get feedback in the form of test results or further instructions. (Answer: the Nile. A piece of it starts in Uganda.)
Dynamic Elements. To review these moving targets, be careful to wait until their entire sequence is completed, more than once, to be sure you've seen everything. You may need to view it many times to make sure you're seeing every word, in context, in the order it's intended to be seen. This can be tricky, so stay extra focused.
Tip
Don't click twice on an interactive object; it may interpret the second click as a second command and repeat whatever it is supposed to do. If you're tempted to click again because the element loads sluggishly, note in your comments that it's slow.
Sometimes moving text will sequence only once. Sometimes the text goes through a rotation of, say, two or three phrases and then stops. In that case, refresh the image and the rotation should start over. Keep track of each change by counting iterations, location, wording, or anything else that applies, so if you need to specify a change, you can note which "version" of the onscreen element the change applies to. Also, be careful to click all More and Next buttons and follow every link to be sure you see all the content there is.
Interactive Features. Some of the most challenging interactive features to check for anomalies are the tests and exercises that come with online learning materials. There are many different types of interactive exercises, but multiple choice with a single correct answer, multiple choice with multiple correct answers, drag-and-drop, and fill-in-the-blank exercises are the ones you see most often. When reviewing these features, be sure you know how many correct answers are intended for each question and what feedback is expected for each right and wrong answer.
For example, sometimes the feedback for all incorrect answers is the same. Sometimes there is different copy for each incorrect answer, containing an explanation of why the incorrect choice is wrong—or not preferred.
Tip
When proofreading online quiz results, you may need to turn off the scoring feature so you can see the feedback for all possible answers.
Graphics. In addition to ensuring the editorial accuracy of any words that appear in graphics on the Web pages, take the time to look at the graphics as a user would. Make sure the graphics appear as intended, in the order intended, and that none are cut off, blocking text, or blocked by text.
Page Titles. The not-terribly-riveting titles of Web pages (e.g., cs-edit.com/what we do/html) show up in the browser address bar. While it's not usually your job to confirm that these accurately reflect the page you're viewing, we don't know of a single client who would mind if you did so. Today, Web page titles are often generated automatically, but it doesn't hurt—nor does it take long—to make sure they are correct.
Screen Resolution. Reviewing pages at different screen resolutions is not usually something editors and proofreaders are asked to do—unless they've taken on that QA role. In a Windows system, to check a page at different screen resolutions, go to the Start menu > Settings > Control Panel > Display > Settings and adjust the screen resolution (number of pixels by number of pixels).
Tip
Be aware that different text and screen sizes, as well as different resolutions, affect the way text appears on a Web page.
With smaller screens, lower resolutions, or larger text sizes, you may have to scroll around to see everything. That might be confusing—or risky. Also, the relationship of elements on the page can get squeezed or stretched or otherwise changed. Not good if the text reads "In the graphic to the right,"and the graphic actually appears under the statement. If you're reviewing a page at different text sizes or resolutions or on different screens, make note of any such potential problems.
Using a form like this, you can note editorial changes to Web pages while viewing them onscreen and then e-mail the list of changes to whoever has asked for your comments. Use this form if it suits or customize it for your own project. We've filled in some sample information here. (Note: The color highlights on this form appear gray on this page only.)
Use this checklist (in addition to the complete editorial checklist in Appendix B) to be sure Web page text is error free and Web page function is flawless.
