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.
> -- $<<The forms in the online manual are well organized and the
names *should
> -- $be* irrelevant: they should just find the title of the form they
are looking
> -- $for in the manual (e.g., Expense Report for Case Managers),
click the link,
> -- $and the form opens for them (they currently don't even have
access to the
> -- $lookup table--they shouldn't need it).>>
> -- $Sounds like a good design. If the lookup table is just for your
use (or your
> -- $successor should you move on to larger forms <g>), I'd recommend
using names
> -- $that you will recognize without having to consult a lookup
table. You'll
> -- $still need to produce the lookup table so that future
maintenance of the
> -- $online manual is easy. Don't know about you, but I have trouble
remembering
> -- $file names from week to week, let alone from year to year. (Call
me Homer!)
I'm jumping in just a little bit late here, but it seems to me the
naming convention should try to anticipate how people describe the
form in question. Because we are no longer limited to eight character
file names, there is no need to scrimp on the description.
So, how do most people describe the form? Many years back, I used to
deal a lot with a form called a Document Transit and Receipt (DND
728). In the office, we just called the thing a 728, hence, if it was
in a file called "Document Transit and Receipt.doc," chances are most
of us would have trouble finding the form. At the same time, calling
the file 728.doc might confuse new staff who may not yet know the
number.
[snip]
> -- $<<these are remote users that do not have access to the
corporate network
> -- $and do not have Internet access.>>
> -- $Scratch the intranet, then. <g> Sounds like we're back to the
CD!
Maybe not. Can the remote users dial into the corporate intranet? If
they do, and they dial into the intranet on a regular basis, say to
collect e-mail using a package like MS Outlook, they could update the
form files at the same time. To add to Goeff's suggestion, a friendly
programmer might be able to write a script that would check the
corporate intranet site for new versions of the forms, and do updates
to remote users' PCs if it finds some.
Just a thought.
--
John Fleming
Technical Writer
Edmonton, Alberta
email: johnf -at- ecn -dot- ab -dot- ca
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17) http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by ForeFront, Inc., maker of ForeHelp Help authoring tools
for print, WinHelp, HTML Help, JavaHelp, and cross-platform InterHelp
See www.forehelp.com for more information and free evaluation downloads
---
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.
