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.
Sarah Bouchier wondered: <<What is the best way to ensure that each
document has a unique ID?>>
Why, to give it a unique ID, of course! <gdrlh> Oh, you wanted a
_helpful_ answer? OK, here goes:
<<I'm currently looking at introducing a scheme whereby all the
documents produced by the company (including those written by
developers) have a unique ID, but I'm having difficulty working out
how to ensure uniqueness.>>
I've done this for many years without error, so here are a few thoughts:
First, assign one person the responsibility of handing out the ID
numbers or codes. The more hands involved in this process, the
greater the likelihood of error. If you have a staff librarian,
they're a great person to do this job. It's also possible to automate
this process with nothing more complex than a spreadsheet or database
file publicaly accessible over your network. Database files are a
better option because they provide better access control, better
validity checks, and better access over a network. They also usually
allow more automation, such as automatic generation of ID numbers
according to an algorithm that you define.
If you populate the first column of the grid with pre-generated
reference numbers, and leave the second and subsequent columns open
to hold titles and other relevant details (e.g., release dates),
people can pick their own reference number simply by typing the
report name into the next open field, followed by any other details
you might find useful (e.g., version number, release date). Once
details (including the report ID) have been entered, they should be
locked so that only the owner of the file can easily overtype
existing records. In addition, someone must still take responsibility
for cleaning this file periodically to detect and eliminate errors,
and someone must take responsibility for ensuring that nobody
(whether the person responsible for maintenance of the file or an
author copying the ID into a report) screwed up the report number.
That's harder (impossible?) to automate, and even your librarian
needs someone to backstop them and look for errors.
Second, design a simple ID system that contains all the relevant
details for identifying a report. You'll have to poll a bunch of
people in different roles (from writers to managers) to find out what
those details must be. These details should be easy to understand too
-- use mnemonics, not numbers. For example, at a former employer, we
had a technical note series and an internal report series, and the
prefixes for their report IDs were TN and IR, respectively. The
report number was then appended: TR-247, for instance. For internal
reports, there was usually a date rather than a number (for reasons
that don't bear close examination <g>): IR-2007-August-3, for instance.
The goal of using simple and obvious abbreviations is to eliminate
the need for anyone to memorize an obscure coding system. Compare the
abbreviation I use for my editing book (below), namely EOE-May 2007,
with the book's ISBN (978-0-9783227-0-0): both serve the goal of
uniquely identifying the book (though the first one only does that
for me), but the former is much easier to remember and understand.
----------------------------------------------------
-- Geoff Hart
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
www.geoff-hart.com
--------------------------------------------------
***Now available*** _Effective onscreen editing_
(http://www.geoff-hart.com/home/onscreen-book.htm)
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
