Being an architect, I'm used to dealing with thousands of documents on a project. The only meaningful way I've discovered to organize those documents is by the flow of work they are being used on, which is what we do. It is especially important when dealing with multiple companies on a single project. Folders and nested folders are a paradigm of the low-productivity windows way - we tried this, it never works well. But document management is really only a small feature of a larger integrated application that guides users through the larger workflow of getting projects done.
Oh, hmm. It would be kinda cool to separate the document management from the workflow ... like, build a document management system with an API, and then create various user interfaces that could interact with it according to different applications.
I think that is the future - many smaller apps integrated together as features within a larger comprehensive application. Integration is the key to really getting productive as opposed to having multiple disconnected apps.
On that note... We actualy have an XML API, though it's not quite public yet... We'll get around to tidying it up and making it public sometime, though...
If you're interested in writing something for it for your clients (with the caveat that it's not even in beta stage... though it appears to work), I can probably send you a ruby example that interacts with it... Let me know via our support link. :-)
Hey, Daniel Tenner here (author of the article), and one of the technology guys behind Woobius.
We hit the same problem with folders-within-folders getting too complicated, but we tried a subtly different solution. All of us use tags in things like GMail, but the funny thing is, we end up using them like folders (in fact, I have my tags in gmail mapped as folders in Mail.app).
So what we did on Woobius is we implemented folders, but we restricted them to one level. So far, a handful of people have requested folders-within-folders, but the majority seem happy with the system as it is, and the big advantage of getting rid of that messy folder hierarchy is that it's made the system look a lot simpler and quicker to use.
Would love to know your thoughts on whether that works for you.
Treating tags like folders isn't really bad; you might not be using them quite to their fullest extent, but you're also not really limiting yourself when it comes to categorizing data.
...which is where the single-hierarchy folder system wouldn't work, because it does create a limit.
I like to think of it this way: currently, the paradigm (I hate that word) is that you have a folder -- a category -- which owns lots of files. What I want instead is to have a file which owns lots of folders -- or categories.
The one client I mentioned in my Disqus response is doing some energy research, government contract and all that. They really need to keep things well-organized, and they need to be able to organize drawings, specs, notes, graphs, test data, etc. etc. by project, by contributor, by date, by revision, by ... etc. etc.
Another client is a doctor's office, and that's probably all I need to say about that. :-)
So, no. While a one-deep hierarchy solves some problems, it's still clutching on to a silly way of organizing things, without actually providing the flexibility of a really intelligent tagging system.
Ultimately a folder (or a tag) is just another piece of metadata, like the ones you listed-- project, contributor, date, revision, etc.
The core issues are input (how do I get this metadata attached to the content? dragging to a folder, document analysis, filesystem metadata, tag autocomplete) and retrieval (how can I quickly sort and filter to find the document(s) I need, based on some set of metadata criteria?)
Whether or not that metadata has a hierarchical structure (a taxonomy/vocabulary), and whether that structure is controlled (e.g. only privileged users can create new terms) is secondary to the question of speedy, usable input and retrieval.
I worked with Documentum document management systems. Tags are critical to being able to retrieve a document once it's scanned in. The problem, of course, is mis-tagged documents.
Right, mis-tagging is a process problem, not a software one. At least, I can't think of a software way right now to solve that.
...Although, like you mention above, being able to find documents quickly can make it much easier to handle. For example, the UI should give you the ability to show all documents modified in the last N days, by user X, etc.
