Hi Phillip, Thanks much for sharing your evolving experiences with GTD. The scenarios help me understand the points about GTD with Chandler, and the merits or demerits of using automated tools with GTD at all. No doubt your search system for next actions by context is faster than mine, is more portable, and only optionally requires batteries. :)
In a summary of this sub-thread, it looks like this to me (echoing, in part, points you and others have made): -Chandler is not an obvious choice with which to implement GTD, even if using GTD with Chandler is effective for some people. -Without any use of GTD, Chandler Triage can be helpful to some people in sifting the signal from the noise of daily demands. -Chandler Calendar CalDAV sharing is superior (for all the many reasons) to ical publish and subscribe. -"Collaboration" is too unspecific to be by itself a USP. -If Calendar is chosen as the lead-off USP for Chandler, then a number of calendar features should be enhanced, for example, UI support for remaining recurrence patterns (already supported in the underlying layers, if memory serves me) -Although promising (in my opinion) as a PIM for individual users, Chandler reveals to date more promise than practicality as the descendent of Lotus Agenda, (the web search term that originally lead me to the OSAF website a few years ago). -Marketing is hard. :) Happy New Year, Andre On Fri, 28 Dec 2007 15:02:57 -0500, "Phillip J. Eby" <[EMAIL PROTECTED]> said: > 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 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
