[Design] Conceptual model for "stamping"

[Phillip J. Eby]

Hi.  I'm a new member of the Services group, and I've been spending a lot 
of time recently trying to catch up on Chandler's design by reading through 
the wiki.  I have no idea whether this is the right way or place to make 
this proposal, but I've got to start somewhere so I'll just jump in with 
both feet first, and hope they don't end up in my mouth.  :)

I've noticed that there are a lot of useful scenarios that have been laid 
out with regard to Chandler as a "triage" tool, which is very interesting 
because few PIMs deal with that very well.  However, as I try to trace 
those requirement scenarios forward through the UI design and down into the 
content model etc., I notice that somewhere there came this idea of 
morphing objects into other kinds of objects as a way to implement those 
scenarios.  But I can't seem to find any rationale that explains why this 
is a better idea than simply having stamps create new items that then link 
back to the source item.  (e.g. a task to answer a particular email by a 
certain date.)

I *do* see places where that idea (linked items rather than morphing) is 
mentioned, but then at some point the idea just seems to fade away.  I'm 
wondering what the issue was, because it seems to me that linked tasks 
allow you to easily plan multiple things in relation to a particular email 
for example.  (Like if it contains multiple tasks.)  It also seems to me 
that it allows the software itself to be much simplified if items only need 
to be of one "kind" at a given point in time.

(Also, for the user's mental-model, when I receive an email, the email is 
not a task.  I have tasks "for" or "in response to" those items.  I'd like 
to be able to see a list of those tasks attached to the email, and be able 
to click through from the task back to the email, but I have trouble 
envisioning how the email and the task could be the same thing, especially 
if there are multiple tasks.)

Last, but far from least, if a "stamp" is basically just a shortcut to 
create one or more action items for a content item, then this is a simple 
model but which opens up all sorts of workflow and document management 
possibilities, while still scaling down for an individual.

Let's say I'm an academic who has to peer review papers, and there is a set 
of steps I have to go through for each document.  The first time, I 
manually create the task list, then select them and say "turn this into a 
stamp", possibly doing a little editing to touch it up.  Then, from then on 
when I receive a paper to review, I stamp it "Peer Review" and it 
automatically puts a bunch of tasks on my list, with names of the form 
"Task Description for Item Name", like "Check references for Paper X", 
"Write preliminary review for Paper X", etc.

And, there are various degrees of fidelity/complexity that can be followed 
for this as to how much information is copyable/customizable/etc. in the 
process.

Anyway, this stuff doesn't really fit with the idea that the paper "is" a 
task, for example.  The tasks are separate, and they may fit into different 
activity contexts (per Allen/GTD next-action lists).  In some cases more 
than one task might be available to do first for the same item.

A related issue to all this is that there seems to be this concept that a 
"calendar item" is a thing, and that a task might be one, or vice versa, 
which seems to lead to some complications.  In particular, if Chandler is 
to help people work better, then it would be helpful to *not* support this 
confusion, since one of the main points of David Allen's work is to keep 
action items distinct from "stuff".

So, let me suggest an alternative way of thinking about this...

Suppose we say that there are "content items" and "action items".  A 
content item is just stuff.  It can be an appointment or event (whatever 
you want to call a thing that happens at some point in time), an e-mail, a 
document, a note, a folder, a project, a goal, a contact, whatever.  It's 
any noun, pretty much.

An "action item", on the other hand, is a verb.  It represents a "next 
action" in Allen's terms.  It could be delegated, deferred, or available 
for doing in some context.  (In a way, you could say that delegated is a 
context that's some other person, and deferred is a context of time, but 
it's probably not worth getting that general just yet.)

An action item can be "on" or "for" some content item, or it can be "on" 
another action item.  For example, once you delegate something, you may 
need a deferred action item in the context of that person, that indicates 
you should follow up after a certain point in time.  This is an example of 
something that could be modeled by the "stamp as template for a set of 
action items" concept.  That is, the idea of delegation could just be a 
stamp that lets you select a person and a follow up date, and then creates 
a message for you to actually delegate the task.  (And possibly also 
changes triage status on the base item.)

The calendar, on the other hand, is itself just a timeline with entries on 
it.  These entries are not action items and they aren't contact 
items.  They're just dates.  After all, a complex event might have several 
actual "entries" on the calendar.  Similarly, an action item might also 
"contribute" entries to the calendar for "Start by" and "finish by" times, 
as well as for history of work on a task.

Again, the key is that items aren't really calendar entries, rather they 
contribute entries *to* the calendar.  And content items aren't action 
items, they can be stamped with them, or become a source for them.

Actually, technically a stamp need not be limited to creating action items 
for a content item, it could just be the idea of creating related items, 
period.  After all, a task might need an e-mail or a document template.

Anyway, I'm rambling on a bit here but the basic idea I want to get at is 
that it seems to me that the idea of having stamps make other items "for" 
an original item, as compared to having stamps "morph" items, is:

* a better match for the user model and for Allen/GTD approach
* allows greater flexibility at the end-user customization level
* does not require coding/testing of lots of special case rules for how 
different attributes get handled during morphing
* allows the content object model to be simpler and more modular
* allows new parcels to easily contribute new kinds to stamp or be stamped, 
without leading to combinatorial explosion of morphing rules
* an easily-explained metaphor
* separates "stuff" from actionable items, providing better support for 
actually deciding what you want to *do* with your "stuff", versus just 
keeping it all in your inbox or kicking it back into your inbox.

So, given this, I'm wondering if there's something that I've missed in my 
reading of the design docs, and was hoping somebody here would have some 
insight.  It would actually make the software's implementation simpler and 
more modular (not to mention extensible by third-party parcels) if it 
didn't have to deal with objects being of more than one kind 
simultaneously.  (By contrast, so-called "destructive" morphing doesn't add 
nearly as much complexity and it clearly supports some meaningful use 
cases, so I'm not proposing to remove that.)

Viewing stamping as a mechanism to create template items (using the current 
item to supply data for the template) offers lots of interesting additional 
possibilities as well.  For example, replying to an email could simply be a 
"stamp" that creates a reply template, which means that people could easily 
create their own custom form responses for emails, for example!  (And it 
wouldn't require coding up a specific feature; it's a natural consequence 
of being able to make things into templates that are available in useful 
contexts.)  Stamps could be keyed for availability based on item type and 
categorizations, e.g. you could have stamps specific to "Emails from Joe" 
or "Events with Steve".

Anyway, if there's no use case for which "multiple simultaneous kinds" adds 
significant value, I'd like to propose dropping it as a feature.  (Although 
not necessarily removing it during the 0.5 timeline, unless doing so 
accelerates features or fixes; i.e. we shouldn't slow down 0.5 to take the 
feature *out*).

I have a lot more thoughts on the uses and implementation of templates, 
workflows, calendar mappings, etc. than I've written about above, but I 
figure I'll save them for later, since I might be completely embarrassing 
myself by having opened my mouth on this subject in the first place.  :)