There seem to be a number of questions around how to find information in e.laborate.  While the tagging idea is a useful solution, it does not seem intuitive for those used to tree navigation.  One example would be the question last night during the e.laborate training where one person was asking where meeting minutes should go.

It occurred to me that one potential way of bridging this gap is to implement sub-tagging and the related GUI widgets to take advantage of it.  I will explain what I mean by sub-tagging.

The way I think conversations in e.laborate is that they are containers of information that are not stored in any particular location.  Tags seem to be used as locations (especially in the case of groups) and conversations are anchored and aliased into these tagged locations.  Right now, when tags are associated to a conversation, there is no relationship implied between the various tags.  Basically this can be interpreted as a conversation belonging to multiple disparate locations.

If this were currently implemented as a directory structure, all the tags would be directories on the root directory, full of pointers to conversations (shortcuts if you want to think of them that way).  This is basically a flat structure.

If we assign relationships between the tags at the time they are applied to a conversation, we can infer a navigation tree within the tags.  This would allow the construction of navigation tools that would allow the user to drill down through this navigation tree.

For example, this conversation is posted to the "BSG Product Managment" group, but is about e.laborate, but specific to product improvements to the navigation.  So with sub-tagging enabled, I could tag it as "BSG Product Management"->"Product Improvement"->"e.laborate"->"navigation", BSGLock.  If there was a navigation widget that consumed this sub-tagging, when somebody visited the "BSG Product Management" group, they would see "Product Improvement"  as one of the nodes on the tree.  Drilling into that they would see "e.laborate", and finally "navigation".  Clicking on any one of these branches would retrieve the relevant conversations.

With the proper GUI controls, it could be fairly easy for a user to build out a sub-tag.  Also, if the editor controls consume the existing tree structure, making it easy for the user to select from the existing structure, this would improve cohesion.  This means the first user to sub-tag would define the default structure.

If you notice in my example above, I also include BSGLock.  This is to demonstrate that this mechanism would not conflict with the existing e.laborate functionality.

If we had this functionality in place, the answer to the question about where to place meeting minutes in a customer's group would be fairly easy.  The first meeting minutes would be tagged with "Company A"->"Meeting Minutes".  Then, when the users visit the group, it would clearly visible on the navigation tree.  When others post meeting minutes, that same tree location would be easily selectable when implementing the tags, just as existing tags are easily selectable now.