If stamping is the answer, what's the question again?

Stamping is becoming a go-to metaphor for adding behavior in Chandler, and I think this is a dangerous trend, because of user interface issues and problems in the implementation that make it ill-suited for those purposes. Today's IRC chat showed that we've got different conceptions about what stamping is and is for.

What is stamping, internally?

As implemented, stamping is a way of combining bags of Attributes into a single ContentItem. (A ContentItem is something persisted in the repository that can appear in a collection, be shared, be displayed in the detail view, etc. An Attribute is a named property of a ContentItem; attributes are strongly typed, though through interitance, it's possible to declare attributes that accept nearly any type of value. Attributes can be required or not, and have default values or not.)

Our implementation of stamping is infinitely flexible: it's internally possible to mix any two types, because the stamping mechanism assures that in the event of an attribute name conflict, one type or the other will "win". Complicating this, we've got an "attribute redirection" mechanism, where a "virtual" attribute name (like "who") can be redirected to different concrete attribute name on different ContentItem^? subtypes (like "creator" on Note, "from" on a received email, or "attendees" on a calendar event).

What is stamping, externally?

Chandler currently provides user interface to allow the user to perform stamping operations: we've got buttons in the detail view's markup bar let the user set any permutation of Note (no buttons checked), Task, Calendar Event, and/or Email.

Third-party parcels (or even internally-created ones, like Photo) support partial stamping: You can add or remove Calendar Event behavior to a Photo, but you can't remove Photo-ness.

Great, so what's the problem?

There are several problems, actually:

• Attribute redirection might be a handy concept on "read", but fails on "write": it's easy to present a "who" field as described above, but different strategies are required around editing "from" on an email and "attendees" on an event.

• Stamping doesn't deal well with un-stamping: conflicts between attributes don't "un-resolve" on unstamping as well as they "resolve" on stamping: I've got a bug now that when you unstamp an email, you lose the "about" value (because attribute redirection is used to map "about" to "subject" on Email, and "title" on Note).

• It's an extensibility nightmare. CPIA certainly supports adding additional stamping buttons to the markup bar, and additional icons to the application bar, but our UI will turn into a swamp if every third-party add-on adds another pair of icons.

• The biggest problem is that stamping doesn't map well to the problems users will actually need to solve:
  • our metaphor for inviting someone to a meeting is to stamp a Calendar Event as an Email and send it. That's fine on its own, but what about when you want to invite someone else, or when the original invitee responds with an alternative time and a conversation ensues?
  • I might want to send someone a Photo, so I might think it natural to stamp a Photo with Email-ness... but what about when I want to send two Photos?

Solving these problems will require a beefed-up mechanism for relationships between items, and confusion between that mechanism and stamping will be a problem for new users trying to understand Chandler metaphors.