Services
If a project interests me I will take
on many different types of technical writing tasks, including the
creation of interactive electronic documentation, printed manuals
and also normal technical writing. With my background in journalism
I have also been known to produce articles for clients on request.
I particularly enjoy writing documentation for creative projects
that I find exciting, because then it's easy for me to communicate
my own enthusiasm to the user.
Help critiques
Outsourcing help authoring
services entirely can be too expensive for startups and small projects,
particularly in the shareware industry. I offer a flat-rate help
critique service that can help to improve the documentation of projects
like this at a very low cost. The critique includes an analysis
of your help and detailed suggestions for improvement. Email me
for more details (email link in the header above).
Development input
Even if I am not asked to make contributions
to development I always conduct exhaustive testing with the application
I am writing about — this is the only way to obtain the information
I need to be able to write the documentation. Since no software
product is ever perfect this usually reveals some bugs and glitches,
and if time allows the customer can often correct these while I
am still working on the documentation.
If requested I can also produce more detailed testing reports with
suggestions for functional changes and usability improvements.
Delivery
I deliver electronically, either via
e-mail or by placing the files in a password-protected area on my
web server for collection.
Electronic help formats
I do all the standard Windows electronic
help formats including HTML Help (my preferred format), Winhelp,
PDF, browser-based HTML and the MMHelp multimedia help format produced
by Help &
Manual, my help authoring tool. This looks very much like HTML
Help but has the advantage of being a stand-alone, single-file *.exe
executable that is ideal for CD-ROM based productions.
Unless you have a special reason for doing so I generally advise
against using the antiquated WinHelp
system for modern documentation products. Although browser-based
HTML is far from antiquated I have found that this is only useful
for special purposes, like website-based help systems. If I produce
browser-based HTML then I prefer to use "HTML Help clone"
version generated by Help & Manual, as it provides users with
a streamlined, familiar interface. Click
here for an example of this on the EC Software website. When
it is Resources section of my own website is ready it will also
be published online in this format.
Print Manuals
Almost identical online help and manual
There are basically two ways of producing
print manuals: The most common is to modify the online help slightly
and output it as a PDF or RTF file that is then used to print the
manual. This is by far the cheapest way: If you know in advance
that you also require a manual the help system can be authored with
variables and conditional text passages so that outputting the manual
version is almost automatic.
Different and complementary online help and manual
The second way is to
approach the online help and the manual as two related but different
projects. This is more time-consuming and expensive, but it also
gives you more flexibility and the result is a slicker, more impressive
product. Users tend to have a "ho-hum" reaction when they
see that the manual is essentially identical to the online help.
Keeping them related but separate allows you to make the online
help less extensive, shifting all the "study material"
to the printed manual. This is something that many users prefer,
as studying long passages on screen is often experienced as tiring.
|
