Where are we at with stamping?

• Stamping is like flagging on steroids: add structured data instead of just one anemic flag
  • The metadata is "grouped" into "kinds". (e.g. you don't just want to add a start date, you want to add a duration as well).
  • OOTB these "kinds" are the pim kinds: calendar, task, communication. Most users will only ever use these kinds.
  • One could extend chandler with new kinds. Possible extenders are (1) web 2.0 python hackers (2) someone extending chandler as a business opportunity (3) pim enthusiasts who want a custom environment. When extending new kinds, its not just a matter of adding n new stamps to a list -- instead they should fit into a hierarchy, which helps the user manage the stamping mechanisms.
  • A "kind" can also imply a context in which the item can be visible. For example, a "calendar kind" event will have the correct attributes so that it can make sense in the calendar view context.

• Stamping and email
  • It helps to separate the idea of a "communications stamp" from the email message or messages that might be associated with an item. The communications stamp is about the metadata of who the event is from/to. It in theory could apply to multiple forms of communication (e.g. instant messaging).

• Stamping and implementation
  • Although we could implement it in many ways, one event with multiple stamps is really one item with one identity.
  • Annotations is likely a cleaner mechanism for implementing stamping.
  • Email messages associated with an item should probably be linked, with a communicatins "stamp" on the primary event.

• Stamping and linking
  • Stamping and linking are two different affordances. Any item may be stamped as a calendar event, and linked to several calendar events, for example.

• Entering data, displaying data
  • Mimi is experimenting with trying to "divorce the act of entering data from entering data into a specific field".
  • Mimi is experimenting with trying to divorce what gets displayed in the summary pane from individual semantic fields ==> display field vs semantic information like location or alarm or whatever
  • Mimi is experimenting with allowing display to change depending on context (what semantic information is displayed as a summary)