User View of Stamping

In most Personal Information Management programs, an Email stays an Email forever. A Calendar Event stays a Calendar Event. A Task stays a Task. You can't change one type into another.

Starting with Chandler Release 0.4, the distinction between item types -- what in Chandler-land we call "Kinds" -- got blurry. In Chandler, you can change an Item's Kind by pressing one of three buttons in the Detail View's Markup Bar. In Chandler-land, we call that "Stamping".

How you Stamp

The Markup Bar has three buttons that support stamping:

• one that looks like a letter for Mail Message
• one that looks like a checked box for Task
• one that looks like a clock for Calendar Event.

The buttons in the Markup Bar are toggle buttons - they toggle between the pressed an unpressed state. So when you select an Item in the summary view, the state of the buttons in the Detail View shows you which stamps are present on the Item, as well as providing an affordance to add or remove the stamp.

What you Stamp

Stamping is supported only on Content Items: Notes, Tasks, Mail Messages, and Calendar Events.

• Notes are the most simple Content Items. You can think of a Note as a piece of text that you might want to process in some way.
• Tasks have information and behaviors related to Tasks. Stamping something as a Task means that you can set who requested the Task, you can mark it "done", etc.
• Calendar Events have time information and behavior associated with them.
• Emails have email-specific characteristics like who a message is from or two; you can also send Mail Messages.

When you stamp an Item, you essentially add a bag of attributes associated with another Kind to your existing Item. Unstamping removes the bag of attributes associated with the stamp that was pressed. Stamping adds both data and behavior to an Item.

It is perfectly possible to Stamp a note as both a Task and as a Calendar Event. In that case, it would show up on your calendar, have a time associated with it, and be something you could check off as "done".

Conflicts

When attributes are added to an Item, conflicts can occur because different Kinds of Items sometimes have different notions of what their key attributes are. One example is what should be shown in the "date" column:

• For an Email Message the important "date" is the date it was received in the "dateReceived" attribute
• For a Calendar Event the important "date" is the event start time in the "startTime" attribute.
• For a Task, the important "date" is the "dueDate".

Other important attributes that have different semantics for different Kinds are "who" and "about".

For each Kind, Chandler keeps track of which attribute to display in various places. For example, it knows that when showing Emails, it should use the "dateReceived" in the "date" column. Chandler knows which attribute to display for each Kind, because each Kind has a "date" attribute which redirects access to the correct attribute. This mechanism is controled by using a "redirectTo" aspect on the attribute.

Thus if an Item has e.g. Email attributes and Task attributes, there is a potential conflict between the "dateReceived" and "dueDate" attributes. Which should be used?

We chose to address this problem by making a clear priority between the differnt kinds when stamping. Whichever kind has the highest priority, that kind's notion of a conflicted attribute wins. A Task always has highest highest priority, so any item that has task-ness will show the "dueDate" in the date column. Calendar Events have the next highest priority, followed by Mail message, and then Note.

When you stamp an Item, you are adding a new set of attributes. This is a lot like creating a new item - except that instead of creating a whole new Item, you are extending an existing item. The same code that's used to initialize a new item's attributes is used to initialize the new attributes of the extended item. This code can also check existing attributes and use those values to determine an appropriate default value. For instance, a new Calendar Event uses the current time to determine the default start time for the new event. When stamping a Task as a Calendar Event, it can examine the "dueDate" for the Task, and base the start time on that instead. For simplicity, Calendar Events always use the current time in our current implementation.

When you "unstamp" an Item, you remove the attributes associated with that stamp. This might mean that the date for an Item is no longer the date an event will take place, now it's just the date that the original Email Message arrived that spawned the event.

Notes in the Implementation of Stamping are available in the StampingImplementation wiki page.

-- DonnDenman - 20 Oct 2004