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.)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
