People that want to work together want to communicate, and produce useful outcomes from that communication.
Often these are 2 seperate steps, and we would benefit from them being more streamlined.

There are many tools available, which all fall short in some way or other:

• Alert new? asks how easy it is to figure out that someone else created new content in your collaborative space. IM does best here because it is immediately intrusive, as do email & IRC because they have specific clients that can alert you to new content. Web based collaboration does worse here because it has no special client, the user has to go the a page to find new things (web based tools often resort to sending you emails to alert you to something new, which is clumsy and polutes your email). So clients allow the user to be passive, browser based requires them to be active. Since users are often lazy/busy/forgetfull, passive mode is the most efficient. So the ideal tool should have its own client, that can be configured in detail about its intrusiveness and what items to alert on.
• What's new? is about being able to seperate the old from the new, once you are checking the collaborative space. Clearly here the tools that present things in (reverse) chronological order work well, whereas those that represent information purely hierarchically are problematic. So the primary view of the ideal tool should first show whats new in chronological order and/or what is "unread", even if the base structure is hierarchical.
• Async? asks wether I can work well asynchronously, i.e. if someone produced content yesterday, is it easy for me to work with that today? Only the chat tools have a problem here. The ideal tool should therefore make information less temporary than current chat tools.
• Direct? is almost the opposite, and asks wether the tool can be used to have immediate feedback communication. The ideal tool should also allow updates to appear instantly, and you to see that someone else is producing updates (a nice thing to have is to show who made the most recent changes and how long ago, so you can tell when people are active and you expect interaction from them).
• Scalable? asks how suitable the tool is for communication with significantly larger number of people than just 1 on 1.
• Private? asks how easy it is to have private 1 on 1 communication, or to restrict conversation to a subgroup. The ideal tool should have both.
• Organisation? is about how useful the information is / how easy it can be accessed/edited as a knowledge base afterwards, once the chrological view is no longer relevant. Wiki does best here, a filesystem works too but only rather clumsily. Clearly an ideal system should allow information to be added in a mixed chronological & hierarchical format. Herein lies the biggest challenge.
• Access rights notes wether it is easy to restrict who can modify what. The ideal system should allow people to create groups so that access is easily assigned to more than one person. Access should be hierarchical in that whoever creates a page is responsible for assigning access, which then by default holds for pages linked from it. This also reduces the "system administration" load by letting multiple people organize their own little corner.
• Offline? is about wether you can work with the information conveniently offline as well, which only really email does. The ideal tool should have a cached copy of all items on the local client, and poll every N seconds or so for new information, and automatically upload/download changes to all clients, when online. Offline work should work normally, without updates. Infact, people can use the tools for private information databases that are never synchronized with a server (but optionally can be, for easy backup purposes).
• Media? says how easy it is to work with media other than text in the format. Clearly it should be easy to mix in at least images, but ideally any file.
• Export? is about how easy it is to convert the stored information into a new format readable outside the context of the original system. Pretty much all systems are lacking here. The ideal system would be able to export to static html/xml, maybe pdf, or even seperate files (when used in the CVS sense).
• Navigation is about how easy it is to browse information, and go between two particular related items. Most systems fall short here, except the wiki. Even the wiki could be improved, in that if you use many small pages, its hard to keep an overview. It would be better if small child nodes (links to small pages) could be shown inline in the parent page, and folded/unfolded. This would also be beneficial for generating other formats.
• History? when edits are made, how easy is it to see who made changes, when, and where. This really only holds for tools that allow Organization (see that column).

So how would the Ultimate Colaboration Tool (tm) work?

From the above, we can see that of all the tools, the wiki is the closest thing to ideal, but it has several shortcomings. So lets see how this tool would be different from a wiki (remember, often changes that may seem small and insignificant can bring a tool from useless to useful in a certain workflow context):

• It would not be browser based, but would be a client you install. This has many advantages as indicated above, but primarily:
  • It would be always on, always there. The more direct access makes the tool more useful than having to load up a web page
  • It would have very customized alerts.. certain pages/areas being updated, certain people, in certain groups can make the tool blink to alert you to comminication that may benefit from direct interaction. All the other updates (by default) will just show up as new when you actually open up the tool.
  • It would be faster to browse around in. Not just because its a native tool, but also because the database is cached locally. You should not be dependent on the current network bottlenecks to access vital information.
  • It can more easily include all sorts of custom functionality.
  • It would allow showing direct updates to text as people type, no more waiting for posts to appear. More immediate than IM, and no unexpected update clashes.
  • The client and server being simple applications as opposed to requiring to be installed as part of a webserver, makes it easier for small groups to set these things up independent of system administrators.
  • You can use one client to stay connected to however many colaborations you are involved in
• It would show hierarchy (in the form of a tree display) as well as focus on a particular node.
  • A wiki is a graph, not a tree, but this simply means you can reach a particular node via multiple paths from the root.
  • It would not be just a simple "windows explorer" style tree, but something which is more context sensitive to your recent browsing, and can more easily show multiple levels of siblings at once for quicker browsing (see "Ultimate tree display" elsewhere).
  • Any level can of course be folded/unfolded
  • Any node will show in clear different rendering the amount of nodes that have changed since you last looked at them. Looking at them will clear the "unread" flag and update parents accordingly, so it will be very easy to see whats new at all times. Alternative ways for showing nodes that have content you want to be alerted to, i.e. people that are trying to communicate with you interactively.
  • Nodes can display child nodes "inline". This allows you to create truely hierarchical documents, using the tools hierarchy rather than things like bullet points and tables to represent the inherent hierarchy in text. It always seems strange that wikis are so densily structured, but then individual pages can then become old fashioned monolithic flat documents again.
• Nodes have hierarchical access restrictions
  • Whoever creates a node, becomes the owner. By default, only the owner can change the contents of that node, but everyone can add children.
  • Who can change a node and who can add children can be easily changed to any subset of everyone.
  • Any child nodes, recursively, that have access permissions at "default", inherit the permissions of the parent. By setting the permissions explicitly you override the access permissions. Any node with two parents (as can happen in a graph) will have access permissions of the owner.

So how would this tool emulate existing ones:

• Wiki: it is already very close to that, just with many extra benefits.
• IM/Chat/IRC: create a node that has read/write permissions only for a particular group of people. People can add to the chat by simply hitting the "add a child node" shortcut. Updates will appear instantly.
• Forum: pretty much the same as chat, really. For threaded discussions, you can additional do add a child on a particular post, rather than on the main node.
• Email: again, very similar to chat, this is just back and forth messages between you and a particular other person (or persons) on a private page.
• Blog: similar to a forum, but the main set of children is read only for all visitors (but comments can be added to the child nodes)
• Filesystem/CVS: The graph can contain images and other file links, and can be mapped/exporter to a set of files with the same hierarchy.
• CVS. automatic rules saying that text nodes ending in certain extensions (such as .cpp) should be exported as vanilla text, so that the tool can be used by multiple people editing code simulateously (unlike normal CVS, would not require a per-file lock or merge!). Additionally, every bit of source code can have chat threads, documentation nodes etc directly associated with it, or handy links to related files for external functions, etc. A simple command can ensure synchronisation with the filesystem such that compile tools can be invoked.

Todo:

• Think about how having a stream of updates being merged into a database can potentially have weird consequences esp if people make offline modifications... need diff style merging like CVS. System becomes quite like CVS then except updating is continuous. Updates would have to go via the master database and then be applied back to the local one to avoid out of sync data. So local edits are always temporary until committed. Could make a system like this not as an UI but as a filesystem based continuous CVS client, using normal text editors that auto update from filesystem updates. Except that wouldn't work for edits unless you press save all the time, or some autosave set to every second.
• There may need to be a way to checkpoint trees if this system is to be used instead of CVS for sourcecode. For most other data its not as much of an issue.
• Besides hierarchy, dynamical queries should be supported as an organizational tool
• Ways to embed images and any files... probably best if they are stored in the local filesystem instead of the database