The "Design" list for the OsaFoundation "Chandler" groupware Client

headers Mimi Yin | 18 Dec 2007 23:53

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

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

At 02:53 PM 12/18/2007 -0800, Mimi Yin wrote:
>I - THE PROBLEM WITH TASK MANAGERS TODAY: STRUCTURE GETS IN THE WAY
>
>To wrap their head around what they have to do, people always start 
>out by making a list/outline of all their projects and all their 
>tasks. This 'structure it in order to get a grip on it' approach to 
>task management has its deficits:
>
>1. The structure itself locks out possibilities that don't fit into 
>that structure. Have something random you need to follow up on that 
>doesn't fit into your structure? Doesn't get written down. That's 
>trivial, petty, you think to yourself. Besides, I don't know where 
>I'd put it in this outline. I'll just keep track of it in my head.
>
>2. As soon as new information comes to light, your outline gets out 
>of date as you struggle to fit today's information into yesterday's list.
>
>3. Lists and outlines don't allow you to focus on *just the stuff 
>you need to attend to NOW*. Instead you see everything that's 
>not-done, and a lot of it is stuff you're only hypothesizing you'll need to do.
>
>4. Lists and outlines don't scale to hold and keep track of the 
>disconnected ideas and thoughts you have that eventually coalesce 
>into the 'work' you need to do. So even if you have a way to manage 
>your *tasks* (aka *list of stuff you need to do*), you still have 
>nowhere to store and manage all the stuff that constitutes the 
>*substance* of those tasks. In that sense, task management seems 
>like a lot of 'meta-work', busywork that doesn't actually help you 
>manage the work you're actually doing.
>
>5. Lists and outlines presume that you do things in a given order. 
>First I will do this, then I will do that. In reality, we noodle on 
>lots of things, all the time, at the *same* time. Coming up with 
>ideas and questions, remembering one more thing to add to that list, 
>spouting fully formed introductory paragraphs to the dreaded 
>year-end summary, scheduling a meeting, coming up with an agenda for 
>that meeting, writing meeting notes for last week's meeting...

My initial reaction to this list is that these things are at best 
only relevant to paper-based organizing, and even there only to *ad 
hoc* paper-based systems, because all of the formal paper-based 
systems I know of (such as GTD, OPA (or whatever Tony Robbins is 
calling it this year), and Franklin-Covey) do not have these 
defects.  I'm also not aware of any PIMs of consequence in the past 
decade or two that don't have ways of doing the same things.  And 
quite a few modern PIMs support having a structured outline *and* a 
to-do list filtered by context+time.

Now, it's not necessarily the case that this would remove the above 
from being part of the marketing picture.  It's not necessary that a 
tool be the first to implement an innovation, it just has to be first 
to *tell the story* to the given customer.

But it seems like there would be a fairly narrow number of people who 
would not know about any paper *or* electronic organizational 
systems, and they are far less likely to be early adopters of a new 
tool.  They would have to be *sold* on Chandler by someone else, 
because there is little chance of them hearing about it.  (If they've 
managed not to hear of GTD or Franklin-Covey, *and* haven't been 
exposed to any PIM's, the odds of them accidentally hearing about 
Chandler seem fairly slim).

To market to the early adopters who would promote Chandler to those 
people by word of mouth, we need to either: 1) emphasize the positive 
*differences* between Chandler and other PIMs, or 2) successfully 
position Chandler as the leader of its own, *new* category.

And I think that the latter approach has a better chance of 
succeeding, because Chandler doesn't do that well as a pure PIM, when 
compared to PIMs that were written 10-15 years ago, from both a 
features and ease-of-use standpoint.

One category that Chandler could define and *own* right now would be 
"lightweight team+personal calendar".  We could in fact strip some 
features *out* of Chandler, and *still* lead this category.  In fact, 
it could be a *plus* to strip any features that detract from leading 
that category or confuse the mission/position in our minds or the 
customers'.  Simplifying the terminology and stripping out any 
too-"innovative" concepts that require users to think or read a 
manual, would be a big plus.  Meanwhile, most of the other features 
you mentioned in your email (cross-platform, connectivity, email, 
etc.) can all be positioned in terms of how they support the 
"lightweight team+personal calendar" mission -- and nothing else.

This would let us define a niche that Chandler could *dominate* -- 
and product that defines the niche can *own* the niche.  (It's 
actually a lot easier to get a lot of users if you can more precisely 
identify the users in question.)

By comparison, the "PIM" category in some sense no longer exists; as 
commercial products, there are only niche PIMs now.  Contact managers 
for salespeople, calendars for enterprises, bug and issue trackers, 
team project trackers, GTD-specific and quasi-GTD PIMs...  these are 
all things that used to be done by programs in the "PIM" category, 
which was too general for the market.  The things that used to be 
PIMs have now become a niche that might be called "customizable PIMs" 
or "power-user PIMs".

And Chandler isn't a viable competitor (IMO) in any of those 
niches.  It doesn't do contacts, it doesn't do Exchange, it doesn't 
do bug tracking or project tracking, it's opposed to GTD philosophy 
in some key ways (i.e., the whole idea of GTD is to *process* your 
"stuff", not to keep it as "stuff" indefinitely), and it's not a very 
customizable power-user PIM.

While other PIM's have had comparable team support (e.g. Ecco), they 
are not positioned at the "lightweight team+personal calendar" 
niche.  And a more narrowly-focused application has the positional 
advantage that people will prefer something that *only* does what 
they need, on the assumption that a specialist will be better within 
its niche, than a more general-purpose tool will.  (i.e. they'd 
rather use a chisel than abuse a screwdriver, if both are available.)

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

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

I think Phillip makes some great points, particularly about  
simplifying the positioning statement and removing some stuff from  
the marketing message. I worry that we are trying too hard to put too  
much information into the initial description. Maybe I am saying that  
I don't think the "pony" has to be in the tagline or elevator pitch  
for instance. I know there is hesitation to call the product a  
Calendar because it does MORE than that but in the end it might make  
it easier to present the other unique features in a compelling way.  
We can leave all the details for the "why should I care?" or "so  
what?" message.

Recently, I demo'd the product for a couple of friends. Despite all  
the work we did with branding and preview I still really struggled to  
describe the product to others in a concise way. I seemed to babble  
on. As soon as I start going into the bits about triage, getting  
stuff out of your head, edit/update etc, people eyes start to glaze  
over. It seems to be either too much detail or I haven't found a  
compelling way to communicate this. Any reference to PIMs or Task  
Managers just gets me into trouble ie: contacts etc.

Personally, when I demo to others, I find I go into way too much  
detail. I wish I had a slick 2 minute demo I could just put in front  
of people. If someone walks by my desk, I really need to be able to  
show the top 5 things and leave them with an impression.

Sheila

On Dec 19, 2007, at 10:31 AM, Phillip J. Eby wrote:

> At 02:53 PM 12/18/2007 -0800, Mimi Yin wrote:
>> I - THE PROBLEM WITH TASK MANAGERS TODAY: STRUCTURE GETS IN THE WAY
>>
>> To wrap their head around what they have to do, people always  
>> start out by making a list/outline of all their projects and all  
>> their tasks. This 'structure it in order to get a grip on it'  
>> approach to task management has its deficits:
>>
>> 1. The structure itself locks out possibilities that don't fit  
>> into that structure. Have something random you need to follow up  
>> on that doesn't fit into your structure? Doesn't get written down.  
>> That's trivial, petty, you think to yourself. Besides, I don't  
>> know where I'd put it in this outline. I'll just keep track of it  
>> in my head.
>>
>> 2. As soon as new information comes to light, your outline gets  
>> out of date as you struggle to fit today's information into  
>> yesterday's list.
>>
>> 3. Lists and outlines don't allow you to focus on *just the stuff  
>> you need to attend to NOW*. Instead you see everything that's not- 
>> done, and a lot of it is stuff you're only hypothesizing you'll  
>> need to do.
>>
>> 4. Lists and outlines don't scale to hold and keep track of the  
>> disconnected ideas and thoughts you have that eventually coalesce  
>> into the 'work' you need to do. So even if you have a way to  
>> manage your *tasks* (aka *list of stuff you need to do*), you  
>> still have nowhere to store and manage all the stuff that  
>> constitutes the *substance* of those tasks. In that sense, task  
>> management seems like a lot of 'meta-work', busywork that doesn't  
>> actually help you manage the work you're actually doing.
>>
>> 5. Lists and outlines presume that you do things in a given order.  
>> First I will do this, then I will do that. In reality, we noodle  
>> on lots of things, all the time, at the *same* time. Coming up  
>> with ideas and questions, remembering one more thing to add to  
>> that list, spouting fully formed introductory paragraphs to the  
>> dreaded year-end summary, scheduling a meeting, coming up with an  
>> agenda for that meeting, writing meeting notes for last week's  
>> meeting...
>
> My initial reaction to this list is that these things are at best  
> only relevant to paper-based organizing, and even there only to *ad  
> hoc* paper-based systems, because all of the formal paper-based  
> systems I know of (such as GTD, OPA (or whatever Tony Robbins is  
> calling it this year), and Franklin-Covey) do not have these  
> defects.  I'm also not aware of any PIMs of consequence in the past  
> decade or two that don't have ways of doing the same things.  And  
> quite a few modern PIMs support having a structured outline *and* a  
> to-do list filtered by context+time.
>
> Now, it's not necessarily the case that this would remove the above  
> from being part of the marketing picture.  It's not necessary that  
> a tool be the first to implement an innovation, it just has to be  
> first to *tell the story* to the given customer.
>
> But it seems like there would be a fairly narrow number of people  
> who would not know about any paper *or* electronic organizational  
> systems, and they are far less likely to be early adopters of a new  
> tool.  They would have to be *sold* on Chandler by someone else,  
> because there is little chance of them hearing about it.  (If  
> they've managed not to hear of GTD or Franklin-Covey, *and* haven't  
> been exposed to any PIM's, the odds of them accidentally hearing  
> about Chandler seem fairly slim).
>
> To market to the early adopters who would promote Chandler to those  
> people by word of mouth, we need to either: 1) emphasize the  
> positive *differences* between Chandler and other PIMs, or 2)  
> successfully position Chandler as the leader of its own, *new*  
> category.
>
> And I think that the latter approach has a better chance of  
> succeeding, because Chandler doesn't do that well as a pure PIM,  
> when compared to PIMs that were written 10-15 years ago, from both  
> a features and ease-of-use standpoint.
>
> One category that Chandler could define and *own* right now would  
> be "lightweight team+personal calendar".  We could in fact strip  
> some features *out* of Chandler, and *still* lead this category.   
> In fact, it could be a *plus* to strip any features that detract  
> from leading that category or confuse the mission/position in our  
> minds or the customers'.  Simplifying the terminology and stripping  
> out any too-"innovative" concepts that require users to think or  
> read a manual, would be a big plus.  Meanwhile, most of the other  
> features you mentioned in your email (cross-platform, connectivity,  
> email, etc.) can all be positioned in terms of how they support the  
> "lightweight team+personal calendar" mission -- and nothing else.
>
> This would let us define a niche that Chandler could *dominate* --  
> and product that defines the niche can *own* the niche.  (It's  
> actually a lot easier to get a lot of users if you can more  
> precisely identify the users in question.)
>
> By comparison, the "PIM" category in some sense no longer exists;  
> as commercial products, there are only niche PIMs now.  Contact  
> managers for salespeople, calendars for enterprises, bug and issue  
> trackers, team project trackers, GTD-specific and quasi-GTD  
> PIMs...  these are all things that used to be done by programs in  
> the "PIM" category, which was too general for the market.  The  
> things that used to be PIMs have now become a niche that might be  
> called "customizable PIMs" or "power-user PIMs".
>
> And Chandler isn't a viable competitor (IMO) in any of those  
> niches.  It doesn't do contacts, it doesn't do Exchange, it doesn't  
> do bug tracking or project tracking, it's opposed to GTD philosophy  
> in some key ways (i.e., the whole idea of GTD is to *process* your  
> "stuff", not to keep it as "stuff" indefinitely), and it's not a  
> very customizable power-user PIM.
>
> While other PIM's have had comparable team support (e.g. Ecco),  
> they are not positioned at the "lightweight team+personal calendar"  
> niche.  And a more narrowly-focused application has the positional  
> advantage that people will prefer something that *only* does what  
> they need, on the assumption that a specialist will be better  
> within its niche, than a more general-purpose tool will.  (i.e.  
> they'd rather use a chisel than abuse a screwdriver, if both are  
> available.)
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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

+1

I've been experimenting with just showing people how to set up an  
account, add an event and share it. Even after that amount of  
explanation, they begin loosing interest, but I think this has worked  
better than my prior demos which began with a bunch of background  
concepts

John

On Dec 21, 2007, at 9:01 AM, Sheila Mooney wrote:

> I think Phillip makes some great points, particularly about  
> simplifying the positioning statement and removing some stuff from  
> the marketing message. I worry that we are trying too hard to put  
> too much information into the initial description. Maybe I am saying  
> that I don't think the "pony" has to be in the tagline or elevator  
> pitch for instance. I know there is hesitation to call the product a  
> Calendar because it does MORE than that but in the end it might make  
> it easier to present the other unique features in a compelling way.  
> We can leave all the details for the "why should I care?" or "so  
> what?" message.
>
> Recently, I demo'd the product for a couple of friends. Despite all  
> the work we did with branding and preview I still really struggled  
> to describe the product to others in a concise way. I seemed to  
> babble on. As soon as I start going into the bits about triage,  
> getting stuff out of your head, edit/update etc, people eyes start  
> to glaze over. It seems to be either too much detail or I haven't  
> found a compelling way to communicate this. Any reference to PIMs or  
> Task Managers just gets me into trouble ie: contacts etc.
>
> Personally, when I demo to others, I find I go into way too much  
> detail. I wish I had a slick 2 minute demo I could just put in front  
> of people. If someone walks by my desk, I really need to be able to  
> show the top 5 things and leave them with an impression.
>
> Sheila
>
> On Dec 19, 2007, at 10:31 AM, Phillip J. Eby wrote:
>
>> At 02:53 PM 12/18/2007 -0800, Mimi Yin wrote:
>>> I - THE PROBLEM WITH TASK MANAGERS TODAY: STRUCTURE GETS IN THE WAY
>>>
>>> To wrap their head around what they have to do, people always  
>>> start out by making a list/outline of all their projects and all  
>>> their tasks. This 'structure it in order to get a grip on it'  
>>> approach to task management has its deficits:
>>>
>>> 1. The structure itself locks out possibilities that don't fit  
>>> into that structure. Have something random you need to follow up  
>>> on that doesn't fit into your structure? Doesn't get written down.  
>>> That's trivial, petty, you think to yourself. Besides, I don't  
>>> know where I'd put it in this outline. I'll just keep track of it  
>>> in my head.
>>>
>>> 2. As soon as new information comes to light, your outline gets  
>>> out of date as you struggle to fit today's information into  
>>> yesterday's list.
>>>
>>> 3. Lists and outlines don't allow you to focus on *just the stuff  
>>> you need to attend to NOW*. Instead you see everything that's not- 
>>> done, and a lot of it is stuff you're only hypothesizing you'll  
>>> need to do.
>>>
>>> 4. Lists and outlines don't scale to hold and keep track of the  
>>> disconnected ideas and thoughts you have that eventually coalesce  
>>> into the 'work' you need to do. So even if you have a way to  
>>> manage your *tasks* (aka *list of stuff you need to do*), you  
>>> still have nowhere to store and manage all the stuff that  
>>> constitutes the *substance* of those tasks. In that sense, task  
>>> management seems like a lot of 'meta-work', busywork that doesn't  
>>> actually help you manage the work you're actually doing.
>>>
>>> 5. Lists and outlines presume that you do things in a given order.  
>>> First I will do this, then I will do that. In reality, we noodle  
>>> on lots of things, all the time, at the *same* time. Coming up  
>>> with ideas and questions, remembering one more thing to add to  
>>> that list, spouting fully formed introductory paragraphs to the  
>>> dreaded year-end summary, scheduling a meeting, coming up with an  
>>> agenda for that meeting, writing meeting notes for last week's  
>>> meeting...
>>
>> My initial reaction to this list is that these things are at best  
>> only relevant to paper-based organizing, and even there only to *ad  
>> hoc* paper-based systems, because all of the formal paper-based  
>> systems I know of (such as GTD, OPA (or whatever Tony Robbins is  
>> calling it this year), and Franklin-Covey) do not have these  
>> defects.  I'm also not aware of any PIMs of consequence in the past  
>> decade or two that don't have ways of doing the same things.  And  
>> quite a few modern PIMs support having a structured outline *and* a  
>> to-do list filtered by context+time.
>>
>> Now, it's not necessarily the case that this would remove the above  
>> from being part of the marketing picture.  It's not necessary that  
>> a tool be the first to implement an innovation, it just has to be  
>> first to *tell the story* to the given customer.
>>
>> But it seems like there would be a fairly narrow number of people  
>> who would not know about any paper *or* electronic organizational  
>> systems, and they are far less likely to be early adopters of a new  
>> tool.  They would have to be *sold* on Chandler by someone else,  
>> because there is little chance of them hearing about it.  (If  
>> they've managed not to hear of GTD or Franklin-Covey, *and* haven't  
>> been exposed to any PIM's, the odds of them accidentally hearing  
>> about Chandler seem fairly slim).
>>
>> To market to the early adopters who would promote Chandler to those  
>> people by word of mouth, we need to either: 1) emphasize the  
>> positive *differences* between Chandler and other PIMs, or 2)  
>> successfully position Chandler as the leader of its own, *new*  
>> category.
>>
>> And I think that the latter approach has a better chance of  
>> succeeding, because Chandler doesn't do that well as a pure PIM,  
>> when compared to PIMs that were written 10-15 years ago, from both  
>> a features and ease-of-use standpoint.
>>
>> One category that Chandler could define and *own* right now would  
>> be "lightweight team+personal calendar".  We could in fact strip  
>> some features *out* of Chandler, and *still* lead this category.   
>> In fact, it could be a *plus* to strip any features that detract  
>> from leading that category or confuse the mission/position in our  
>> minds or the customers'.  Simplifying the terminology and stripping  
>> out any too-"innovative" concepts that require users to think or  
>> read a manual, would be a big plus.  Meanwhile, most of the other  
>> features you mentioned in your email (cross-platform, connectivity,  
>> email, etc.) can all be positioned in terms of how they support the  
>> "lightweight team+personal calendar" mission -- and nothing else.
>>
>> This would let us define a niche that Chandler could *dominate* --  
>> and product that defines the niche can *own* the niche.  (It's  
>> actually a lot easier to get a lot of users if you can more  
>> precisely identify the users in question.)
>>
>> By comparison, the "PIM" category in some sense no longer exists;  
>> as commercial products, there are only niche PIMs now.  Contact  
>> managers for salespeople, calendars for enterprises, bug and issue  
>> trackers, team project trackers, GTD-specific and quasi-GTD  
>> PIMs...  these are all things that used to be done by programs in  
>> the "PIM" category, which was too general for the market.  The  
>> things that used to be PIMs have now become a niche that might be  
>> called "customizable PIMs" or "power-user PIMs".
>>
>> And Chandler isn't a viable competitor (IMO) in any of those  
>> niches.  It doesn't do contacts, it doesn't do Exchange, it doesn't  
>> do bug tracking or project tracking, it's opposed to GTD philosophy  
>> in some key ways (i.e., the whole idea of GTD is to *process* your  
>> "stuff", not to keep it as "stuff" indefinitely), and it's not a  
>> very customizable power-user PIM.
>>
>> While other PIM's have had comparable team support (e.g. Ecco),  
>> they are not positioned at the "lightweight team+personal calendar"  
>> niche.  And a more narrowly-focused application has the positional  
>> advantage that people will prefer something that *only* does what  
>> they need, on the assumption that a specialist will be better  
>> within its niche, than a more general-purpose tool will.  (i.e.  
>> they'd rather use a chisel than abuse a screwdriver, if both are  
>> available.)
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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

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

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

At 09:01 AM 12/21/2007 -0800, Sheila Mooney wrote:
>I think Phillip makes some great points, particularly about
>simplifying the positioning statement and removing some stuff from
>the marketing message. I worry that we are trying too hard to put too
>much information into the initial description. Maybe I am saying that
>I don't think the "pony" has to be in the tagline or elevator pitch
>for instance. I know there is hesitation to call the product a
>Calendar because it does MORE than that but in the end it might make
>it easier to present the other unique features in a compelling way.
>We can leave all the details for the "why should I care?" or "so
>what?" message.

Right, it's much easier to present the rest in the context of *why* 
it's such a great calendar.  :)  That is, it's a great calendar 
*because* it has the other features.

A wise person once said that good marketing is the act of "letting 
people know about something they *already* want".  People already 
want group calendaring solutions, and they already know their choices 
are mostly not very good.  And Chandler has a nice combination of 
advantages in that space: standards-based interop, 
offline/online/web, overlay calendars from multiple sources, email.

Once you have people's attention with that, *then* they may care 
about the rest.  Before that, the rest is stuff they don't *know* 
they already want, which is why it takes so much effort to get that 
message across as the first thing.

>Recently, I demo'd the product for a couple of friends. Despite all
>the work we did with branding and preview I still really struggled to
>describe the product to others in a concise way. I seemed to babble
>on. As soon as I start going into the bits about triage, getting
>stuff out of your head, edit/update etc, people eyes start to glaze
>over. It seems to be either too much detail or I haven't found a
>compelling way to communicate this. Any reference to PIMs or Task
>Managers just gets me into trouble ie: contacts etc.
>
>Personally, when I demo to others, I find I go into way too much
>detail. I wish I had a slick 2 minute demo I could just put in front
>of people. If someone walks by my desk, I really need to be able to
>show the top 5 things and leave them with an impression.

I think the highlights would probably be things like:

* Download some calendars
* Change something, add an event, etc.
* Sync it to the hub
* Go to the hub and view it in a web browser ("your friends don't 
even need to have the program, you can view this from anywhere, etc.")

And for maximum clarity/impact, it would help if there was a visible 
indication that a sync was required, so you can see "why" you need to 
hit sync ("see, here it shows that there is stuff waiting to upload, 
so we just hit this and look... there it goes, now when my 
friends/team sync they will see there was a change.").

And of course we should make a screencast of this, blog it, PR it, 
etc...  at least, after we review what parts of the walkthrough are 
awkward to do or explain, and make the necessary changes to 
terminology or interface.

We could later do additional screencasts for triage, edit/update, and 
so forth, each being only a few minutes, but the calendar demo will 
be the key seller, I think.  Our edit/update capability right now is 
way too primitive, and triage isn't different enough from what other 
PIMs can do to be a big seller.  In particular, it won't impress 
early adopters and PIM geeks ("I can do that with a filter, 
duh").  Calendar sharing (with mention of standards compliance and 
the ability to have plugins) will be more impressive, and the 
simplicity of the app will be a win for people who have to support 
this.  (Not to mention the open source part.)

In other words, the most likely way a workgroup will end up using 
this is if their IT guy or resident techie sees that it gets the 
calendaring job done and won't be hard to teach/support their 
users.  So the audience for this demo is actually those people who 
would do the recommending.  Thus, the commentary would need to 
briefly mention things here and there about the SSL security, hub 
account management, etc.

We are not *quite* ready to make and spread these demos, of course, 
but I think we could define Chandler 1.0 (Desktop and Server) as 
being whatever is needed to make these short demos shine under the 
watchful scrutiny of an alpha geek who's looking for holes.

(To clarify, holes would be anything our hypothetical IT person would 
spot as a monkeywrench in their installing the software for users, 
from how installation is done, to security issues, to unsupported use 
cases within the target usage area, to difficulty teaching/explaining 
the software to their users.)

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

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

I agree with the sentiment that we need to market Chandler in terms  
of what people already 'know' they want or need a solution for. I'm  
not sure it should start with calendaring.

For one, how do we differentiate ourselves from other web calendar  
services? The offline functionality doesn't seem compelling enough on  
its own.

Second, I *have* had success demo-ing Chandler to people by pitching  
it as something that ties all the bits and pieces of information you  
have floating around in your head, Inbox, random text files together:  
Personal and shared 'source of truth' manager. I agree that this is a  
hard pitch to get right, but I don't think we've given this angle a  
fair shot yet. We're only starting to articulate it in the long-hand  
form now.

What I am trying to get at is that there is something in the  
combination of Faceted Sidebar, Triage-Dashboard and Stamping that is  
substantively, significantly different and more valuable than filters  
+ hierarchy in other PIMs / Task Managers. In many ways, the design  
we have today is in response to the 'just build a filtered view'  
approach to information management.

This 'thing' we've had trouble articulating doesn't have to be what  
we communicate in the marketing pitch. But I think that to come up  
with a compelling pitch, we need to start with a clear understanding  
of it. Otherwise, how can we go about helping others to see and  
experience it?

Mimi

On Dec 21, 2007, at 10:15 AM, Phillip J. Eby wrote:

> Our edit/update capability right now is way too primitive, and  
> triage isn't different enough from what other PIMs can do to be a  
> big seller.  In particular, it won't impress early adopters and PIM  
> geeks ("I can do that with a filter, duh").  Calendar sharing (with  
> mention of standards compliance and the ability to have plugins)  
> will be more impressive, and the simplicity of the app will be a  
> win for people who have to support this.  (Not to mention the open  
> source part.)
>
> In other words, the most likely way a workgroup will end up using  
> this is if their IT guy or resident techie sees that it gets the  
> calendaring job done and won't be hard to teach/support their  
> users.  So the audience for this demo is actually those people who  
> would do the recommending.  Thus, the commentary would need to  
> briefly mention things here and there about the SSL security, hub  
> account management, etc.

This is part of our target. But I think we can reach beyond this  
audience. People start using tools like OmniOutliner on their own, I  
don't see why Chandler can't reach the same kind of users.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

At 12:26 PM 12/21/2007 -0800, Mimi Yin wrote:
>I agree with the sentiment that we need to market Chandler in terms
>of what people already 'know' they want or need a solution for. I'm
>not sure it should start with calendaring.

Fair enough.  It's simply the most obvious and fully-grown pony, as 
far as I can tell.  :)

>For one, how do we differentiate ourselves from other web calendar
>services? The offline functionality doesn't seem compelling enough on
>its own.

Doesn't that depend on who the user is?

>Second, I *have* had success demo-ing Chandler to people by pitching
>it as something that ties all the bits and pieces of information you
>have floating around in your head, Inbox, random text files together:
>Personal and shared 'source of truth' manager. I agree that this is a
>hard pitch to get right, but I don't think we've given this angle a
>fair shot yet. We're only starting to articulate it in the long-hand
>form now.

 From a marketing perspective, this is a bit backwards.  You don't 
make a product and then figure out how to sell it, you figure out 
what people want to buy and then make it.  What specific pain do 
people have that they would be motivated enough to spend money (or at 
least time/effort/learning) to eliminate, and what emotional payoff 
will they receive from eliminating it?

We still have to answer this question, even for calendaring, it's 
just that having a well-defined space like "calendar" allows you to 
e.g. look at what's being advertised via AdWords to check out the competition.

In contrast, the only existing word I know of for the broader mission 
is "PIM", and we can't win in that category.

>In many ways, the design
>we have today is in response to the 'just build a filtered view'
>approach to information management.

So what about it is better (as opposed to merely different)?  (Where 
better is defined in terms of ultimate impact on the person using it.)

>This 'thing' we've had trouble articulating doesn't have to be what
>we communicate in the marketing pitch. But I think that to come up
>with a compelling pitch, we need to start with a clear understanding
>of it. Otherwise, how can we go about helping others to see and
>experience it?

We need to start from the other end: who needs this, what is their 
pain, and what *emotional* payoff will they get from the solution?

My extremely limited perspective on this is that I see IT guys whose 
users are bugging them for a calendar.  Their pain is they don't want 
to do Exchange, but they want something better than some random PHP 
intranet app, especially if they have remote users.  The competition 
for this niche is low, especially under 25 users.  (E.g., Zimbra 
sells in blocks of 25 seats, and their marketing is a little too 
corporate-speak for smaller groups, anyway.)  The emotional payoff is 
that they save the day and the budget and look good for picking the 
right thing.

However, this is only *one* potential niche.  There are likely others 
that I'm not aware of.

What niche(s), if any, did you have in mind?

>This is part of our target. But I think we can reach beyond this
>audience. People start using tools like OmniOutliner on their own, I
>don't see why Chandler can't reach the same kind of users.

To a PIM geek, Chandler isn't even in the same league with 
OmniOutliner (or its likely inspiration from the PC, Ecco Pro).

Now, it might be that I'm wrong, and there are non-PIM geeks who buy 
things like OmniOutliner.  Certainly some of them must be.  But my 
general impression has been that PIM enthusiasts and other people 
with the "productivity" otaku are the primary ones who already *know* 
they want a PIM.  And Chandler compares less well within that 
category, IMO, than it does in the calendar category.

As Katie has put it, we have a few different centers of gravity:

"Outlook killer" -- we simply don't stack up

"GTD" -- Chandler's design philosophy directly contradicts that of 
GTD on occasion, doesn't accept GTD's premises in other areas, and 
doesn't provide any GTD-specific tools that aren't done significantly 
better by other PIMs (even ones that aren't specifically designed for 
GTD).  The only differentiating factor here is open source+GUI.  Note 
that there are open source GTD tools based on text-only/command-line 
operation, which just goes to show how *much* demand there is for 
good GTD tools.  If we built an actual, scripturally-correct GTD 
application, we'd have GTD fans all over us -- but that would be a 
non-trivial effort, to say the least.

"small team collaboration" -- this is the only niche we actually have 
any competitive oomph in right *now*, but even so we will not compete 
without defining a *new* subcategory/niche to be the leader 
of.  That's primarily a marketing question, and it's primarily 
directed *outward*, to the question of what people want, as opposed 
to what we have.

Unfortunately, I am not a "real" marketing person, so all this is 
perhaps not as clearly elaborated on my part as I would like it to be.

In any case, those three areas above are areas where people already 
know they need something, and might thus pay attention to messages about it.

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

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

I say this again below, but I wanted to reiterate that I think this  
discussion is really helpful and exactly what we need to do to get to  
a solid pitch. You're forcing me to articulate a lot of things I  
thought I had articulated, but either hadn't really or did so in the  
wrong context. I'm sure I'm not the only one, so please jump into  
this thread if you can!

(Aside: I realize that some additional context might be necessary for  
my *call to action* above: Why is it important for us to  to air out  
all of our assumptions? to get on the same page? The reality is, this  
is a group effort. We don't have a marketing department to carry out  
the will of a single vision by fiat. Instead, we need to rely on  
ourselves (this includes our small but active user community!) to see  
to it that Chandler succeeds. And just as it was really hard for us  
as an organization to design and implement a coherent product until  
we defined target users and usage scenarios, we won't be effective at  
*selling Chandler* until we can each clearly and authentically pitch  
the *same* product.)

See more in-line...

On Dec 21, 2007, at 4:15 PM, Phillip J. Eby wrote:

> At 12:26 PM 12/21/2007 -0800, Mimi Yin wrote:
>> I agree with the sentiment that we need to market Chandler in terms
>> of what people already 'know' they want or need a solution for. I'm
>> not sure it should start with calendaring.
>
> Fair enough.  It's simply the most obvious and fully-grown pony, as  
> far as I can tell.  :)

Yes, I'm trying to change that perception :)

>> For one, how do we differentiate ourselves from other web calendar
>> services? The offline functionality doesn't seem compelling enough on
>> its own.
>
> Doesn't that depend on who the user is?

Just to clarify, I'm not saying that offline mode isn't incredibly  
useful. It's just that in my mind, 'Shared calendaring, now offline  
too!' feels like it lacks oomph as a pitch.

>> Second, I *have* had success demo-ing Chandler to people by pitching
>> it as something that ties all the bits and pieces of information you
>> have floating around in your head, Inbox, random text files together:
>> Personal and shared 'source of truth' manager. I agree that this is a
>> hard pitch to get right, but I don't think we've given this angle a
>> fair shot yet. We're only starting to articulate it in the long-hand
>> form now.
>
> From a marketing perspective, this is a bit backwards.  You don't  
> make a product and then figure out how to sell it, you figure out  
> what people want to buy and then make it.  What specific pain do  
> people have that they would be motivated enough to spend money (or  
> at least time/effort/learning) to eliminate, and what emotional  
> payoff will they receive from eliminating it?

I'm not sure I'm following. The pitch I'm referring to *is* the  
problem we originally identified and designed Chandler to solve.

>> In many ways, the design
>> we have today is in response to the 'just build a filtered view'
>> approach to information management.
>
> So what about it is better (as opposed to merely different)?   
> (Where better is defined in terms of ultimate impact on the person  
> using it.)

That, was the topic of my first email :) My claim is that if we can  
figure out how to orient people so that they approach the product in  
the right state of mind (e.g. don't expect it to be a PIM, email  
client, traditional project manager)...it's an information / work /  
task manager people can actually stick with.

>> This 'thing' we've had trouble articulating doesn't have to be what
>> we communicate in the marketing pitch. But I think that to come up
>> with a compelling pitch, we need to start with a clear understanding
>> of it. Otherwise, how can we go about helping others to see and
>> experience it?
>
> We need to start from the other end: who needs this, what is their  
> pain, and what *emotional* payoff will they get from the solution?

Yes. The pain is: I have too many bits and pieces of information to  
keep track of all in my head, but I can't seem to stick with any of  
the information-manager-type things I try, be it a paper-based list  
system, excel, project managers, task lists, outliners, etc.

The emotional pay-off is relief that I have a *trusted system* where  
everything is, it's easy to keep up-to-date, it's shared with others  
so that organizing myself = organizing everyone else too, AND it  
doesn't feel like a lot of busy-work because it's actually helping me  
get work done too, not just helping me keep track of the task  
representations of work.

> My extremely limited perspective on this is that I see IT guys  
> whose users are bugging them for a calendar.  Their pain is they  
> don't want to do Exchange, but they want something better than some  
> random PHP intranet app, especially if they have remote users.  The  
> competition for this niche is low, especially under 25 users.   
> (E.g., Zimbra sells in blocks of 25 seats, and their marketing is a  
> little too corporate-speak for smaller groups, anyway.)  The  
> emotional payoff is that they save the day and the budget and look  
> good for picking the right thing.

Yes, this is a path we could have gone down. But the reality is, we  
didn't. Chandler wasn't designed to solve this problem. We partially  
solve this problem, but our target has been the thing I tried to  
describe in my initial email...It feels wrong to give up on that  
problem before we've given it a proper chance.

>> This is part of our target. But I think we can reach beyond this
>> audience. People start using tools like OmniOutliner on their own, I
>> don't see why Chandler can't reach the same kind of users.
>
> To a PIM geek, Chandler isn't even in the same league with  
> OmniOutliner (or its likely inspiration from the PC, Ecco Pro).
>
> Now, it might be that I'm wrong, and there are non-PIM geeks who  
> buy things like OmniOutliner.  Certainly some of them must be.  But  
> my general impression has been that PIM enthusiasts and other  
> people with the "productivity" otaku are the primary ones who  
> already *know* they want a PIM.  And Chandler compares less well  
> within that category, IMO, than it does in the calendar category.

 From our user interviews, I believe there is a significant  
population of people who spend a lot of time *managing their stuff*,  
but they aren't served well by bugzilla-like models for task/project  
management because the things they need to deal with aren't really  
concrete. They're things that people used to just keep track of in  
their head, but the modern workplace is swarming with this kind of  
amorphous 'stuff' coming at you from all different directions,  
pertaining to a dozen different contexts and it's now impossible to  
just rely on your head. In this way, we are trying to address the  
same problem as GTD.

> As Katie has put it, we have a few different centers of gravity:
>
> "Outlook killer" -- we simply don't stack up
>
> "GTD" -- Chandler's design philosophy directly contradicts that of  
> GTD on occasion, doesn't accept GTD's premises in other areas, and  
> doesn't provide any GTD-specific tools that aren't done  
> significantly better by other PIMs (even ones that aren't  
> specifically designed for GTD).  The only differentiating factor  
> here is open source+GUI.  Note that there are open source GTD tools  
> based on text-only/command-line operation, which just goes to show  
> how *much* demand there is for good GTD tools.  If we built an  
> actual, scripturally-correct GTD application, we'd have GTD fans  
> all over us -- but that would be a non-trivial effort, to say the  
> least.

The way I think of GTD is  that we're solving the same problem GTD  
solves for the individual. And then we're also solving the GTD  
problem for groups. Additionally, Chandler possesses a different set  
of benefits/deficits than the tools David Allen had available to him:  
Paper, Palm, Outlook, etc...

As a result, our take on GTD turns out to be substantively different  
from GTD methodology as described by David Allen. But the spirit of  
GTD is very much in the product.

In other words, in the same way that cars eventually stopped looking  
like horse carriages and were better off for it and synthesizers can  
do way cooler things than reproduce 'real', analog instruments, we're  
solving the same problem as GTD, but with different tools and  
materials, so the house we build is just going to look different.

I fully acknowledge however, that trying to shed people of their  
expectations around GTD and information managers is really, really  
hard. It's probably why my instinct is to avoid pitching Chandler  
around GTD and PIMs. But as you point out, that leaves us in the no- 
man's land of *products that nobody knows they want or need*.

> "small team collaboration" -- this is the only niche we actually  
> have any competitive oomph in right *now*, but even so we will not  
> compete without defining a *new* subcategory/niche to be the leader  
> of.  That's primarily a marketing question, and it's primarily  
> directed *outward*, to the question of what people want, as opposed  
> to what we have.
>
> Unfortunately, I am not a "real" marketing person, so all this is  
> perhaps not as clearly elaborated on my part as I would like it to be.

Well, none of us are real marketing people. So we'll need to consult  
a real one before drawing any definitive plans for how we pitch the  
product. This discussion however is critical to helping us prepare  
for that consultation. Maybe we'll get really lucky and end up with a  
pitch that's smack on target with the problem we've been trying to  
solve all along. We may end up with a pitch out of left-field. We may  
end up pitching ourselves as low-maintenance group calendaring.

Regardless of what our pitch is, we still need a crystal clear  
picture of what we *actually are* as opposed to *the thing we pitch*,  
because there's *compromise for the sake of reaching a goal* and then  
there's just going after whatever's available. I think we can  
probably all agree on that one.

Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

At 08:27 AM 12/26/2007 -0800, Mimi Yin wrote:
>On Dec 21, 2007, at 4:15 PM, Phillip J. Eby wrote:
>>At 12:26 PM 12/21/2007 -0800, Mimi Yin wrote:
>>>I agree with the sentiment that we need to market Chandler in terms
>>>of what people already 'know' they want or need a solution for. I'm
>>>not sure it should start with calendaring.
>>
>>Fair enough.  It's simply the most obvious and fully-grown pony, as
>>far as I can tell.  :)
>
>Yes, I'm trying to change that perception :)

And I'm pointing out that it's not *my* perception you'll need to change.  :)

>>>For one, how do we differentiate ourselves from other web calendar
>>>services? The offline functionality doesn't seem compelling enough on
>>>its own.
>>
>>Doesn't that depend on who the user is?
>
>Just to clarify, I'm not saying that offline mode isn't incredibly
>useful. It's just that in my mind, 'Shared calendaring, now offline
>too!' feels like it lacks oomph as a pitch.

Actually, it's open source shared calendaring for small groups with 
web interop and offline.  No, it doesn't have much oomph, but the 
oomph it has is far more *communicable*, because it's easier to go 
viral.  A person can relay that message to their friends, but the 
"GTD alternative" message is difficult to communicate, even for 
you!  The average person won't have much of a chance.

>I'm not sure I'm following. The pitch I'm referring to *is* the
>problem we originally identified and designed Chandler to solve.

I understand that.  The problem with that pitch is that it's a new 
entry into an old and fragmented category (PIM), which inherently 
means that the competition is based on a "value" proposition, i.e. 
lower price and/or better features.  And in the PIM category, we 
mostly lose on features without being any better on price than some 
alternatives with more features.

If you want to go after a PIM-ish market, we will have to define a 
*new* category in which we are the leader.  But the approach you're 
proposing is that we compete (philosophically) with David Allen and 
by extension, every tool that says "we do GTD".

And if we do that, we will lose in the marketplace, because the 
product will not be perceived or believed as being superior, even if 
it really were.  (And I don't believe it is, for reasons I'll go into 
later below.)

>>>In many ways, the design
>>>we have today is in response to the 'just build a filtered view'
>>>approach to information management.
>>
>>So what about it is better (as opposed to merely different)?
>>(Where better is defined in terms of ultimate impact on the person
>>using it.)
>
>That, was the topic of my first email :) My claim is that if we can
>figure out how to orient people

That can be done, but it costs a LOT of time and money.

>so that they approach the product in
>the right state of mind (e.g. don't expect it to be a PIM, email
>client, traditional project manager)...it's an information / work /
>task manager people can actually stick with.

So now you're saying "lightweight PIM", essentially, unless you want 
to put some proof behind the "can actually stick with" part to create a USP.

If "can actually stick with" is the USP, then we'll need story/evidence as to:

* why people don't stick with other PIMs
* how Chandler avoids this problem
* examples of people who didn't stick with other PIMs, but did with Chandler

Of course, to do this, we need to define what "sticking" means - 
using it for a month? three months? a year? - and collect some evidence.

I'm not saying this to discourage the idea - if we could *prove* that 
USP, it'd be fantastic because it *would* be a new category.  But 
it's not enough to *say* it's a PIM people can stick with, we have to 
have some explanation and evidence to back that up.

>>We need to start from the other end: who needs this, what is their
>>pain, and what *emotional* payoff will they get from the solution?
>
>Yes. The pain is: I have too many bits and pieces of information to
>keep track of all in my head, but I can't seem to stick with any of
>the information-manager-type things I try, be it a paper-based list
>system, excel, project managers, task lists, outliners, etc.

Again, if the USP is going to be that you'll stick with Chandler, 
we'll need a compelling reason to *believe* that.  Otherwise, from 
the listener's perspective, it's just standard marketing fluff.  Why 
will they stick with Chandler, if they didn't stick with those other tools?

I think you'll find that what actually gets people to stick with an 
approach is the *religion*, not the tool.  Which is why, if we're not 
targeting features to attract members of "established" religions 
(such as GTD and F-C), we will likely have to create our *own* 
religion.  (Meaning someone will have to write our scriptures and 
preach our gospels, thereby adding more work to the process.)

Now contrast starting our own, to leveraging partnership with the 
existing "churches".  A free GTD or F-C tool increases the value (via 
the law of complements) of GTD training or F-C training -- the bread 
and butter of those "churches".  This means that we could get those 
organizations to promote Chandler at essentially no cost to us, with 
a host of other benefits accruing.  (That is, they would have 
financial motivation to collaborate with us.)

In contrast, creating our own religion means we have to do all that 
stuff ourselves, or convince other people to.

>The emotional pay-off is relief that I have a *trusted system* where
>everything is, it's easy to keep up-to-date,

How is this different from me writing everything on 3x5 cards and 
putting them in a card box?  That's also a "trusted system where 
everything is", and is "easy to keep up-to-date".

>it's shared with others
>so that organizing myself = organizing everyone else too,

Really?  How does putting *your* tasks into the system "organize" anyone else?

>AND it
>doesn't feel like a lot of busy-work because it's actually helping me
>get work done too, not just helping me keep track of the task
>representations of work.

What work?  Sending emails?

>Yes, this is a path we could have gone down. But the reality is, we
>didn't. Chandler wasn't designed to solve this problem. We partially
>solve this problem, but our target has been the thing I tried to
>describe in my initial email...It feels wrong to give up on that
>problem before we've given it a proper chance.

To be honest, I don't think we've solved that problem, or even 
adequately defined it.  But even if we had, that's an orthogonal 
problem to communicating or selling the solution.

To communicate, we have to have a message that gets people's 
attention -- specifically, the people in the target audience, which 
can't be defined as "everyone", because a message to everyone is a 
message no-one specifically wants to hear.  (Spam, in other words.)

To cut through the fog, it's necessary to have either a sufficiently 
well-specified group that the target audience identifies with (e.g. 
left-handed firemen), or a sufficiently clear benefit/USP that the 
target audience will say, "yes, I want that" (e.g. pizza in 30 
minutes or it's free).

So if we're not niching by identity, we need a USP, which has to be 
concrete.  For example, if we're going for, "the PIM you'll actually 
use", we'll need to be specific about what that means and offer proof.

> From our user interviews, I believe there is a significant
>population of people who spend a lot of time *managing their stuff*,
>but they aren't served well by bugzilla-like models for task/project
>management because the things they need to deal with aren't really
>concrete. They're things that people used to just keep track of in
>their head, but the modern workplace is swarming with this kind of
>amorphous 'stuff' coming at you from all different directions,
>pertaining to a dozen different contexts and it's now impossible to
>just rely on your head. In this way, we are trying to address the
>same problem as GTD.

Except we are not actually *addressing* that problem, because 
Chandler actively *discourages* turning "stuff" into action.  This is 
the place where it diametrically opposes the GTD philosophy, which 
states that the only way to actually get things done is to convert 
your "stuff" into actions that are concrete.

It's almost like saying, "Chandler: the NEW way to avoid actually 
managing your work!"  :)

Now, I don't know what you mean by "bugzilla-like", but I sure as 
heck don't like bugzilla and wouldn't use it as a model for anything, 
let alone group task management.  In my last position, I designed and 
implemented a "viral" group task manager that successfully took over 
a 2400-person company, even in the face of management opposition, 
displacing various purchased solutions whose costs ranged from 
$100,000 up to $10,000,000.  (These systems could probably be 
described as Bugzilla-like, in the sense that they were also 
abominations against humanity that should be cast into the nearest 
lake of fire.)

So I know a little bit about group collaboration -- large as well as 
small.  Enough to know, anyway, that the success of a system will be 
determined by what things it makes easy and what things it makes 
hard.  What it shows you, and how many steps it takes to see or do 
something, will determine what people will actually do.

And based on that experience, my hypothesis is that people using 
Chandler will not do anything significantly different from what they 
already do (or don't), nor anything significantly different from what 
they would do if they were using a paper calendar and a to-do 
list.  Because Chandler provides no cognitive support for doing anything else.

In other words, it doesn't make it any easier for you to turn "stuff" 
into action, than to just keep putting off your "stuff", the same way 
you already do.

>The way I think of GTD is  that we're solving the same problem GTD
>solves for the individual.

I'm sorry, I don't know any nice way to put this.  The only way I can 
conceive of someone making this statement about Chandler is if they 
have completely missed the point of GTD.  Because Chandler totally 
*ignores* the single biggest problem GTD sets out to solve: the 
ill-defined (and therefore non-actionable) nature of work.

GTD solves this by defining a system of workflow whose purpose is to 
*eradicate* "stuff" -- not keep it around!

>  And then we're also solving the GTD
>problem for groups.

No more than for individuals, which is not at all.

>Additionally, Chandler possesses a different set
>of benefits/deficits than the tools David Allen had available to him:
>Paper, Palm, Outlook, etc...

Actually, the only benefits/deficits that are relevant to any of the 
"established" religions are those of the human brain.  The only 
things that the tools do, is change how easy it is to implement the 
intended workarounds for brain shortcomings.

F-C emphasizes workarounds for strategy-level shortcomings of the 
brain, while GTD emphasizes workarounds for tactical 
shortcomings.  OPA/RPM is somewhere in the middle.

None of these religions have anything to do with the specific tools 
used to *implement* them; all have changed and refined their tools 
over the years, while remaining largely invariant in terms of the 
cognitive shortcomings they're designed to work around.

>As a result, our take on GTD turns out to be substantively different
>from GTD methodology as described by David Allen.

Definitely!

>But the spirit of
>GTD is very much in the product.

Then one of us has a deeply profound misunderstanding about either 
GTD or Chandler, or both, because as far as I can tell, what you've 
said (and what Chandler does) is diametrically opposed to GTD.

>In other words, in the same way that cars eventually stopped looking
>like horse carriages and were better off for it and synthesizers can
>do way cooler things than reproduce 'real', analog instruments, we're
>solving the same problem as GTD, but with different tools and
>materials, so the house we build is just going to look different.

[silent sound of jaw dropping]

I think you have this backwards: Chandler is actually the horse 
carriage in this analogy.

>I fully acknowledge however, that trying to shed people of their
>expectations around GTD and information managers is really, really
>hard.

It's even harder if you don't understand what GTD is or why people 
actually like it.  Of course, I'm not saying that every GTD user 
actually understands GTD, either!  But GTD fans aren't going to pick 
a tool that doesn't at least superficially mimic the totems of GTD, 
cargo-cult style.

If you want to sell *against* GTD, then you need to have an appealing 
alternative philosophy.  For example, LifeBalance claims that their 
approach improves on GTD by organizing your priorities and balancing 
the amount of time you spend on different things.  Whether this is 
true or not, it at least *sounds* like it would be an improvement, 
because it offers a believable explanation, backed by the product features.

At the same time, LifeBalance at least offers a strong implementation 
of GTD-style contexts, and thus attracts GTD fans.  (It also has good 
support for projects in an almost-but-not-quite-GTD way.)

My point isn't that LifeBalance is "better" than Chandler or GTD, 
just that it is designed in a way that lets it *sell* to people 
interested in GTD -- or Franklin-Covey, for that matter.

Why?  Because it focuses on automating the *tedious* parts of using a 
personal organization system like GTD or F-C.  In contrast, the only 
part of Chandler that helps reduce an individual's tedium in applying 
a personal organization system, is that you can use collections for 
contexts.  And even then, it's only a time saver over paper when the 
action needs to live in *multiple* contexts.  (Since on paper I can 
just write the action down on the right 3x5 card to start with.)

I'm not aware, right off, of any other way in which Chandler is an 
improvement over paper, for an individual who's trying to apply GTD, 
F-C, RPM/OPA, or any other time/life management "philosophy" I've 
encountered.  (Or at least, an improvement that isn't also provided 
by a significant number of other PIMs, and is thus reduced to a 
required bullet point, from a marketing perspective.)

In contrast, successful PIMs nearly *always* offer at least one 
"killer" feature that actually uses the computer to do something that 
would be woefully impractical if you used paper.  That is, they offer 
"car" features instead of just "horseless carriage" 
features.  Chandler's few "car" features (recurrence, timezones, date 
parsing, and putting the same item on multiple lists) are just 
keeping up with the competition, not putting it ahead.  (That is, 
they are all features found in last year's "car" models.)

>It's probably why my instinct is to avoid pitching Chandler
>around GTD and PIMs. But as you point out, that leaves us in the no- 
>man's land of *products that nobody knows they want or need*.

Yep.  We are in agreement about that at least, although we differ as to why.

>We may end up pitching ourselves as low-maintenance group calendaring.

I like that turn of phrase, it's a good addition.  "Low maintenance" 
sums up the benefits for the IT/sysadmin audience that would be most 
able/likely to viralize the message.

>Regardless of what our pitch is, we still need a crystal clear
>picture of what we *actually are* as opposed to *the thing we pitch*,
>because there's *compromise for the sake of reaching a goal* and then
>there's just going after whatever's available. I think we can
>probably all agree on that one.

Actually, the big tension I see here is between "what we are" and 
"what we'd like to be" or "what we set out to be".

Compared to that, the tension between "what we are" and "what we 
pitch" is quite small, I think.

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

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

Hi Phillip,

I, and I would suspect many others,  really appreciate your valuable
insights in this thread about how to position Chandler. I am not quite
following what you've written about Chandler and its suitability for use
with the religion of GTD (love the analogy) and wanted to offer some
thoughts. Echoing one of your comments, perhaps I also have a profound
misunderstanding of GTD or Chandler (or both). You mention a LifeBalance
application, and I'm assuming you mean the Life Balance app by
Llamagraphics. Having used the Life Balance application for many years,
I don't understand how either the Chandler app or the Life Balance app
actively discourages (or encourages, for that matter) turning stuff into
action according to the precepts of GTD any more than or less than a 3X5
card does.

Might it be that a kind of philosophy/religion of Chandler Triage is
what is diametrically opposed to the philosophy/religion of GTD as
compared to the product of Chandler? Assuming even a religion of
Chandler Triage that has influenced the design of the Chandler product,
for me, to date, the religion of Chandler Triage is separable from the
product of Chandler. It may be that as I use Chandler with GTD that I
would be graded as failing to apply Chandler Triage. However, similarly,
when I use Life Balance with GTD, I fail at making any use of the
application's namesake, that is, at using the Balance tab to balance my
efforts across the top-level-items (LB-speak) in my Life Balance outline.

When I was using only Life Balance for day-to-day GTD, the most
significant selling point for me was that my information was accessible
from the tools I predominantly used then, Windows-based PCs and a Palm,
not the innovative tools intended to aid the balancing of one's efforts
across different arenas of life. I like and use (in my own way perhaps)
the Chandler triage features, but the current, most significant selling
point for me for Chandler is the CalDAV-based workflows for sharing of
items regardless of kind, that is, not only calendar items, with or
without the rites of Chandler Triage, or GTD for that matter.

Thanks, Andre

Phillip J. Eby wrote:
> Except we are not actually *addressing* that problem, because Chandler
> actively *discourages* turning "stuff" into action.  This is the place
> where it diametrically opposes the GTD philosophy, which states that
> the only way to actually get things done is to convert your "stuff"
> into actions that are concrete.
>
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

At 02:06 PM 12/27/2007 -0500, Andre Mueninghoff wrote:
>Hi Phillip,
>
>I, and I would suspect many others,  really appreciate your valuable
>insights in this thread about how to position Chandler. I am not quite
>following what you've written about Chandler and its suitability for use
>with the religion of GTD (love the analogy) and wanted to offer some
>thoughts. Echoing one of your comments, perhaps I also have a profound
>misunderstanding of GTD or Chandler (or both). You mention a LifeBalance
>application, and I'm assuming you mean the Life Balance app by
>Llamagraphics. Having used the Life Balance application for many years,
>I don't understand how either the Chandler app or the Life Balance app
>actively discourages (or encourages, for that matter) turning stuff into
>action according to the precepts of GTD any more than or less than a 3X5
>card does.

Lifebalance and 3x5 cards don't collect your email messages and 
encourage you to turn them into tasks without first defining the 
action to be taken or goal to be accomplished.

While it's true that you can enter ill-defined things into all three 
tools, LifeBalance at least nudges you in the direction of defining 
what place and aspect of your life those things fit into, along with 
relative ordering and importance.  Chandler and 3x5 cards have only 
the dimensions you define, starting from a clean slate.

>Might it be that a kind of philosophy/religion of Chandler Triage is
>what is diametrically opposed to the philosophy/religion of GTD as
>compared to the product of Chandler?

Yes, that's where the most dramatic opposition occurs, but even the 
smallest of practical barriers (e.g. hiding something in a menu vs. 
making it easy to access, let alone just not including a feature) can 
be a significant discouragement in practice.

>  Assuming even a religion of
>Chandler Triage that has influenced the design of the Chandler product,
>for me, to date, the religion of Chandler Triage is separable from the
>product of Chandler.

Indeed - and this is certainly the case if you use Chandler primarily 
as a calendaring tool.  And that's a key reason why I'm suggesting a 
positioning centered on calendaring applications, as that positioning 
doesn't require a new religion to be developed and promoted.

>It may be that as I use Chandler with GTD that I
>would be graded as failing to apply Chandler Triage.

Yep.  Of course, you will also have no more dimensions to work with 
than you would've had with 3x5 cards, and you will only have the 
minicalendar/preview area to serve as a visible "hard landscape" 
while switching between next action lists.  Personally, if I were 
doing GTD and using Chandler, I think I'd use Chandler strictly as a 
calendar, because I don't see that it provides any compelling reasons 
to enter tasks versus just writing them down.

>However, similarly,
>when I use Life Balance with GTD, I fail at making any use of the
>application's namesake, that is, at using the Balance tab to balance my
>efforts across the top-level-items (LB-speak) in my Life Balance outline.

Sure.  But LB, in contrast, provides lots of other incentives over 
plain paper, such as place-nesting and place-hours, which can be 
quite useful for a GTDer.  (For that matter, priorities and lead 
times, too, even if you completely ignore the effort and balance aspects.)

>When I was using only Life Balance for day-to-day GTD, the most
>significant selling point for me was that my information was accessible
>from the tools I predominantly used then, Windows-based PCs and a Palm,
>not the innovative tools intended to aid the balancing of one's efforts
>across different arenas of life.

Which is why I think that Chandler's useful selling points are in its 
on/offline+web, cross-platform, multi-protocol, open-source goodness, 
not in its organizational religion.

>  I like and use (in my own way perhaps)
>the Chandler triage features, but the current, most significant selling
>point for me for Chandler is the CalDAV-based workflows for sharing of
>items regardless of kind, that is, not only calendar items, with or
>without the rites of Chandler Triage, or GTD for that matter.

Yep - which is why I think that's at least one leg of the pony, right there.

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

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

Thanks much for your message. I think I understand better now your
points, and mine, for that matter. It seems to me that significant
proportions of the "pony" discussion are supported by assumptions and
the projection of our few personal and professional experiences and
preferences (and the projection of the feedback and preferences of those
interviewed by OSAF awhile ago) onto the many potential Chandler users.

For example, it seems to me that Mimi assumes that many people have
trouble sticking with personal organization tools (for which she
proposes Chandler as a solution for stick-to-it-ness). My differing
point of view is that generally it is more costly (in effort) to switch
between tools and systems than it is to evolve further ones personal
work flows with current tools. An example of high switching cost is the
challenge of taking a Life Balance outline over to Chandler's flat
lists. (Since I use Life Balance on Windows, I don't have available to
me the sync services with ical in the most recent Mac OS release build,
which possibly simplifies this challenge.) I used Life Balance for all
of my GTD implementation for a considerable length of time, and still
use it for some projects. My point being that the whether it is easier
to stick with Chandler or not, the cost to switch, even from less
functional tools, is fairly high.

More comments inline...

Phillip J. Eby wrote:
> At 02:06 PM 12/27/2007 -0500, Andre Mueninghoff wrote:
>> Hi Phillip,
>>
>> I, and I would suspect many others,  really appreciate your valuable
>> insights in this thread about how to position Chandler. I am not quite
>> following what you've written about Chandler and its suitability for use
>> with the religion of GTD (love the analogy) and wanted to offer some
>> thoughts. Echoing one of your comments, perhaps I also have a profound
>> misunderstanding of GTD or Chandler (or both). You mention a LifeBalance
>> application, and I'm assuming you mean the Life Balance app by
>> Llamagraphics. Having used the Life Balance application for many years,
>> I don't understand how either the Chandler app or the Life Balance app
>> actively discourages (or encourages, for that matter) turning stuff into
>> action according to the precepts of GTD any more than or less than a 3X5
>> card does.
>
> Lifebalance and 3x5 cards don't collect your email messages and
> encourage you to turn them into tasks without first defining the
> action to be taken or goal to be accomplished.

Perhaps we might need to agree to disagree about whether Chandler
"encourages" one to turn email messages into undefined tasks. I don't
understand quite how the mere existence of email integration in Chandler
provides such encouragement exactly. I would agree that Chandler makes
it quicker to do this via stamping as Kind, but as you point out, one
could just as well (and nearly as quickly) scribble on a 3x5 card the
subject line of an email message and have the same poor effect.
Likewise, in Life Balance, one could create a task, leave it in the
Anywhere place, and leave it be wherever in the outline it happens to
exist. There is nothing in Life Balance that requires one (nor in my
opinion encourages one) to do any further GTD-type front-end processing.
My point is that I believe that those intent upon implementing GTD will
implement GTD.

> While it's true that you can enter ill-defined things into all three
> tools, LifeBalance at least nudges you in the direction of defining
> what place and aspect of your life those things fit into, along with
> relative ordering and importance.  Chandler and 3x5 cards have only
> the dimensions you define, starting from a clean slate.
>
>> Might it be that a kind of philosophy/religion of Chandler Triage is
>> what is diametrically opposed to the philosophy/religion of GTD as
>> compared to the product of Chandler?
>
> Yes, that's where the most dramatic opposition occurs, but even the
> smallest of practical barriers (e.g. hiding something in a menu vs.
> making it easy to access, let alone just not including a feature) can
> be a significant discouragement in practice.

I agree about practical barriers, though my bar would seem to be lower
than yours and others with regards to Chandler and GTD. Nonetheless, I
would not suggest the current release of Chandler as a GTD tool for a
new GTD acolyte. (still milking your analogy...) (I haven't used F-C in
so long, I hardly remember the rituals. GTD was my antidote for F-C.) I
do use Chandler with GTD, but I have several hard-won work-arounds that
permit me some sanity. (If I had such a magic wand, to make Chandler
more "GTD-Compatible", I would add " <at> Waiting For" as a triage status,
and add (searchable) tags at the item level as a mechanism for assigning
GTD-Contexts.)

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.)
>>
>> Chandler Triage that has influenced the design of the Chandler product,
>> for me, to date, the religion of Chandler Triage is separable from the
>> product of Chandler.
>>
>>  Assuming even a religion of
>
> Indeed - and this is certainly the case if you use Chandler primarily
> as a calendaring tool.  And that's a key reason why I'm suggesting a
> positioning centered on calendaring applications, as that positioning
> doesn't require a new religion to be developed and promoted.

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. When I explain Chandler
in my own terms, I have yet to find others failing to have interest in
the potential of sharing items of all kinds, events included.

>> It may be that as I use Chandler with GTD that I
>> would be graded as failing to apply Chandler Triage.
>
> Yep.  Of course, you will also have no more dimensions to work with
> than you would've had with 3x5 cards, and you will only have the
> minicalendar/preview area to serve as a visible "hard landscape" while
> switching between next action lists.  Personally, if I were doing GTD
> and using Chandler, I think I'd use Chandler strictly as a calendar,
> because I don't see that it provides any compelling reasons to enter
> tasks versus just writing them down.

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. 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.

>> However, similarly,
>> when I use Life Balance with GTD, I fail at making any use of the
>> application's namesake, that is, at using the Balance tab to balance my
>> efforts across the top-level-items (LB-speak) in my Life Balance
>> outline.
>
> Sure.  But LB, in contrast, provides lots of other incentives over
> plain paper, such as place-nesting and place-hours, which can be quite
> useful for a GTDer.  (For that matter, priorities and lead times, too,
> even if you completely ignore the effort and balance aspects.)

I'm sure the very clever place-nesting and place-hours features in LB
are quite useful for many, and they were for me for quite awhile. (They
were somewhat fun and satisfying to set up in the beginning.) However,
over time, I found that the match between my actual real-life context
and the calculated-context-based list of action items presented by LB
was at best about 50%. In short, it wasn't worth the maintenance. For
me, the tidy compartmentalization of contexts such as  <at> Home and  <at> Work
just didn't match my real life. So perhaps I should seek counsel from a
GTD coach, but that was my experience. My point being that sometimes a
multiplicity of features that have arisen from the experiences and
preferences of a few can become collectively themselves a practical
barrier to adoption and stick-to-it-ness. It's interesting to me that
the Llamagraphics team protects their vision of LB's design model with
the same tenacity with which Mimi does so for Chandler (using Mimi as a
proxy here for all that has gone into Chandler). The Life Balance user
forums have their fair share of "since not this <feature>, thanks and
bye" type messages, similar to Chandler user list messages along the
lines of "no <feature> yet still? then not for me."

>> When I was using only Life Balance for day-to-day GTD, the most
>> significant selling point for me was that my information was accessible
>> from the tools I predominantly used then, Windows-based PCs and a Palm,
>> not the innovative tools intended to aid the balancing of one's efforts
>> across different arenas of life.
>
> Which is why I think that Chandler's useful selling points are in its
> on/offline+web, cross-platform, multi-protocol, open-source goodness,
> not in its organizational religion.

Completely agree.

Notably, if someone wants a feature that will enhance the support of
their particular organizational religion, open-source goodness provides
them the opportunity to build and contribute it.

>>  I like and use (in my own way perhaps)
>> the Chandler triage features, but the current, most significant selling
>> point for me for Chandler is the CalDAV-based workflows for sharing of
>> items regardless of kind, that is, not only calendar items, with or
>> without the rites of Chandler Triage, or GTD for that matter.
>
> Yep - which is why I think that's at least one leg of the pony, right
> there.

Yep. Well, heck, I sure seem to use a lot more words sometimes than
might be necessary, but I appreciate the opportunity to weigh in, and
thank anyone who actually read this far.  

Thanks, Andre
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

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  <at> Home and  <at> 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

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"
<pje <at> telecommunity.com> 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  <at> Home and
> > <at> 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

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

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

Hi Philip,

On Dec 19, 2007, at 10:31 AM, Phillip J. Eby wrote:

> To market to the early adopters who would promote Chandler to those  
> people by word of mouth, we need to either: 1) emphasize the  
> positive *differences* between Chandler and other PIMs, or 2)  
> successfully position Chandler as the leader of its own, *new*  
> category.

Yes, I agree with that. Articulating that =s finding the pony in the  
product for me.

> One category that Chandler could define and *own* right now would  
> be "lightweight team+personal calendar".  We could in fact strip  
> some features *out* of Chandler, and *still* lead this category.   
> In fact, it could be a *plus* to strip any features that detract  
> from leading that category or confuse the mission/position in our  
> minds or the customers'.  Simplifying the terminology and stripping  
> out any too-"innovative" concepts that require users to think or  
> read a manual, would be a big plus.  Meanwhile, most of the other  
> features you mentioned in your email (cross-platform, connectivity,  
> email, etc.) can all be positioned in terms of how they support the  
> "lightweight team+personal calendar" mission -- and nothing else.

I'm not sure we're on the same page with this characterization. But I  
think we need to go one level more concrete to have a fruitful  
discussion.

So following this line of thinking, what features might you strip out?

Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

At 02:24 PM 12/20/2007 -0800, Mimi Yin wrote:
>On Dec 19, 2007, at 10:31 AM, Phillip J. Eby wrote:
>>One category that Chandler could define and *own* right now would
>>be "lightweight team+personal calendar".  We could in fact strip
>>some features *out* of Chandler, and *still* lead this category.
>>In fact, it could be a *plus* to strip any features that detract
>>from leading that category or confuse the mission/position in our
>>minds or the customers'.  Simplifying the terminology and stripping
>>out any too-"innovative" concepts that require users to think or
>>read a manual, would be a big plus.  Meanwhile, most of the other
>>features you mentioned in your email (cross-platform, connectivity,
>>email, etc.) can all be positioned in terms of how they support the
>>"lightweight team+personal calendar" mission -- and nothing else.
>
>I'm not sure we're on the same page with this characterization. But I
>think we need to go one level more concrete to have a fruitful
>discussion.
>
>So following this line of thinking, what features might you strip out?

To be clear, I was speaking mainly about stripping features out of 
the *marketing* discussion.  For example, the summary table view, 
triage, stamping, and almost everything to do with email are not all 
that critical to a marketing message like, "Your team, your friends, 
your life: Bring them together, with Chandler."  Or "Your time is 
your life.  Use Chandler to share it."  Insert other appropriate 
marketing sound bites here.  :)

Those features don't have to actually be removed from the program or 
even change much, necessarily.  (Although I might, e.g. rename the 
addressing button, move the mail related buttons, or make other such 
tweaks to make it flow smoothly in demonstration.)

In fact, at the "demo the product" level, it seems to me that there 
are now two features I would *add*: the ability to see at all times 
whether there are unsynced items (e.g. some visual indication on the 
collection), and the ability to group collections and share those 
groups of collections via Chandler server.  (The latter would make it 
easy for a company to share some official collections like conference 
room schedules, work/vacation schedules, etc., while allowing users 
to keep those collections distinct from other "life areas", so to speak.)

So, not much change from where we are now.  I just think that the 
major features we have, get the most opportunity to *shine* if 
Chandler is positioned as a lightweight collaborative calendar.  We 
can do that really well -- and more importantly, I think we can 
*communicate* that idea really well, much more so than the much more 
abstract "new way to organize" ideas.

Certainly we can *also* say that for many people, Chandler may be a 
complete organizational tool, but I think that should be kept within 
the context of the "collaborative calendar" mission, e.g. "it even 
helps you organize tasks and mail, too!" rather than trying to lead 
with that message.  It's a supporting feature, down there with "can 
have plugins to add new features", rather than a leading feature like 
"reads and sends calendars to X number of servers, formats, and email".

I know, it's not as broad as what the project originally set out to 
do, but it's what we *have* now, and if we get the users we can 
always give them more later.  :)

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

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

My first late-night thoughts...the Chandler suite would benefit from a
summary "so-what", a simply stated "raison d'etre" in three bullet
points...a first shot at leveraging Mimi's pony/horse in the product
thoughts:

The "So-What" of Chandler
-Capture and triage information into a flexible, adaptable system
-Focus on what is important Now
-Integrate your personal and collaborative (team) work-flows

Andre

Mimi Yin wrote:
> Last week I wrote to the design list that we needed an articulation of
> 'the pony in the
> product': http://lists.osafoundation.org/pipermail/design/2007-December/008115.html
>
>
> Basically, it's back to the good ole elevator pitch. What's the
> problem we're trying to solve and how are we solving it and why do we
> think it's better than the competition.
>
> We had some good guesses when we launched Preview, but it's taken
> really using the app for the last few months for some of us to really
> 'get it'. 
>
> Here's a first pass at trying to articulate the pony. My hope is that
> this will help us formulate a crisp pitch that is compelling to our
> target audience. As I said in a past last email, I think part of the
> problem is that as product-builders, we have a clinical understanding
> of the problem that emphasizes how we *solve* the problem, rather than
> the symptoms of the problem itself. Users on the other hand,
> understand the symptoms. "Items in multiple collections" isn't
> compelling unless it is presented as a solution to a problem people
> can relate to. So here is an attempt to present Chandler and what it
> does in the context of problems people can relate to.
>
> CAVEAT: This is not intended to be landing page copy. This is simply
> an articulation of what Chandler is, so that we're all on the same
> page about what needs to be expressed in demos and other marketing
> material. Unfortunately, my pony turned into a horse, so suggestions
> about how to make this more succinct would be helpful.
>
> NOTE: A number of the concepts discussed below are our interpretation
> of "the spirit of GTD". I think it'd be worth identifying what they
> are so that we can talk about it clearly and consistently. (e.g. Don't
> over-organize. Don't over-plan. Make sure you allow yourself to do a
> free-form dump so you get everything out of your head.)
>
> Mimi
>
> =====
>
> THE PROBLEM
> You get bits of information from emails, more emails, IM chats,
> hallway conversations, post-it notes left on your desk, more email. At
> the end of the day, where's the source of truth? Where exactly are we
> having dinner? at what time? What are we supposed to bring? What's the
> agenda for the meeting exactly? Where's the final packing list? Not
> only do you need a 'source of truth' for yourself, you need it for all
> the different groups of people you coordinate, work, live, need to get
> through life with.
>
> *So you need a *trusted* system that can be your personal *source of
> truth*. The groups you work with need a *trusted* system that can be
> their *shared source of truth*. There are lots out there...why can't
> people seem to stick to any?*
>
> *I - THE PROBLEM WITH TASK MANAGERS TODAY: STRUCTURE GETS IN THE WAY*
>
> To wrap their head around what they have to do, people always start
> out by making a list/outline of all their projects and all their
> tasks. This 'structure it in order to get a grip on it' approach to
> task management has its deficits:
>
> 1. The structure itself locks out possibilities that don't fit into
> that structure. Have something random you need to follow up on that
> doesn't fit into your structure? Doesn't get written down. That's
> trivial, petty, you think to yourself. Besides, I don't know where I'd
> put it in this outline. I'll just keep track of it in my head.
>
> 2. As soon as new information comes to light, your outline gets out of
> date as you struggle to fit today's information into yesterday's list.
>
> 3. Lists and outlines don't allow you to focus on *just the stuff you
> need to attend to NOW*. Instead you see everything that's not-done,
> and a lot of it is stuff you're only hypothesizing you'll need to do.
>
> 4. Lists and outlines don't scale to hold and keep track of the
> disconnected ideas and thoughts you have that eventually coalesce into
> the 'work' you need to do. So even if you have a way to manage your
> *tasks* (aka *list of stuff you need to do*), you still have nowhere
> to store and manage all the stuff that constitutes the *substance* of
> those tasks. In that sense, task management seems like a lot of
> 'meta-work', busywork that doesn't actually help you manage the work
> you're actually doing.
>
> 5. Lists and outlines presume that you do things in a given order.
> First I will do this, then I will do that. In reality, we noodle on
> lots of things, all the time, at the *same* time. Coming up with ideas
> and questions, remembering one more thing to add to that list,
> spouting fully formed introductory paragraphs to the dreaded year-end
> summary, scheduling a meeting, coming up with an agenda for that
> meeting, writing meeting notes for last week's meeting...
>
> *CHANDLER'S SOLUTION*
>
> *1. Chandler doesn't start with a project outline. Chandler starts out
> with a dumping ground for *stuff*.*
> Dump everything out of your head into Chandler no matter how poorly
> thought through, trivial or seemingly irrelevant. Don't worry about
> what it is, when it needs to get done by, or what project it pertains
> to. Don't worry about where it belongs. It doesn't need to be a task
> or a meeting. Random thoughts are welcome. Anything that's taking up
> space in your head is welcome. Chandler isn't so much a task manager
> or a calendar as a mental *stuff* manager that helps you turn *stuff*
> into concrete, actionable, useful things like tasks, events, lists and
> messages.
>
> *2. Chandler takes a don't over-organize, iterative approach to
> organization.*
> Once you've gotten past the 'dumping' stage, Chandler helps you work
> your way through the pile with some out-of the box organizational
> affordances that help you process and make progress on the things you
> need to do bit-by-bit. 
>
> Chandler's organizational affordances are lightweight: (*)
> + Decide whether you want to deal with something NOW or LATER.
> + Create collections of items
> + Add items to Task lists and Calendars
> + Assign alarms
>
> Also, don't worry about regretting tomorrow how you chose to organize
> stuff today. Organization in Chandler is flexible so it never grows
> stale. Structure is 'additive' in Chandler so that there's never any
> 'opportunity cost' to organizing your data in a particular way.
> - Creating an event on my 'Family' calendar shouldn't preclude me from
> seeing it in my 'Personal' calendar. 
> - Tracking milestones on your calendar shouldn't preclude you from
> tracking them on your Task list as well.
>
> (*) Eventually, we would like to support more sophisticated
> organizational tools because sometimes, you just need to be that
> organized:
> + Clusters: A way to thread items together
> + Tags and user-defined attributes
> + Smart, user-defined views
>
> However, this functionality will be added in a way that is in keeping
> with Chandler's minimalist and flexible approach.
>
> *3. Chandler distinguishes between Not-Done and Needs to be Done so
> that you can focus on what you need to deal with NOW without losing
> track of the stuff you eventually need to deal with LATER.* You can
> assign alarms and/or add items to the calendar and they will
> automatically pop back into NOW. It's kind of like being able to time
> when you receive a reminder email from yourself.
>
> *4. Chandler isn't just for keeping track of what you need to do. It's
> for *doing* what you need to do. In this way, Chandler isn't so much a
> 'task manager' as a 'work manager'. *Unlike lists and outlines, each
> task you enter into Chandler is a discrete information item with it's
> own notes field. So your task item to 'Collect quotes for the
> presentation' **becomes** the list of quotes itself as you collect
> them in the Notes field over time. (This idea isn't easily discernible
> today. Adding support for a Document or Resource Kind would help
> highlight this aspect of Chandler.)
>
> *5. Chandler presumes that you're working on multiple things *at the
> same time, all of the time*.* Chandler isn't about listing out the
> order in which you're going to do things and then automatically
> telling you what you need to do next because the reality is, even the
> best laid plans are laid to waste by the constant stream of 'new
> information' we receive. Instead, you pick at-will what you want /
> need / can't help but focus on right NOW and work on them simultaneously.
>
> *II - THE PROBLEM WITH COLLABORATION TOOLS TODAY: WHETHER IT'S A WIKI
> OR SHAREPOINT, COLLABORATION TOOLS ARE NEVER INTEGRATED WITH PERSONAL
> TASK MANAGEMENT TOOLS. (WHICH IS WHY EMAIL IS STILL THE INFORMATION
> MANAGER OF CHOICE, IT'S THE ONE SOLUTION THAT INTEGRATES THE TWO)*
>
> *Now Chandler integrates personal and shared information manager too! *
> + You have equal access to personal *and* shared information in a
> single application.
> + The same notes, tasks and events can appear in both shared and
> personal collections so your personal 'source of truth' stays in sync
> with the 'group's source of truth'.
>
> *III - THE PROBLEM WITH A LOT OF SOFTWARE TOOLS IS THAT THEY'RE NOT
> AVAILABLE / ACCESSIBLE FROM EVERYWHERE*
> + Chandler is cross-platform: Windows, Linux and Mac. Install it at
> home and at work. Collaborate with others even if they're on a
> different operating system.
> + You don't need everybody in your group to use Chandler to enable
> collaboration. Send others to view and edit shared collections in the
> web browser instead. They don't even need to sign up for an account.
> + Chandler allows you to access your own data via the web browser.
> + Chandler doesn't assume that everyone you need to work with can or
> will use Chandler, which is why you can also collaborate on notes,
> tasks and events via email.
>
> + Chandler is working on ways to get data onto mobile devices.
>
> ===
>
> Elevator pitch: *Stuff manager for organized chaos? Work manager for
> organized chaos? Project information manager for organized chaos? Task
> manager for organized chaos?*
> *
> *
> ------------------------------------------------------------------------
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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

Yes 3 bullet points sounds about right :)

There's something we need to get across that speaks to people who are  
perhaps usually allergic to the idea of a task manager or project  
manager.

As in, Chandler is the anti-task manager, task manager. In the same  
way GTD is the anti-time management, time management system.

+ Don't spend a lot of time organizing yourself. Just dump what  
you're working on into Chandler.
+ Chandler helps you make progress and keep track of your work with  
Triage Status, custom alarms and the Calendar.
+ Work together as a group and manage group and personal work from a  
single place.

Mimi

On Dec 18, 2007, at 8:35 PM, Andre Mueninghoff wrote:

> My first late-night thoughts...the Chandler suite would benefit from a
> summary "so-what", a simply stated "raison d'etre" in three bullet
> points...a first shot at leveraging Mimi's pony/horse in the product
> thoughts:
>
> The "So-What" of Chandler
> -Capture and triage information into a flexible, adaptable system
> -Focus on what is important Now
> -Integrate your personal and collaborative (team) work-flows
>
> Andre
>
> Mimi Yin wrote:
>> Last week I wrote to the design list that we needed an  
>> articulation of
>> 'the pony in the
>> product': http://lists.osafoundation.org/pipermail/design/2007- 
>> December/008115.html
>>
>>
>> Basically, it's back to the good ole elevator pitch. What's the
>> problem we're trying to solve and how are we solving it and why do we
>> think it's better than the competition.
>>
>> We had some good guesses when we launched Preview, but it's taken
>> really using the app for the last few months for some of us to really
>> 'get it'.
>>
>> Here's a first pass at trying to articulate the pony. My hope is that
>> this will help us formulate a crisp pitch that is compelling to our
>> target audience. As I said in a past last email, I think part of the
>> problem is that as product-builders, we have a clinical understanding
>> of the problem that emphasizes how we *solve* the problem, rather  
>> than
>> the symptoms of the problem itself. Users on the other hand,
>> understand the symptoms. "Items in multiple collections" isn't
>> compelling unless it is presented as a solution to a problem people
>> can relate to. So here is an attempt to present Chandler and what it
>> does in the context of problems people can relate to.
>>
>> CAVEAT: This is not intended to be landing page copy. This is simply
>> an articulation of what Chandler is, so that we're all on the same
>> page about what needs to be expressed in demos and other marketing
>> material. Unfortunately, my pony turned into a horse, so suggestions
>> about how to make this more succinct would be helpful.
>>
>> NOTE: A number of the concepts discussed below are our interpretation
>> of "the spirit of GTD". I think it'd be worth identifying what they
>> are so that we can talk about it clearly and consistently. (e.g.  
>> Don't
>> over-organize. Don't over-plan. Make sure you allow yourself to do a
>> free-form dump so you get everything out of your head.)
>>
>> Mimi
>>
>> =====
>>
>> THE PROBLEM
>> You get bits of information from emails, more emails, IM chats,
>> hallway conversations, post-it notes left on your desk, more  
>> email. At
>> the end of the day, where's the source of truth? Where exactly are we
>> having dinner? at what time? What are we supposed to bring? What's  
>> the
>> agenda for the meeting exactly? Where's the final packing list? Not
>> only do you need a 'source of truth' for yourself, you need it for  
>> all
>> the different groups of people you coordinate, work, live, need to  
>> get
>> through life with.
>>
>> *So you need a *trusted* system that can be your personal *source of
>> truth*. The groups you work with need a *trusted* system that can be
>> their *shared source of truth*. There are lots out there...why can't
>> people seem to stick to any?*
>>
>> *I - THE PROBLEM WITH TASK MANAGERS TODAY: STRUCTURE GETS IN THE WAY*
>>
>> To wrap their head around what they have to do, people always start
>> out by making a list/outline of all their projects and all their
>> tasks. This 'structure it in order to get a grip on it' approach to
>> task management has its deficits:
>>
>> 1. The structure itself locks out possibilities that don't fit into
>> that structure. Have something random you need to follow up on that
>> doesn't fit into your structure? Doesn't get written down. That's
>> trivial, petty, you think to yourself. Besides, I don't know where  
>> I'd
>> put it in this outline. I'll just keep track of it in my head.
>>
>> 2. As soon as new information comes to light, your outline gets  
>> out of
>> date as you struggle to fit today's information into yesterday's  
>> list.
>>
>> 3. Lists and outlines don't allow you to focus on *just the stuff you
>> need to attend to NOW*. Instead you see everything that's not-done,
>> and a lot of it is stuff you're only hypothesizing you'll need to do.
>>
>> 4. Lists and outlines don't scale to hold and keep track of the
>> disconnected ideas and thoughts you have that eventually coalesce  
>> into
>> the 'work' you need to do. So even if you have a way to manage your
>> *tasks* (aka *list of stuff you need to do*), you still have nowhere
>> to store and manage all the stuff that constitutes the *substance* of
>> those tasks. In that sense, task management seems like a lot of
>> 'meta-work', busywork that doesn't actually help you manage the work
>> you're actually doing.
>>
>> 5. Lists and outlines presume that you do things in a given order.
>> First I will do this, then I will do that. In reality, we noodle on
>> lots of things, all the time, at the *same* time. Coming up with  
>> ideas
>> and questions, remembering one more thing to add to that list,
>> spouting fully formed introductory paragraphs to the dreaded year-end
>> summary, scheduling a meeting, coming up with an agenda for that
>> meeting, writing meeting notes for last week's meeting...
>>
>> *CHANDLER'S SOLUTION*
>>
>> *1. Chandler doesn't start with a project outline. Chandler starts  
>> out
>> with a dumping ground for *stuff*.*
>> Dump everything out of your head into Chandler no matter how poorly
>> thought through, trivial or seemingly irrelevant. Don't worry about
>> what it is, when it needs to get done by, or what project it pertains
>> to. Don't worry about where it belongs. It doesn't need to be a task
>> or a meeting. Random thoughts are welcome. Anything that's taking up
>> space in your head is welcome. Chandler isn't so much a task manager
>> or a calendar as a mental *stuff* manager that helps you turn *stuff*
>> into concrete, actionable, useful things like tasks, events, lists  
>> and
>> messages.
>>
>> *2. Chandler takes a don't over-organize, iterative approach to
>> organization.*
>> Once you've gotten past the 'dumping' stage, Chandler helps you work
>> your way through the pile with some out-of the box organizational
>> affordances that help you process and make progress on the things you
>> need to do bit-by-bit.
>>
>> Chandler's organizational affordances are lightweight: (*)
>> + Decide whether you want to deal with something NOW or LATER.
>> + Create collections of items
>> + Add items to Task lists and Calendars
>> + Assign alarms
>>
>> Also, don't worry about regretting tomorrow how you chose to organize
>> stuff today. Organization in Chandler is flexible so it never grows
>> stale. Structure is 'additive' in Chandler so that there's never any
>> 'opportunity cost' to organizing your data in a particular way.
>> - Creating an event on my 'Family' calendar shouldn't preclude me  
>> from
>> seeing it in my 'Personal' calendar.
>> - Tracking milestones on your calendar shouldn't preclude you from
>> tracking them on your Task list as well.
>>
>> (*) Eventually, we would like to support more sophisticated
>> organizational tools because sometimes, you just need to be that
>> organized:
>> + Clusters: A way to thread items together
>> + Tags and user-defined attributes
>> + Smart, user-defined views
>>
>> However, this functionality will be added in a way that is in keeping
>> with Chandler's minimalist and flexible approach.
>>
>> *3. Chandler distinguishes between Not-Done and Needs to be Done so
>> that you can focus on what you need to deal with NOW without losing
>> track of the stuff you eventually need to deal with LATER.* You can
>> assign alarms and/or add items to the calendar and they will
>> automatically pop back into NOW. It's kind of like being able to time
>> when you receive a reminder email from yourself.
>>
>> *4. Chandler isn't just for keeping track of what you need to do.  
>> It's
>> for *doing* what you need to do. In this way, Chandler isn't so  
>> much a
>> 'task manager' as a 'work manager'. *Unlike lists and outlines, each
>> task you enter into Chandler is a discrete information item with it's
>> own notes field. So your task item to 'Collect quotes for the
>> presentation' **becomes** the list of quotes itself as you collect
>> them in the Notes field over time. (This idea isn't easily  
>> discernible
>> today. Adding support for a Document or Resource Kind would help
>> highlight this aspect of Chandler.)
>>
>> *5. Chandler presumes that you're working on multiple things *at the
>> same time, all of the time*.* Chandler isn't about listing out the
>> order in which you're going to do things and then automatically
>> telling you what you need to do next because the reality is, even the
>> best laid plans are laid to waste by the constant stream of 'new
>> information' we receive. Instead, you pick at-will what you want /
>> need / can't help but focus on right NOW and work on them  
>> simultaneously.
>>
>> *II - THE PROBLEM WITH COLLABORATION TOOLS TODAY: WHETHER IT'S A WIKI
>> OR SHAREPOINT, COLLABORATION TOOLS ARE NEVER INTEGRATED WITH PERSONAL
>> TASK MANAGEMENT TOOLS. (WHICH IS WHY EMAIL IS STILL THE INFORMATION
>> MANAGER OF CHOICE, IT'S THE ONE SOLUTION THAT INTEGRATES THE TWO)*
>>
>> *Now Chandler integrates personal and shared information manager  
>> too! *
>> + You have equal access to personal *and* shared information in a
>> single application.
>> + The same notes, tasks and events can appear in both shared and
>> personal collections so your personal 'source of truth' stays in sync
>> with the 'group's source of truth'.
>>
>> *III - THE PROBLEM WITH A LOT OF SOFTWARE TOOLS IS THAT THEY'RE NOT
>> AVAILABLE / ACCESSIBLE FROM EVERYWHERE*
>> + Chandler is cross-platform: Windows, Linux and Mac. Install it at
>> home and at work. Collaborate with others even if they're on a
>> different operating system.
>> + You don't need everybody in your group to use Chandler to enable
>> collaboration. Send others to view and edit shared collections in the
>> web browser instead. They don't even need to sign up for an account.
>> + Chandler allows you to access your own data via the web browser.
>> + Chandler doesn't assume that everyone you need to work with can or
>> will use Chandler, which is why you can also collaborate on notes,
>> tasks and events via email.
>>
>> + Chandler is working on ways to get data onto mobile devices.
>>
>> ===
>>
>> Elevator pitch: *Stuff manager for organized chaos? Work manager for
>> organized chaos? Project information manager for organized chaos?  
>> Task
>> manager for organized chaos?*
>> *
>> *
>> --------------------------------------------------------------------- 
>> ---
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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

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

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

What's the 'pony in the product'?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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