[Design] Chandler as a Managed Workspace

[Phillip J. Eby]

At 03:41 PM 1/7/2008 -0800, Jeffrey Harris wrote:
>Hi Folks,
>
>>Note that this approach puts us in competition with intranet 
>>software, CMSes, virtual meeting software, Lotus Notes, and that 
>>thing that was made by that guy before he went to Microsoft...  Ray 
>>Ozzie?    What was that thing he had that was a sharing 
>>platform?  Groove, or something like that?  Is it still around?
>
>I think I've read stories about Groove still being popular in the 
>military, because of its encrypted P2P bits.
>
>I agree, focusing on a shared workspace does put us in the same 
>space as all the things PJE mentions.  Is that bad?  My sense is 
>that people get pretty excited about shared spaces, but with the 
>exception of Groove they're all aimed at *really* large groups.

My sense is that, feature for feature, we don't stack up well against 
such tools.  Either, as you say, they're for large groups, or else 
there is an increasing tendency towards real-time collaboration, like 
virtual whiteboards and collaborative editing.


>>One of the very first problems we'll hit in that space is that our 
>>conflict resolution isn't fine-grained enough to support this kind 
>>of collaboration unless it's synchronous or there's just one person 
>>managing a given project.
>
>I agree that if we're encouraging people to manage small projects as 
>one item's text field, our text field conflict management is inadequate.
>
>Still, I really like the general outlines of Chandler's existing 
>triage workflow, especially as it relates to group project 
>management.  If we could prioritize oft-mentioned but 
>never-implemented clusters, I'd be a lot more satisfied, and I think 
>some (though certainly not all) of the impedance mismatch between 
>Chandler's feature set and GTD practitioners desired features would go away.
>
>Clusters might change the frequency with which detail view conflicts 
>happened.  I think conflict management for notes fields would still 
>be an issue, but perhaps not so bad that the still-incomplete system 
>wouldn't be useful?

That's certainly a possibility, but I think that before we spend any 
development resources on implementing such a thing, we'd better know 
how we'll sell it, and to whom.

My suggestion is that what we need now is a *demo* -- a short 
walk-through of the application that will sell it to a target 
audience, to identify rough spots and to sharpen the pitch.  We could 
have more than one, of course, to try out different slants or 
audiences.  But having demos will get us focused on something 
*concrete*, rather than the general ideas of this feature or that 
feature.  We can talk about whether or not the feature actually helps 
a specific demo script to achieve its goal.

I recently read an interesting book written in 1937 called "Tested 
Sentences That Sell": it's a fascinating look at what we might 
nowadays call elevator pitches.  It said that you have about ten 
seconds to get someone's attention, and three minutes to sell them 
before they get bored.  So three-minute demos sound about right.  :)

(Of course, complex software can't be taken all the way to a purchase 
or setup commitment in three minutes, but all you want in such a case 
is a commitment to investigate or evaluate the product.  That is, the 
user should decide they want to try it out.)