TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: checklist for templates From:"Dick Margulis " <margulis -at- mail -dot- fiam -dot- net> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 15 May 2002 15:21:18 -0400
Been there, done that, PV...
A few things off the top of my head:
1. Do not confuse the template with the guideline for using the template. Provide two separate files, in other words--an actual template that includes pro forma headings, styles, fields, etc.; and an example document showing the template as it might be completed, with instructions, commentary, callouts, etc.
2. KISS. Do not design paragraph styles as if you were going to use the template yourself. Stick pretty much to the default Word style names. In fact, for the engineers' input template, you might even stick to the default Word style definitions. Then, when you attach your own spiffed-up publishing template, everything will turn pretty as if by magic.
3. In the guise of explaining the program for which the engineers will be writing documents, slip in a lesson about using styles rather than doing a lot of manual overrides of "Normal." Show how this simplifies life for them (don't talk so much about how much grief it saves you).
4. While you're at it, make sure you explain what a template (.dot) is, where to store it on their systems, how to invoke it when creating a new document, etc. Many's the time I've seen engineers blow up because they were trying to save all their work _in_ the read-only template and couldn't figure out how to save a .doc.
5. If you have multiple _kinds_ of documents, provide multiple template/guideline sets. But keep the underlying style template the same throughout.
6. Provide an overview (org chart, flow diagram, Gantt chart, whatever else seems appropriate) that explains the relationships among the documents, the purposes to which they will be put, and the roles of the individuals involved.
HTH,
Dick
"P V" <p_v_1551973 -at- hotmail -dot- com> wrote:
>
>Hello fellow members,
>Our project is about to embark on the creation of a template for documents
>related to software engineering. These documents will be mostly laying out
>and describing proces guidelines. Has any of the honourable members been
>through this exercise before?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
