The Ideal Document Management System?

We have been in the documentation industry for many years, and we are now seeing a common set of requirements for a document management system, which no product seems able to fill.

DMS products come from two directions: products like Robohelp and Frontpage come from a 'build and present' direction. Their focus is on allowing an author to construct a document which more than one reader can access. There is a strict split between an author session, and a reader session: a reader can't edit the document without launching a different executable.

The 'build and present' products are strong on presentation. They provide features like searching, and an expandable table of contents (a tree structure like Windows Explorer on the left of the screen, with the actual page content on the right).

The other direction that DMSs come from is 'store and retrieve'. Products like Docushare, Notes Domino, and Sharepoint allow a single user to be both the reader and author in the same session. But they're poor on presentation: typically they treat documents as binary files, the result being that the user can't see the content of the file until it has been 'launched' on their desktop.

Organisations have a requirement for their policies and procedures documentation to be presented online in a form which is both searchable and has an expandable table of contents, but which does not make a distinction between 'read' and 'edit' sessions.

There are products that allow this kind of flexibility, but they are very expensive, and difficult to administer. What we need is something simpleminded.

Why is this important?

In implementing systems of policies and procedures (and implementations of ISO9000, ISO14000, AQTF, Privacy Act and other legislative compliance, etc, are just sets of policies and procedures) we have found the following to be true:

policies and procedures only work if they are easy to find, and easy to change

"easy to find": No-one is going to get any use out of a document if they can't find it. Many systems take the internet approach to document retrieval: put all of the documents into a 'bucket' and then use a search engine to find the one you want. The problem there is that the wheel gets reinvented too many times, and when you go looking for a wheel you get a hit on each wheel that's been invented.

And you have to know that the wheel exists, and what it's called, before you can even look for it.

A structured table of contents is a much better approach, because it forces you to look at the material that's already been developed before you decide to reinvent it, and because it lets you find things by subject, rather than by content.

The 'build and present' products are good at letting people find documents, but the 'store and retrieve' products are bad at it.

"easy to change": The harder it is to change a document the less likely it is to happen. With the best will in the world, a user who spots a minor error on a document will only fix it if it's a click or two away from being edited. Having to check out the document, launch it, edit it, then check it back in, is just too hard.

Documents with minor errors are hard to take seriously. Minor errors get left, and major changes are too hard to make as well. Soon the document is well out of date. That's what often happens with documentation - it gets drafted in a burst of enthusiasm, and then just sits there unedited until eventually it's scrapped. The primary health check we use for systems of policies and procedures is this: do all the documents have different, and fairly recent, publication dates? If they do, then it's likely a 'living' set of documents.

The 'store and retrieve' systems are bad at letting people change documents, and the 'build and present' products are awful at it.

Something better

Here's the scenario: Rose is Engineering Manager for a medium sized firm. She knows one of her staff is coming up for long service leave, but she's not sure how long it will be, or when it's due. She launches the document management system on her screen, and opens "HR", then under "HR" she looks under "Leave entitlements", and so on until she finds what she's looking for - when she clicks on "Long service leave" on the table of contents, the page on the right immediately shows the information she's looking for. She can view or print the document, but she can't edit it.

There's a link on the page she's looking at to "Management policy on long service leave" and she clicks on it. The system checks (from her NT login) whether she's allowed to view the page. She is. The right-hand pane changes to that page and the table of contents changes automatically to match the jump she's just made. Again, she can view the document, but can't edit it.

Now Tom the HR Manager views the "Long service leave" page. Again the system validates his NT login, and allows him to view the page. On reading the page, he sees a minor typo in it. He clicks a button at the top of the screen, and it changes to edit mode (which he's allowed to do because as HR manager, he's 'owner' of all of the HR documents). He makes the edit, then clicks another button to commit the change.

He then realises that the typo may also have ended up on the standard induction letter for staff. He uses the same table of contents to find the letter, which is a Word document. When he clicks on the table of contents, the right-hand pane shows the Word document (in Word). He puts it into edit mode, then saves the changes.

Further requirements

That's it in a nutshell - the ability for a single interface to allow viewing and editing depending on the user's level of authorisation, and to provide an 'expandable table of contents' interface to the documentation.

Other requirements are detailed below.

Security

The system should use the NT login of the user to grant access (Imail uses this method).

View, edit or administer authorisation should be for an NT group for a particular part of the table of contents. An administrator should be allowed to set view, edit or administration privileges for any part of the contents over which they have control.

Installation

The system must be easy to install on a client machine. Ideally, it should self-install as a Java applet via a web session.

Metadata

Documents when created should inherit metadata from the branch of the table of contents in which they are created. Branches should inherit from their parent branches.

Metadata fields should be user-customisable.

The system should allow flexible reporting - generating lists of documents sorted/selected by metadata and built-in data.

The user groups that are allowed to edit and view the document should show up as metadata fields, as should version number, last edit date, etc. The names of the individuals that can view and edit the document should also show up as metadata, as well as the last person who edited the document.

The metadata should be selectably visible on the view of the 'native' document, so that the system can be set up to show which user group is allowed to edit this document, when this document was last edited, etc.

Versioning and logging

Any edit (and optionally, view) operation should be logged. The log should be visible to anyone who has read access to the document.

Optionally, previous versions of documents should be stored.

Notification

Users with read access to a particular branch of the table of contents should be able to view a 'recently changed list' showing which documents in that branch have changed within the past year, and when.

Layout, linking

Some documents will be embedded Word (or other embeddable application) files. Others will be 'native' text.

'Native' text pages do not need fancy layout. They will need the 'vanilla' HTML set of layout features:

• bullets
• numbered lists
• tables
• bold, italic
• choice of typeface
• etc

Pages can have hyperlinks to other pages, but embedded documents need not.

Collision avoidance

When one person has a document (native or embedded) open for editing, it should be read-only to other users, with a message stating who's got it open for editing. Editing should time out, so that any file that's been open for (a selectable number of) minutes is unlocked automatically.

This article may be reproduced only with the permission of HCi (email HCi ). Copyright HCi, 2001-2.