|

| |
What is it?
The term "Documentation" is usually applied to a written description of what
an item, function or service is meant to do, and how it is supposed to be used. "Open
other end" at the bottom of Swedish Coke bottles is documentation; the workshop
manual for your new Imperial Blue Ford Fiesta ST is documentation, just as the User's Manual
for your new Toshiba Satellite Pro is documentation.
I/we will translate a wide range of topics, but when it comes to writing -
authoring,
if you insist - documentation, I am limiting myself to a narrow field: The creation of
User Manuals for Windows-based application software within certain specific
fields.
Why use external resources?
 | Avoid the cost of full-time personnel when the time required for document purposes is
less than a man-year per annum |
 | Avoid staff expansion to cater to short periods of high activity |
 | Tie documentation to projects, for monitoring progress and cost |
 | The end result of the competence is retained in the business, in the shape of the
finished documentation |
Procedure
The documentation writer will typically join the team of developers, to extract their
knowledge of the product in order to condense it and convey the knowledge to the
users.
Prerequisites are general knowledge of Windows, a clear and efficient writing
style, solid
knowledge of the tools employed, and about various target platforms or media. The most
important knowledge remains the product knowledge that resides with your
developers, and
sometimes with your customers. This is the knowledge that the technical writer needs to
attain, and commit to paper. Which is really a figure of speech; paper may yet become the
only medium not used for certain types of documentation.
- Microsoft Word
- Intimate knowledge of the tools is important. If you need a different tool than MS-Word
for your documentation, you also need a different writer.
- WinHelp, HTML help, or...
- Both, and more. What you will need from your technical writer is knowledge of different
target platforms, and what are the features, benefits and problems with each
one.
- RoboHelp? Doc-to-Help?
- These are two leading tools for the development of help systems based on user guides
in the shape of Word documents. Each has its strong points and weak points; tell me your
priorities, and I'll help you select. I hold full licences for either; if you wish to
maintain the finished help system yourself, you will need your own licence for the product
in question (in addition to Word, of course).
References
- Siemens Business Services
- Formerly Siemens Nixdorf Information Systems, earlier still Nixdorf
Computer; was home
to the software development group DocuLive, which made client/server software for document
management, case management and workflow management with users in private industry as well
as in local and central government. User guides and help systems were
authored by yours truly,
partly as external resource, partly as employee, through the end of 1997.
- Telenor Mobil
- Following up on the immense success with MobilKontor (Mobile Office), Telenor Mobil
chose to develop its own MobilKontor 2. The development task was assigned to A/S EDB, who
were quietly advised to select the same writer that was responsible for the localisation
of MobilKontor 1. All told, Telenor sold a five-figure number of these software
packages for those early adopters among us who needed constant email access without benefit of
cables.

|