A recurring theme among writers in general is how challenging it is to spot errors in one's own writing. Typos and grammatical glitches practically jump off the page when perpetrated by others, but even after multiple passes through the self-editing loop, clean copy isn't guaranteed. Printing the piece may help; black text on a white sheet of paper often provides the contrast that's missing on a screen layout, especially when the color scheme doesn't lend itself to reading. Certain typefaces make it hard, too, when they're used much beyond logos or advertising. A compelling look and feel is great, but simplicity is more important when reader-comprehension is the ultimate goal.
Years ago, I sent most of my writing to the printer beside my desk, but I so rarely use a desk anymore that this isn't practical. I never much liked the idea of using up trees for my proofreading as it was, so this is a good thing in more ways than one. Now, most everything turns to HTML sooner or later anyway, so pumping up the text size in the browser—or other HTML client—is a good way to spot problems before they're sent out onto the Web. This is the final step in my process, however; there are too many problems that can develop in the code when formatting changes are made during the writing process. Depending on the particular software you're using for publishing Web content, these problems can run the gamut from mildly irritating to aaaaaiiiiiii!!!! I've pulled down more than one blog post within minutes of sending it to the host because of one or more of these unanticipated mess-with-stuff-in-the-HTML-stage effects. And in some cases it had more to do with Sudafed Head, but that's another story entirely.
Anyway, this is why I do the actual writing in plain-text format, or at least something not far removed from plain text. Not only does this provide a buffer against code glitches—because there is no code at that point—but makes it easier to focus on the words, without the distractions of layout or formatting issues. It's more like a plain sheet of paper. At this stage, I can use any font size because there's no formatting; things like relative text size are part of that final HTML world. It's easier for me to spot errors when the letters aren’t the size of gnats, so I keep the font relatively large during this initial phase. This is also where the spell-checking takes place; although it's possible after everything is converted to HTML, I avoid it because of the aforementioned potential for grief.
Of course, the best solution to the proofing and editing quandary is to get someone else to do it for you. When it comes to writing, there's no substitute for a fresh perspective. But this isn't always practical, so the next best thing is to shift your own perspective just enough to bring into focus the individual trees in your own forest of words.
No comments:
Post a Comment