Testing! Testing!
Here’s another example why you should have proof everything you publish, and why you should have a proofing procedure in place Before You Publish.
Consider this view of a recent law firm newsletter:
The bulleted items aren’t set right. Does it matter?
Someone at the firm might have proofed the newsletter and not noticed that things weren’t set right. The proofer might have seen this:
This can occur when the proofer uses a computer that doesn’t show how the article is going to appear on other computers.
____________
We don’t need to concern ourselves with the technical details. All we need to know is that the HTML for the newsletter doesn’t follow the rules, and that’s why the newsletter looks OK on some computers, but not on others.
What to do?
A good test for anything you publish using HTML is to run it through an HTML validator before you publish it. You’ll see the errors, and you’ll fix them before you publish (assuming you’re a conscientious sort).
Copy the following URL:
http://www.kenyon.com/newsletters/summer08_PatentExhaustion.html
Go to the W3C’s Markup Validation Service, and paste that URL into the Address field.
You might see the following:
No wonder the newsletter won’t look right to some (depending on which browser they’re using, and how it’s preferences are set).
OK. In this case, it’s not a big deal, but imagine what COULD happen when you publish something with so many errors!
____________
There’s a potential client, and he’s searching for some information. He finds your firm’s newsletter, which contains precisely the information he seeks . . . but he can’t decipher it because of technical problems: technical problems that are easily so resolved with due care.
