Re: What's the 'pony in the product'?

"Phillip J. Eby" <[email protected]> Fri, 28 Dec 2007 15:02:57 -0500
Newsgroups gmane.org.osaf.design
Message-ID <[email protected]>
At 10:33 PM 12/27/2007 -0500, Andre Mueninghoff wrote:
>My point is that I believe that those intent upon implementing GTD will
>implement GTD.

And mine is that those who are bent on implementing GTD and comparing 
software tools for it, won't find much of direct relevance to GTD in 
Chandler's feature list, compared to tools such as LB, MLO, or OmniFocus.


>Is not, however, much of this discussion about trade-offs? In support of
>the USP you suggest, I find the calendar integration in Chandler to be a
>practical advantage. In spite of all that is truly wonderful about LB, I
>began to migrate away from Life Balance when my needs for better
>calendar support outgrew what was available in LB during a time when the
>developers of Life Balance had other priorities. Also, seen as a
>practical advantage by large numbers of LB users, outlines became a
>practical barrier to me. It was becoming more and more difficult for me
>to find tasks and projects. Buoyed by seeing an explanation from David
>Allen about the advantages of simple flat lists over outlines, I was
>already migrating my GTD implementation in LB to flat lists when I first
>discovered Chandler. (Please know that I am not bashing the feature-rich
>Life Balance application, and that I am indebted actually to the
>"Llamas" [an affectionate name for the developers]. Nearly all of my
>top-level outline items in LB are Chandler collections now. I'm going
>into such specifics about LB in the interest of clarity in this
>discussion.)

Fair enough.  Having used both LB and 3x5 cards for GTD 
implementation in the past at differing times in my career, the 
advantage to LB was precisely the outline and automatic activation of 
tasks.  At the time, I was juggling part time software development 
work and full-time mortgage brokering, with many complex projects on 
both sides.  Oh yeah, and trying to put together a consulting gig 
too.  Anyway, being able to see what I needed to do when I was, where 
I was, wouldn't have been practical without the outline.  I bought a 
PalmOS PDA just to run LifeBalance back then, because I had a strong 
need for specifically that feature.

At other times, 3x5 cards have worked better when I had fewer 
projects and fewer locations to work from.  Sometimes my GTD 
implementation is a single piece of paper divided by required 
*effort* (e.g. 5 minute vs. 15 minute vs. 30 minute etc. tasks), now 
that I work entirely at home and usually only have a couple of 
projects rolling with any complex structure.

So for me, outlines and recurrence are pretty much the only reason I 
would even bother entering something into a computer to begin with; 
the payoff for to-dos and single events just isn't there.  A single 
folded 8.5x11 piece of paper or a handful of 3x5 cards works wonders 
for having a "trusted system", with a regular paper dayrunner or 
other calendar to manage ticklers and "hard landscape".


>More powerful in my opinion is to go beyond only calendaring
>applications and to position Chandler for small-group collaboration
>(which was one of the original USPs that had attracted my initial
>interest). Positioning initially for group calendaring would seem to be
>a solid step in the direction of small-group collaboration, but seems
>like "leaving money on the table," so to speak.

That's a natural and obvious thought -- which is what makes it 
totally wrong as a marketing thought.  :)  If marketing were a 
natural and logical thought process, there wouldn't be so much of it 
that sucks.  :)

There are two non-obvious catches with the "small-group 
collaboration" phrase.  The first is that "collaboration" doesn't 
mean anything.  It's an abstraction, rather than concrete, so it 
doesn't produce a vivid image in the mind.  It thus merely raises 
questions, rather than presenting a concrete answer.  Is it a chat 
program?  A shared file manager?  A virtual meeting and whiteboard 
tool?  (Notice how these are all descriptions of specific, concrete 
activities or objects.)

The second catch is that to the extent this *is* a concrete term, 
it's already an existing niche with a completely different concept 
attached to it: think of tools like Microsoft Sharepoint, intranet 
content managers, and a whole boatload of other sorts of programs 
that in no way resemble Chandler, and whose shoes Chandler can in no 
way fill at present.  (Such as the aforementioned chat, virtual 
meeting and whiteboard tools.)

Finally, note that in marketing, being more specific is not really 
leaving money on the table.  The more specialized the message, the 
greater the response rate among people who meet the message's 
selection criteria.  It's just as profitable to get a 10% response 
from 10% of the market, as it is to get a 1% response from the market 
as a whole.  In fact, sometimes it's *more* profitable, if it costs 
less to get your message out to that 10% of the market, due to more 
focused ad buys, or improved viral-ity(?).  (And the difference in 
response rate between a vague message and a specifically-targeted one 
can easily be greater than 10:1.)

If we want users, then, the appropriate thing is to cut any part of 
the message that does not support getting a user's attention and 
interest (not to mention desire and action).  Neither our 
organizational religion nor our original goals for the product have 
much relevance to most users, so attempting to communicate them (in 
the context of user *acquisition*) is a waste of funds and effort.

Now, once you have a relationship with someone, it's a lot easier to 
communicate more complex messages.  You can say, "oh, and look, we've 
got this too", and it doesn't go in one ear and out the other as 
much.  But before you have that relationship, people tend to shut off 
or click away the moment you bore them with something they don't 
understand or have to give some thought to.  We have to "show them 
the pony" right away.


>OK. However, clearly our preferences are different. I much prefer
>capturing a task into Chandler over capturing a task on a 3x5 card
>because of the practical advantage of being able to search more easily
>and quickly my large stack of Chandler "cards" as compared to a large
>stack of 3x5 cards.

I don't mean one card per task - I mean that when I use cards for 
GTD, I have a card *per context*, onto which I write all of the next 
actions for that context.  That means I have maybe 5-6 cards in all, 
easily tucked into a pocket.  When I use paper, I usually just fold a 
single piece of paper 3 times to make an 8-page booklet, using each 
page for a different context.


>As I documented and sent to the Chandler-Users list,
>I use a consistently set of abbreviations for GTD contexts in the bodies
>of items. This enables me to use Chandler's Lucene search to quickly,
>easily, and dynamically view a list of next actions by context.

I bet I can find the 3x5 card for a given context, faster than you 
can start Chandler and run that search.  :)  Actually, doing the same 
with LB is faster too, as it's only a button push away on my 
Palm.  But that's probably cheating.  :)


>For
>me, the tidy compartmentalization of contexts such as @Home and @Work
>just didn't match my real life.

It doesn't match mine these days either - I work almost entirely from 
home, so everything would be "home" if I used space for context; it's 
not worth separating kitchen or living room tasks, really.  Since 
I've been working at home, I usually use expected task duration as 
contexts for my paper tools.

When I first came up with this, I thought it was a neat innovation, 
but then I re-read the GTD book and rediscovered the section where it 
lists the four criteria used for task selection.  That is: context, 
time required, energy required, and priority.  So, it's literally the 
next thing after physical context, which makes a lot of sense.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design