Treat the document as an information provider. Don't look to other systems to manage a document -- interrogate the document itself. Look at the Neuromancer project for parallels (see
Jim Waldo's Contrarian Mind for information on Neuromancer), where the edge device is an information provider. In a similar way the document becomes an information provider to the shell, not just to the user who opens it and consumes the "actual" content.
Every document has a database, or perhaps it is more appropriate to say that each document is a database. An LDAP or XML tree structure would be ideal conceptually, if somewhat cumbersome.
<document>
<data> [raw document content goes here]
</data>
<transactions>
<log id='1000000' datestamp='1121886227' name='create' owner='malk@null.com'></log>
<log id='1000001' datestamp='1121886227' name='email' owner='malk@null.com'>bloggs@recipient.net</log>
</transactions>
<attributes>
<attr type='note' id='2000000' title='Additional Info'>Should I change the colour?</attr>
<attr type='todo' id='2000001' title='Email Brian'>brian@nowhere.net
<attr type='alarm' id='2000002' title='Deadline' trigger='1121889000'>Don't Forget</attr>
<attr type='emblem' id='2000002' title='Warning' uri='file:///home/malk/pandafireman.svg'></attr>
</attributes>
<applications>
<app id='3000000' name='vim' datestamp='1121886227'/>
</applications>
</document>
Try to ignore the fact that I'm using XML to represent this information -- I am very well aware of its short-comings, particularly when applied to this problem. But it is a commonly understood format and therefore an excellent tool for articulating concepts to a wide audience. I'd also be grateful if you glossed over the details of the elements and attributes. This is not a design, it's an impression.
Other attributes:
- Attachments
- Links
- Labels (cf. GMail, BeFS)
As an aside, the technologies to support XML are quite mature, so it is not inconceivable to see tools such as Berkeley DB XML being used here. Not to mention the powerful XPath, XQuery and XSLT tools.
It would appear that BeFS provides a good foundation upon which to build an effective user experience with document-orientation.
Labels replace folders
Use labels to replace traditional folders functionality. Each label created is visible as a folder-like object on the desktop or from the command line. Provide a command line shell that also supports this model. Create a consistent metaphor between
GUI shell and command shell.
Preferred Application
Keep a history of the applications used to manage this document. Mime association is managed by the document itself, not by external systems. This means that the operating environment is only
used to suggest a default in the absence of any other information. Must be able to flatten the document for export to other file systems.
Attachments
Why not? I suppose it is a rather extreme extended attribute. It is more likely that one would embed a URL or some other linkage but it might be useful as a way of associating related material in a direct way so that the document overall is autonomous. Look at how OpenOffice / MS Office documents handle images, charts and so on.
Links
Special annotations that refer to other documents or material available on the network. Rather like the list of references printed at the end of any research paper or similar material. Any legal URI will do.
Notes
Post-its attached to the document. Or speaker notes. Or unfiled material. Or anything, really. Just a short item of text that has relevance within the context of the document.
To Do
A list of open/completed actions against the document.
Alarms
A reminder to do something on or near a given time. A deadline for completion, or a reminder to send the document to another department or print it out in order to send it in the morning's post.
Emblems
Nothing new here. A visual cue associated with the document. Could follow the document as an attachment. Could also be the document's icon.
History
I find that transaction history is an increasingly important aspect of document management and maintenance, both in my professional life and at home. The idea of being able to track changes is not new; CVS, ClearCase, Subversion, Arch et al. are testament to that fact. I use CVS every day as part of my system for organising almost every document that I maintain, regardless of its type or purpose. It's a little cumbersome to have to remember to checkin changes every now and again, but it's worth it for the extra flexibility and power that tagged files and history deliver.
It's a bit much to expect that any file system is going to automatically record all changes to a file and also maintain that history within its own internal structure. But at the least there should be some sense of when changes were made and by whom. What software was used to make those changes?
Another aspect of document history will be who sent the document to whom. To whom did I email this file? From whom did I receive it?
Privacy
(This does not represent a thorough examination of the right to privacy and how it affects the design of a document-centric operating environment. It is a simple introduction of the topic.)Privacy is an important right and one that requires careful consideration. It will be necessary to provide auditable facilities to manage the contextual information. Users must have the right to erase history, attachments and all other metadata. We have to be able to flatten the file, which in this system would mean presenting only the contents of the data element. A flattened or exported document is presented and stored in exactly the same way as any other document currently in existence -- without metadata. We need the Anonymiser. Or Flattener. Or... You decide.
As a corollary, it should also be possible for users to lock certain attributes that they have contributed. The transaction that records the original author should be immutable, for example.
