He starts off:
If I thought it would do any good, I would advocate that every so-called ‘plain language’ document should have a warning.
WARNING! THIS DOCUMENT CAN MISLEAD
But warnings, like many aspects of communication—including ‘plain’ language—are not all they are cracked up to be (see our recent review of boxed warnings). The simple fact, with far from simple consequences, is that communication is messy and non-predictable (not just unpredictable). Any attempt to reduce communication to a few simple rules fails. Plain Language advocates offer us a few simple rules. They are good rules and in the main, well intentioned. But neither of these are a necessary or sufficient basis for good communication.[Editor: here's the link to the article about Boxed Risk Warnings]
And, a bit later:
I was prompted to write this particular blog because Plain Language advocates in the USA are all of a dither with excitement; there is legislation before the USA Congress requiring all government bodies to use plain language, no doubt in the belief that this will lead in due course to plain language heaven.
Why is plain language heaven as unlikely in the USA as it has been in Australia? I could give a long and complex explanation, but the basics are simple enough. There is no secret to good communication.
You really should read the entire article. Its implications spread far and wide: whether you're developing software, preparing a product brochure, creating a PowerPoint presentation, writing a user guide of any sort, or in any other endeavour involving communications, there should be something in David's article to make you think more carefully about what you're doing.
For example, I put much thought and effort into the wording of pop-up text on my web site, into the wording of error messages, into the layout and contents of user guides. Importantly, I don't leave it at that but regularly review my works of art, trying to hone them to perfection -- whatever perfection might be. Could that pop-up error message be improved? Is that user guide missing any important information, and can it be arranged better? ...
We should all do this, but with insight from David Sless's artcle we can now also contemplate whether or not our creations suffer from the "plain language" syndrome!