Need sources for document naming/storage conventions?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Riça Night (long time no see, RN!) reports: <<The department I'm helping
out... recently realized that its knowledge management and/or document
management has been poor to nonexistent. In an attempt to remedy the
situation, they've embarked rather precipitously (read:without adequate
planning or understanding of the implications of what they're doing) on a
project that they think will remedy the situation. To wit: they're going to
centralize all departmental documents (which are currently scattered on
about a dozen local hard drives) onto one big server--or maybe it's just a
drive--that will live on the hospital's already-established network.>>

Knowledge management is a specialized domain, and any advice we can give you
on naming and storage conventions is only a stopgap measure for a proper
system developed by someone with library or archive experience. Given that
you're working out of Toronto, you might want to contact Ryerson College (I
believe they're the one with the certificate in archival studies--if not,
call the provincial archives and ask them for a referral). It's quite likely
that one of their graduate students is willing to consult with you on this;
sometimes you can get free or inexpensive expert consulting work from
someone up to date on the latest technologies in exchange for giving a
student a real-world problem to solve en route to a thesis. (And perhaps a
future job with the hospital once you graduate. Talk about win-win!) In the
mean time:

<<We need to develop a document-naming convention, as well as some
convention for naming the folders and subfolders (a.k.a. directories and
subdirectories), and *fast*!>>

Your first step should be to talk to the various people who originally had
the documents on their hard drives, as well as to the people who will be
seeking these documents, to find out how they usually approach the task of
retrieving a document. If they've been doing this for a while, they've
probably found relatively efficient ways to find information; even if not,
paying attention to how they frame the problem of searching gives you
important insights into the inherent categories in the information, and a
structure based on those categories will always be more efficient than an ad
hoc structure. You're not looking for answers like "I remember the date on
which I created it, and use the search function to find all files created on
that date"; what you need are commonalities in the organizing principles,
such as the fact that everyone (or almost) divides the information into
three categories such as admissions red tape, embarassing medical records,
and private jokes at the expense of patients. <g> Knowing the paths people
plan to take to reach information lets you develop a structure based on
those paths.

One key thing to remember about naming conventions: keep them as mnemonic as
possible. In the absence of an existing coding system that everyone knows
and understands, it's far easier to understand names based on a moderately
deep* but explicitly named directory structure (e.g., patient
records/children/male/patient 103) than to use a shallow structure with
cryptic names (e.g., 17-A5-01-103, with 17 being the code for patient
records, A5 meaning children, and so on). In the presence of such a system,
the cryptic names may actually be easier to use because people have the
codes memorized or already work with them every day, so you're not imposing
the additional burden of having to look up the codes. A particularly good
example is that if patient records are filed by OHIP number, it would make
sense to use that number in actual file names.

* There's always a tradeoff between depth and breadth; a deep structure
requires users to navigate ever deeper through many directories, which can
get frustrating and can really annoy people if they discover they have to
backtrack through several levels after they make a mistake. In contrast, an
overly flat structure can require too much searching among alternatives
before users can find the next level in the hierarchy; in the extreme case,
everything would go into a single directory, with no subdirectories--yuck!.
There's no one right answer for every situation, but based on my readings
(e.g., Jakob Nielsen, Jared Spool, others), I try to design for a maximum of
three levels of hierarchy.

You didn't mention what software options are open to you. If you can use
HTML, you can create an intranet that's supported by all standard HTML
tools. For example, you could use HTML Indexer (www.html-indexer.com) or
Deva Tools (www.devahelp.com) to create a really good index that would help
people find their way. The latter also includes a search engine that might
be very useful.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html

"The most likely way for the world to be destroyed, most experts agree, is
by accident. That's where we come in; we're computer professionals. We cause
accidents."-- Nathaniel Borenstein

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com

A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.  http://ieeepcs.org/2001/

---
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.