Technical Writing STANDARDS REHASHED By Dianna Patterson Senior Editor To readers who do not l i v e in the English speaking part of North America, I should explain that the t i t l e of this essay is meant to have a certain gastronomique relevance. This is because my intention is to eat some words that I wrote a while ago. I have not been a fan of standards, and I have dared to say so in print. I have found them restricting, and often s i l l y , because they focus on the wrong things. Several people have pointed out my error, and while I have agreed in principal, I have not been converted to the use of standards. I had never seen one that did a l l those wonderful things that standards writers always claimed they would do, and didn't do a l l those things that I dreaded them for. Well at last I have met a standard that has been a joy to work with. I t has given me just enough information, and not cramped my freedom of expression. To give credit where credit is due, I w i l l give the standards buffs and standards makers a taste of what a technical writer, who imagines herself creative, thinks are good standards. The standards I shall quote are from the Ministry of Transport C o m ~ S e r v i c e s Branch Documentat~~nd~ They are published by Transport Canada, DCS, Transport Canada Building, 14th floor, Place de V i l l e , Tower "C", Ottawa, Ontario Canada KIA ON5. everything that is important is on one of those pages. In 33 pages, the standard covers the three manuals that the ministry desires for each program. There are only a couple of pointers leading to another document, and those are merely how to f i l l out the job submission forms. 4) 5) 6) what quality control is to be applied what security requirements exist a sample transmittal s l i p Here is the general layout of the manual: Introduction User's Guide Introduction One section for each part named in the introduction Production Manual Introduction One section for each part named in the introduction System Manual Introduction One section for each part named in the introduction Each section is one page, and i t usually contains the required information in l i s t s . In the User's Manual Input section, for instance, the information required is: what i t is and what purpose i t serves where i t comes from how i t is prepared for the system But simply because the words are simple, and there aren't very many of them, does not mean than the directives are not comprehensive. Here is the entire section describing Error Correction Procedures to be given in the User's Manual: "For every error condition reported, there should be an error correction procedure explained in this section. Include the names of those people on whom the responsib i l i t y of error correction falls." Any forms that are expected to be included in a manual are included in the standard. There is l i t t l e chance of misinterpretation, and l i t t l e or nothing is l e f t out of this standard except the mention of an Index. So I am prepared to eat words I may have spoken against standards in general. Standards such as these are easy to l i v e with, and they do a l l those things that standards probably ought to do. Best of a l l , they are already f l e x i b l e enough that they don't need. constant committees of maintainers to keep them current. I don't see that I can ask for anything more -except, perhaps, for some salt? This is so very terse work that i t l ) is hard not to want to quote pages from i t . No page contains more than about 250words, and a 2) reading of the entire manual shouldn't take up more than half 3) an hour of a writer's time. Yet -44-

/lp/association-for-computing-machinery/standards-rehashed-KbrawCLVIU