Ultimate Collaboration Tool

HOME
 
Contact

modified: 2013/08/2

[update: it seems something rather similar to this is being implemented by google: Google Wave!]

People that want to work together want to communicate, and produce useful outcomes from that communication. Often these are 2 separate 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? Whats new? Async? Dir ect? Scal able? Priv ate? Organi zation? Access rights? Off line? Media? Exp ort? Navi gation? Hist ory?
Email ************************************ * 
IM *********************** *******    
IRC ********************* ******    
(web) forum **************** ******* *****
(web) wiki ******** ***** ****** ****************
(web) blog ************ **** ****** *** **
network filesystem/sync * ***** **** ****** ********* 
Source control / CVS ********************************* *******

So how would the Ultimate Collaboration 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 work flow 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 communication 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 web server, 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 collaborations 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 truly 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)
  • File system/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 simultaneously (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 synchronization with the file system 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 file system based continuous CVS client, using normal text editors that auto update from file system updates. Except that wouldn't work for edits unless you press save all the time, or some auto save 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 source code. 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