r2 - 22 Jan 2005 - 10:54:47 - MimiYinYou are here: OSAF >  Journal Web  >  MimiYin > StampingRevisited

Stamping Revisited

Phillip Eby, a new addition to our Services team asked some old questions about Stamping which yielded fruitful discussion on the design list. I've decided to put together a wiki page summarizing our conversation and expanding it to propose a more comprehensive mental model for Stamping and Kinds in the context of extensibility.

Phillip asked: Does everything [all Kinds] have to be morphable into anything [all other Kinds], simultaneously? Or [are we] really restricted to the Mail+Event+Task triad.

This question has been asked and discussed before and the answer has always been an unsatisfactory, we're pretty sure stamping is just for the PIM Kinds, but we wouldn't take that to the bank.

A little bit of brainstorming about extensibility brought out some interesting patterns which might help us put together a more concrete (albeit still "too early to tell") model for how stamping might scale.

For background on Stamping, also look at:

For really old stuff that shows how the Stamping idea germinated:

  • OrderToChaos
  • ImmutabilityIssueScenarios
  • PolymorphabilityWorkflowScenarios

Extensibility brainstorm

The ways in which Chandler might grow:

  • Communications
  • Email
  • IM
  • Text messaging
  • VoIP
  • Video conferencing
  • File sharing

  • Tasks
  • Agendas
  • Errands
  • Projects
  • Shopping lists

  • Time-sensitive Kinds
  • Appointments
  • Events
  • Holidays, Birthdays and other date-specific items that don't actually take up any particular amount of time
  • Time blocks for things like office hours,

  • Resource Kinds
  • Contacts
  • Restaurant directory
  • Accounts and passwords
  • Schedules for trains, planes, classes (this is different from each individual instance in the schedule, that would be a calendar item)

  • News Kinds
  • Websites
  • Newsgroups
  • Discussion groups
  • Blogs
  • Mailing lists

  • Document Kinds
  • Text documents (Notes, .txt, .doc, .html)
  • Slideshow presentations
  • Spreadsheets

  • Media Kinds
  • Photos
  • Movies
  • Songs

Looking at this list, I realized that there are actually 2 types of Kinds: Action Kinds and Object Kinds.

  • Action Kinds are verbs and just to be redundant, they perform an action (ie. Communicate, Do, Schedule, Disseminate).
  • Object Kinds are acted upon (ie. Email this Photo or Do something about this Document)

Both types of Kinds should be extensible. For example, someone might contribute an extension that allows you to one-click "Disseminate" a document via a mailing list, RSS feed, by posting it on a Newsgroup, publishing it to the web OR all of the above. (Effectively adding an Action Kind.) Likewise, someone might contribute an extension that allows Chandler to manage Documents. (Effectively adding an Object Kind.)

The key difference is that Action Kinds do something we've been calling Stamping (aka Add a pre-defined "bag of attributes" to the existing item) thereby morphing items to become items of hybrid Kind. Object Kinds are the objects of the Stamp.

My gut feeling is that while there is approximately n Object Kinds, there is a relatively limited set of useful Action Kinds.

  • Action Kind candidates
  • Communicate
  • Do (aka Task)
  • Schedule
  • Disseminate

Open issues

  • Does this change the UI? Probably not?
  • Does this change the content model? data model? This is a question for Engineering

Comments

MimiYin 20040121 Phillip had expressed concern about whether it was fair to say that items such as Emails, Events and Documents could be Tasks as well...That perhaps it would be more accurate to say that such items might generate a task or even multiple tasks and that a feature that allowed users to link or imbed multiple tasks to a root item would be more useful.

This is an old debate that was one of the first and hardest issues we tackled. I won't go into to much detail, but we decided to go with the Stamping or item morphing model for a couple of reasons:

  1. An important David Allen insight is that it is simpler to manage 1 item than 2. In other words, if you have a Document you need to work on, why not use the Document itself as the tickler mechanism rather than creating a separate task to remind you to go look at the Document. Especially if all of your data is virtual, creating and linking two items that are for all intensive purposes the same thing is a vestigial remnant of the physical "paper-clipping" world. Many task managers fail because they lack this exact insight and as a result they usually end up too segregated from the lives they attempt to manage. Another way of putting it is that the data model is often too explicit: drawing fine lines between action items (ie. Finish write-up) and the items that are to be acted upon (ie. The write-up) that the average lazy user isn't interested in maintaining.
  2. Of course, there are use cases and users who will not want to pollute their Documents with annnotations for the Task of Finishing the Document. Or perhaps, the Task of Finishing the Document itself requires 10 significant Sub-Tasks that really need to be managed as discrete, first-class items. In such scenarios, users can resort to a more robust workflow we call clusters where users can "cluster* multiple items together (ie. and Email that generates several Tasks). (See also AdhocCollectionsWorkflow and SummaryTableViewSpec#ClustersStoryboard.) This is the second reason why we decided to stick with Stamping. Stamping solves for one set of very lightweight use cases where users simply want to flag certain items so that they show up as David Allen-esque ticklers on their task lists. For anything more heavyweight, users will have other workflows (ie. clusters) to meet their needs.

As we move forward with Kibble and start to get real user feedback about Stamping, we will probably want to tweak the design for clusters (which is not making it into Kibble). Whatever the specific solution ends up being, the underlying philosophy is: we don't want to rely on the heavyweight solutions (ie. clusters) to address lightweight use cases (ie. tickling). While clusters theoretically meets the need for lightweight tickling by allowing users to cluster a Task with the Email That Generated The Task, the more cumbersome user experience outweights the advantages of using the feature. In a word, it's overkill.

MimiYin 20040121 Chao expressed concerns about the universal applicability of certain Stamping Kinds. For example does it really make sense to stamp a Photo as a Task? Well Photos are to Photo Editors what Emails and Documents are to the Information Worker. In the same way you or I might want to be able to tickle a Document for follow-up so that it shows up on the Task list, someone who works heavily with Photos might want to do the same with a picture.

We both agreed though, that for the average layperson, Photos as Tasks might be confusing OOTB. So while applying the Task Action Kind to the PIM Kinds might be easily accessible to all users OOTB, we should look at ways to make it harder for beginner users to trip over the less obvious applications of the Task Stamp.

MimiYin 20040121 Sheila pointed out that it's possible that you might even want to Stamp an Object Kind item as a Contact. (ie. Your friend Joe shares a photo of himself with you and it might make sense to be able to simply contact-ize this picture so that your contact for Joe has a picture of Joe.)

However, I think there is a subtle yet important distinction between this kind of "information transfer" and the more "action-oriented" use cases we've discussed thus far.

  • When you Communicate a Document, you actually want to do something to the Document, you want to pass it on to someone else.
  • When you Disseminate a Document, you want to publish it to the wider world.
  • OTOH when you Contact-ize a photo, you simply want to transfer the information in the photo (ie. the picture) to a Contact. But the photo isn't really the Contact. When you view the photo in a Photo album, you don't want to see contact information popping up. Instead, what you actually want is for the Photo to appear inside of the Contact item. (The same way you might want a Contact name to appear inside the To: field of an Email item.)
  • To give an example of a true Action Kind, when you Task-ize a Document, it might be because you want to follow-up, edit or read the Document. As a result, the Document actually represents the Task, they are one in the same.

Questions to ask ourselves when trying to establish whether an Object Kind could or should also be an Action Kind

  1. Does the Action Kind do something to other Object Kinds? Or is it simply a mechanism for information transfer between Kinds?
  2. When applying the Action Kind to another Object Kind, do you think of the item as representative of both Kinds? Is the Object Kind a representation of the Action Kind?
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.