Martin,

Agree that my post has the potential flaw in that if someone fails to use the hashtag or makes a spelling mistake then it doesn’t work.

NOTE: you only have to use the hahtag for new posts, not comments

I was trying to think of a method that is not pre-defined, but instead the user can define it. But not by the user being able to build a task type app, instead I was thinking of the most simple way to coordinate work. People often don’t like visiting group spaces, with members, permissons, etc…Rather than have to find and visit a group space to say something (which you don’t have to do in email), I was thinking about making it as dead easy as email (one window to post content, just tag it to file it into a channel)

Anyway my posts are first draft ideas..not sure if they work until you get to play with them.

Paula,

I don’t know traction well enough, I do know that it’s a very granular tool and allows the user plenty of structural freedom…but have not played with it.

I’ve watched a few traction video clips, but not one’s based on the functionalities expressed in your comment.

But I have read the Kuka case study, which has a flavour of what you talk about.

The Traction team covered this angle by originally partnering with FAST Search. But since Microsoft does not support the 3rd-party vendor OEM model, this partnership has been replaced with a related (as in same DNA) product: Attivio.

To be fair to the truly brilliant at Google, there are pockets of intelligence who have covered some of the limits of their search algorithms through new solutions. The semantic recommendations that Google offers — this is fundamentally the same sort of approach that FAST and now Attivio has taken. The underlying premise is the “zero-term search” — no need to search at all if relevant answers have already been presented for questions you haven’t yet asked. http://www.fastforwardblog.com/2008/02/25/better-shift-the-attraction-economy/

But focus on the architecture. Don’t look for a self-service demo, it’s contextual. It makes more sense when you see it framed for the potential of a particular context. Otherwise it can look like those 3D images from the 90s (that it took me the longest time to ’see’).

The Traction team has done architecturally what we told vendors was needed in the mid-90s: All software has been ‘optimized’ for a particular set of assumptions. For a business to be ‘unique’ (the whole goal of a competitive marketplace) it cannot rely on fixed, predefined tools. Stop creating ‘finished’ products. Build functions that we can refine for ourselves (especially the UI).

The problem with building such a solution is that everyone judges tools by the UI — they’ve been trained to do so, because for most tools if it’s not to be seen in the UI, you have no hope of accessing it. For a well-architected solution, that’s not the case.

The next problem begins with the fact that few resources in IT think architecturally — they’re minions of binary code.

Hashes, tags and labels (folksonomies) within collaborative programmes have transformed the way in which granular information can be managed, but it’s not always easy to get people to use them, and use them sensibly.

In my experience, folksonomies often fall down because people feel that’s it’s just too much to think about on top of every other aspect of their work or the project details. I use them a lot, but am not sure others feel the same devotion to them as i do )

An interesting post anyway…