“Let’s see...company credo number three... ‘Our employees are the lifeblood of the company, they are our most important asset.’ Huh, that sounds familiar.... Let me check.... Oh, here: ‘Our employees are the life’s blood of the company....’ Oh, hmm... And here: ‘Our employees are the company’s lifeblood....’ Oh wait....”
Three identical pieces of text...that aren’t identical. This is what some editors call job security. Certainly such error magnets keep us busy, help expand our billable hours, and help us to justify our existence to employers and clients, but in the end, we find ourselves wishing that more content would be planned in a way that minimized the use of imperfectly redundant redundancy.
Any good editor relishes a piece with large-scale errors, open to plenty of hacking and slashing and the possibility of creativity in setting things aright. What’s irksome to editors are the passages that involve repetitive drudgework, when you have to read the same text over and over again, just in case someone accidentally hit an extra key when they were cutting and pasting. Not only that, if the text really is supposed to be identical to something else, the editor has to spend extra time on that baleful verbiage to both edit it and check it word for word against other occurrences.
Companies have good reasons for such repetition: “the clients want to see how it’s going to look as a final product,” “they don’t realize that they could see this same text elsewhere,” or “we don’t want the user to have to flip back and forth.” Because editors are dutiful and flexible service-oriented individuals, ultimately we’re always willing to accept these explanations, however grudgingly, and get back to work. But as we work, rest assured that we are taking note of every time we see that same text again.
In the world of all-paper publishing, typewriters, and lead type, there wasn’t much you could do about this problem. Every piece of text had to be put on the page, and, therefore, every word on the page had to be read by an editor, no matter how many times that text occurred. We live in a different world now, a world that has content management systems and XML coding. And what a wonderful world it can be.
With a content management system, we can treat pieces of text as numerous individual documents. With XML, we can label pieces of text and treat them like objects, just as we can treat chunks of code in object-oriented programming. In both cases, we can build larger documents by pulling together these pieces of text in a very clean and highly efficient fashion. You want those company credo items listed five times in the annual report? Just have the credo saved somewhere and insert a call for ‘credo.doc’ or ‘credo.xml’ into your document in five places. There’s no need to type out the credo five times or go copy the credo from one place and paste it into four others.
A common response might be, “Well, in the end, you’re going to have to edit the whole thing anyway, so what do you save by breaking the text into pieces?” True, if you print the whole document out, you’re going to want to make sure everything’s there, but if you use a more object-oriented setup, that review can go much more quickly.
If we use the credo as an example, before printing out the document, you will have edited the credo file or object already—once, not five times. When the file is printed out, sure, you might give the first occurrence of the credo a quick proof—sometimes errors are easier to see on paper than on a computer screen. But once you’ve done that, anywhere else the credo appears, all it will require is a quick glance to make sure it showed up...and maybe check that the period at the end isn’t missing. If you find any errors, you only need to correct them once, in the file or object, and they will be fixed in all five places.
Stay tuned for the next installment on this...ahem...thrilling topic.
