Cook Computing

Document Management

November 22, 2002 Written by Charles Cook

Chris Sells recently discussed the limitations of hierachical forms of data organization. This was interesting because several years ago I worked on a document management system which attempted to address this problem. In this system a document existed in its own right without requiring the concept of belonging to a container in a hierarchy. Obviously some form of organization was required and this could be achieved in two ways. First, a document could have one or more parents, each parent being a folder or another document, the latter specifically to allow for composite documents built up via OLE linking. So although a hierarchy could still be implemented you could develop a much more network oriented organisation of your data. This was useful for creating different views of your documents which gets away from the idea of the often too limiting strict hierarchy.

Second, and more significant, was the concept of search folders, where the contents of a folder were based on search criteria which were evaluated each time the folder was opened or refreshed. The search criteria were of various types such as ownership, date created/modifed, title, document type, size, description, keywords, and even content which is where I came in: I had ownership of the separate UNIX-based document store which performed full-text indexing of the documents. I seem to remember that the system also allowed you to request notifications to be sent whenever the contents of a search folder changed but this may be wishful thinking.

Was it successful? Yes, I think it was. If you were lazy or had better things to do than spend all day tidily organising your folders you could just chuck documents into the DMS and rely on the search folders to do the work for you. I wish I could do that now with the thousands of documents I have archived. Windows does provide searching for documents based on various criteria but the searches are transitory and the UI is not integrated into the standard Windows Explorer application, so it pales into comparison with a more thoroughly implemented document management client. Ive seen reports that a future version of Windows is going to have a file store based on a database so maybe things will get a lot more interesting in this area.

The key to all this is the user interface. Clever interfaces which appeal to developer types simply just dont work with the vast majority of users yet how do you present concepts like these without a complex UI?. The client of the DMS I worked on also had to handle both versions and revisions of versions of documents (but well worth it because this is so much more powerful than just providing a single level of versioning) so you can imagine how difficult it was to convey all these various complexities in an understandable UI.

I could do with a screenshot to refer to because my memory of the UI is a bit hazy now but the main problem that comes to mind was that the UI did not show the parents of a document very satisfactorily, so browsing in this direction was difficult. Thats speaking as a developer of course. Maybe the concept of a document being accessible in two or more folders would be completely alien to the average user and any attempt to represent this would not have worked.

When I scan over the thousands of documents I now have stored in the archive hierarchy on my hard disk its obvious that I need a much better way of managing this data. Maybe I could do a lot better using the inbuilt indexing facilities of Windows and the ability to create links in the file system but I would still be missing the ability to add metadata to files and anyway it all seems like too much work.