The issues we're addressing

See Sheila's summaries on the design list:

• http://lists.osafoundation.org/pipermail/design/2006-April/004473.html
• http://lists.osafoundation.org/pipermail/design/2006-April/004471.html

There is a concern that Stamping does not solve for all relationship use cases, in particular:

• Stamping does not solve for one-to-many use cases
• There is no elegant way to transition from Stamping to more complex relationship use cases
• Edit and Update part of Stamping does not work well with how Email works, namely that each Email transaction is a separate item with different attributes.

From a design perspective, there is no such thing as a "generic" relationship. As a result, the design must offer different affordances for different kinds of relationships in different contexts. Stamping is merely one of them. We need to understand better, specific use cases for other types of relationships in order to figure out how to design for them. (ie. Linking, Embedding and Threads). This is what the Stamping Storyboards presentation intends to explain/address.

What's the point of Stamping?

1. To provide a loose framework for unstructured data.
2. A little MORE structure than storing information in Email folders, with even LESS hassle than dragging email messages into folders.
3. To give information transported via Email a longer lifespan in the hopes of improving the signal-to-noise ratio across our various communications channels. (By differentiating between Information Items and Chatter about Information Items. And recycling Information Items with Edit/Updates: See: HelpingUsersBeMoreMindfulAboutTheEmailTheySend)
4. The Everyday Man's version of Interoperability. Do you ever wish somebody could just send you an event that would just land on your calendar? a task that would just deposit itself on your task list? Barring getting the entire world onto the same "system", stamping is the next best thing.

Notes

Inspirations for stamping

• Outlook and how it handled xxx
• Observing how people used their email clients
  • people did everything in their email client: folder called "books", "events"
  • drag event into a folder, or flag it, to add semantics that the email had information about books or events
  • people don't keep databases of "books", but they have emails with information about books that they keep
• Add semantics for most common things, and give them "stickers" or "stamps"
  • this email represents a calendar event
  • this email represents a book

How should we explain Stamping to the person on the street?

1. A hack to help people PILE data in the right places.
2. A quick way to: (GTD) Put things where they mean something to you.

Misunderstandings about Stamping

Terminology note: We're using the term "information item" to refer to the user's idea of an item in Chandler. "Information items" may ultimately be the same as "ContentItems" in the current implementation, but we don't want to get too distracted by the current implementation.

1. An Email is NOT an "Information Item" in and of itself
   • Email is a wrapper tha allows users to transport information items back and forth.
   • By default, the user does not interact with Email. Although we can have a special affordance for inspecting email items.
   • Sometimes there is a close 1-to-1 mapping between the attributes of an user item and those of an email. But any similarities are incidental.
   • Instead, user items are: Messages/Correspondence, Notes, Tasks, Invitations, Documents, Photos, Contacts
2. "Information items" on the calendar are NOT always events, meetings or appointments.
   • Tasks with due dates
   • Projects with Milestones
   • Book or Movie Release dates
   • Holidays
   • Anniversaries
   • Person's Birthday: It would be nice to be able to click on a Birthday on the calendar and see the contact item right there: mailing address, photo, gift ideas, etc
   • Travel dates: With different start and end timezones for Flights
   • PTO, Sick-leave, Out of Office dates

Notes

• A "book" doesn't have to "meld" with a "calendar event" to be on the calendar.
• A "book" can be placed in the calendar context, or mailed around, in its own right.
• The calendar canvas is agnostic to what thing is on it, at some point in time needs to display something.

An alternate explanation for Stamping from the perspective of how we model the implementation

Stamping can be largely understood as a way of separating Data from Knowledge from Context, where:

• Data = Repository, Data model, What Users think of as Technology
• Knowledge = Domain model, User Semantics
• Context = Views and Information Spaces. Calendar, List, Map, Home, Work, Personal, Private, Shared with Family, Shared with Friends
• Please see Lee Iverson's paper for more: http://www.ece.ubc.ca/~leei/dkc-iri2005.pdf

Examples of how Chandler tries to adhere to this model

• Our KINDS are defined around User Semantics.
  • Email is not an Information Item Kind. Messages or Correspondences are.
  • RSS is not an Information Item Kind, it is a data type.
  • IM is not an Information Item Kind. Chat is. Chat's can happen over Email or IM.
  • The From field does not necessarily map to the from field of the Email that is used to transport Knowledge arround.
• Not all things on the Calendar context are necessarily Events with a Start time, End time, and Timezone.
• The same "Knowledge" should be able to appear differently in different Contexts.
  • A task in my Dashboard shows me who assigned the task to me and what my Personal triage status is.
  • A task in a shared Group task list shows me that it's assigned to me and what the Group triage status is.

Examples of systems that conflate all three

• OS: The File system Users interact with is a direct GUI interpretation of the file directory structure of the OS. The Semantics that users interact with (Folders, Files, Applications, Date created, IMAP, POP, Port 25) is a direct translation of the semantics of the technology.
• Implementing CalDAV in Scooby: Morgen explained the problems of not providing a layer on top of the Data structures in a recent mail to the Scooby list about how Scooby might address the 1-event in multiple collections problem:

Bobby wrote: As the tenets for Scooby's Target User Release are view-oriented, this is ok for now. However we do need to at some point address this problem and I would love to have notion of resources existing in multiple locations somehow be expressed in DAV or as an accepted extension to DAV. This was discussed on the Chandler Dev list a little while back and Lisa mentioned a couple of proposals that could help us here (http://lists.osafoundation.org/pipermail/chandler-dev/2006-March/005360.html)

Morgen replied: One problem with linking two resources via some sort of DAV extension is that in one collection, the publisher may have included reminder information in the icalendar body, but in the other collection not included reminders (because one collection is being shared with one audience, and the other collection is meant for a different audience).

In other words, the Data, doesn't understand about how to present itself in different Contexts.

What is Stamping NOT intended to solve

• Linking items together, aka 1-to-1 and 1-to-many and many-to-many relationships
  • Gotham is the location of the Apps meeting
  • Apps meeting is located in Gotham
• Embedding one item inside another item, aka hierarchical relationships
  • Adding a Photo item to a Contact item
  • Creating items while you type notes in the Notes field of an item. ie. As you're taking meeting notes, you can create Tasks, Meetings, Notes, Open issues, Documents.
• Threading items, aka sequential relationships
  • Conversation threads
  • Task threads (dependencies)
  • Event series

• Stamping is not the same as Tagging
• Stamping is not the same as Filing

Basic PIM use cases for Stamping

Based on behaviors observed through user interviews and research

• RECEIVED EVENT: You receive an email: Let's have lunch on Thursday at 2PM at Quintessence, here are the directions. You want to be able to "trip over" this information on the calendar, which is where you look to figure out where you have to be next and when.
• SENT EVENT: You are having a dinner party. You want to invite some friends.

• RECEIVED TASK: You receive an email from your friend who's looking for a new job: Could you give me some feedback on this cover letter? You want to be able to "trip over" this information on your task list, which is where you look to figure out what stuff you need to do.
• SENT TASK: Tax season is coming up. You want your spouse to do your taxes for you.

• SCHEDULED TASK: You have a task to go to UPS and ship your bike back to the manufacturer's for repairs. You've got all the info about UPS hours and rates in the task notes. You figure out a time when you can go and want to put all that info on your calendar.
• SENT SCHEDULED TASK: You're roommate has to ship his bike too. He's offered to do it for you and needs all the info about where to ship the bike to, etc.

• MEETING I NEED TO SCHEDULE: You've been asked to set up a post-mortem which will require a delicately crafted agenda proposal.
• MEETING I NEED TO WRITE UP NOTES FOR: After the post-mortem, you need to clean up your notes from the meeting and send them out to everyone. You're raw notes are in the notes field below the agenda.
• SENT MEETING NOTES: After you clean them up, you want everyone who attended the meeting + the rest of the company to see the notes. You want them to know what meeting it was for. What the agenda was for the meeting was. Meeting notes.

PIM 2.0 use cases (including items that fall under the Resources and Directories kinds)

Based on behaviors observed through user interviews and research

• LIST ON THE CALENDAR A shopping list for when I go to the Mall on Sunday afternoon.
• SENT LIST ON THE CALENDAR A shopping list of stuff I need my spouse to get me when he goes to the Mall on Sunday afternoon.

• DOCUMENT ON YOUR TASK LIST ON THE CALENDAR A proposal I need to put together by Monday.

Side effect: In this way, you actually begin to see some texture on your task lists and calendars. Instead of seeing a sea of undifferentiated "Tasks" and "Events", you start to see write-ups, errands, meetings, conversations, reviews, reading, etc. instead.

Experimental Web 2.0 use cases

Speculative use cases

• PERSON ON YOUR TASK LIST: Call irate client on the phone and find out what his problem is. Maintain a call log of every phone conversation you have with client in the Notes field of the Contact entry.
• PHOTO ON YOUR CALENDAR: Put photos on the calendar on the date they were taken. (Adobe Photoshop Album and Picasa do this).
• BOOK ON THE CALENDAR: You're a book publisher. You want to put out a calendar of when your books are coming out. Put books on the calendar on their release dates.
• MOVIES ON THE CALENDAR: You're running a film forum out of your basement. You want to publish a film calendar for the movies you're showing each month with the show times.

Notes

• Stamping a person on the calendar: can I put the person on the calendar in two places?
  • Not with stamping, but you could with linking. Remember that stamping is not an affordance for "advanced" modeling, its an affordance that is supposed to be similar to but better than flagging a message "unread" or putting it in a folder for semantic meaning.
• To put an item on the calendar you need a date. Can this be less generic than "a date"? (e.g. birthday vs death date vs start time)
  • We'll come back to this after the meeting

Storyboard for Basic Stamping

• StampingStoryboards.ppt: Powerpoint
• StampingStoryboards.pdf: PDF

The storyboard depicts an Invitation workflow from the perspective of the Meeting Organizer.

1. I create calendar event on my calendar.
   • Suggest an Agenda in the body
   • Stamp it to send it to Carol, Amy, Junior and Lars for review
   • Hit Send
2. I go to view the invitation from the My Mail collection
3. Carol (non-Chandler user) replies with suggestions for the Agenda and a better time to hold the meeting
4. Carol replies again with oops, another suggestion.
5. I return to the original Invitation to add Carol's suggestions
6. I'm making the changes and hit Update
7. The Invitation has been Updated.
8. Junior, another Chandler user makes some changes of his own and Updates the Invitation.
9. I go to Junior's Update to inspect the Message headers.
10. Amy, another Chandler user who is the sharing the invitation with me via a shared collection edits the Invitation some more, but doesn't hit Update. Because I am sharing it with her, I can see her edits.

Notes

• The differently colored text on the slides is just to focus attention in the storyboard.
• What if she updated an older event vs the most recent one?
  • What would the ui look like? How do we avoid your changes getting clobbered?
  • Mimi: maybe this wouldn't be a problem in practice, I can always go look at the "retired" item. Maybe it would and we'd have to do something about that.
  • This is also a problem with sharing -- probably we want a similar solution.
• Do you see your own messages back? (like in gmail)
  • Mimi: yes
• Go back to previous thread and comment on that -- can't update an older version
  • In discussions when people reply to earlier point -- that is chatter
  • Different use case from updating an "authoritative" version
• Will email threads/chatter work the way it does in other clients? Can I respond to an earlier chatter message? Yes
  • The point is to distinguish chatter from updating the "authoritative" item that you are building

Forwarded items and Sending updates to Newly added people

• If you receive an item as a Forward, you see who Forwarded the item, not the original From field of the item. ie. via Amy
• If you receive an Update to an item that you've never received before: You see who the item is From, not who Updated the item.

Relationship Types (the stuff that's NOT Stamping)

• Item-after-Item relationships: Threading
• Relationship_Types.ppt
• Relationship_Types.pdf

An exploration of different relationship types in Chandler and how they might be supported:

• Item-to-Item relationships: Linking
• Item-inside-Item relationships: Embedding

Notes

• Can user specifiy their own types/attributes?
  • Someday, yes, if we had a schema builder
• Parcels -- rather than think of data as kind app area with collection
  • distributed, knit into the experience
  • tool that user could download, useful to you because you use the service, and you'd like it to be more tightly integrated
  • mac mail client: see that someone is online in aim, if you have contacts in address book

• Still notion of from and to? MimiYin I've written up a more coherent response to this question: TheMeaningOfFromAndTo
  • Mimi: expediency: its simpler right now to just do from/to (from a design standpoint)
    • in actuality, Mimi organized the organization, ultimately, the management is the organizer
    • more generic from/to fields right now, people don't get stuck
  • Alec: you could change the organizer at any time
    • could be separate field for who the actual organizer is
  • Bryan: from/to feel very email specific
    • something is both an event and an email
    • different versions of that event
  • Mimi: events: all have been wrapped in email
    • they are all event invitations, and they have all been wrapped in email
  • Mimi: concerned about terminology that implies a very narrow workflow
  • Sheila: what is the most common use case?
    • is it more common to know who is the organizer
  • Mimi: I can't send out an invitation from the PPD team
  • Jeffrey:
    • People are wondering if there are semantics beyond from/to: wanting more semantics
  • Alec: I think from/to are not generic, they are email specific
  • Bryan: I'm worried there is too much magic in those fields
    • Mimi: the assumption is it will get sent to everyone in those fields
  • Mikeal: I think people will do communication medium first, and then stamp that as an event
  • Mimi: have you ever created a wiki page that is going to become a more official wiki page, edit it there, then promote it as a project page into the wiki? Have you ever created a draft email and saved it for later?
  • Jeffrey: I was assuming you'd say that you could do it in either direction.
  • Priscilla: the argument is that people will negotiate through email, and not through chandler
    • Sheila: how will people discover how to do this particular workflow?
    • Mimi: people naturally do that -- mimi sends the summary first and then eventually sends it to everyone -- behavior that people already kind of do, don't have the right tools
  • Alec: a lot of people are used to associating a bunch of information in emails, chatter
    • acknowledgement that there are two different
  • Grant: how do you propose that we do this in email? Its just in text, there is no way to help you if you just do it in text.
  • Mimi: how does the proposal impact that acknowledgement?
    • Alec: from/to is confusing
    • Ted: people might never think to edit from/to
    • Mimi: default is that its going to be you -- we'd like to see if you can edit it, more sophisticated use cases. Updated field being separate will be helpful. Outlook already does this, distinguishes.
  • Alec: could you demo outlook? Outlook in exchange setting.
• Mikeal: some of the workflows made a lot of sense. Concerned about default state of stamping -- 1:1.
• Use case: url item I want to send to multiple people
  • Mimi: could combine the threads
  • Alec and Mikeal: might want to have to different threads. E.g. "Waterfall" thread -- send to wife, send to dev list separately.
• "Sketchfest" -- put this on the calendar
  • stamp on calendar -- when the event is
  • stamp and send to mark -- chatter thread
  • stamp and send to jan -- chatter thread
  • would like two separate chatter threads
  • How would we create multiple conversations about the same item?
• Etiquette with invitations
  • organize food with one person
  • organize music with another person
  • kind of useful to see whole thing in one context
  • gap between simple stamping model, and multiple groups of people
  • no good story for complex case
  • invitations are related to each other and spawn different threads -- complex and hard from a design perspective, in the meantime we collapse it
  • do we display the branching thing in the summary view? might be useful to reconnect these threads
• Solving for the simple problem doesn't prevent us from solving the more complex problem in an elegant way
  • requires more ui
  • graphically display when conversations branch out into multiple conversations
• Use case: a series of meeting, a conference -- how do we handle threads about that?
• Use case: send email with one embedded ics file with three events
  • how would we handle this?
  • mimi: 3 embedded events in the message item
    • we could do things like stamp each one, or we could leave them
  • alec: how are embedded events represented?
    • mimi: might just see title/start time, but not whole thing because that might kill the detail view
  • alec: what if we also had a drop down, that would say new, can fill out the detail, maybe from and to come from the top level item, event details fill in
    • lisa: mixing metaphors
• john: both embedding and stamping have use cases that make sense
• mimi: you could have the notion of having a master item, uber communicated joke, everyone you ever sent joke to, every time you created the thing
• lisa: stamping affordance could be different from "create new thing in this cluster" affordance
• mimi, alec: slightly different case, new thread of messages about this event
  • might make sense to have a separate set of "to"s

• Can we get to some comfort zone with the simple use cases? Theory, we could improve that process dramatically with simple 1:1 modeling, and feel like it won't preclude us from solving sophisticated cases in the future.
  • eventually solve clustering
• Lisa: Afraid spot inbetween -- stamping but not clustering, might be confusing.
• Mimi: Its still much better than flag/folders
• Alec: worry -- if we solve stamping problem from design perspective.

List on the board

• What are the semantics and affordances associated with different notions of sender, addressee, attendee, etc?
• How do you have multiple, separate conversations about the same event, rss feed, etc.

The Communications Stamp (formerly known as Email Stamp) and Sharing:

Why it's important to unify Sharing and Sending Items via Email

• Why Alex's Mom won't use Flickr.
• She sends the whole family huge pictures all the time via Email.
• I tried to get her to upload her pictures up to Flickr from iPhoto.
• But no matter how many times I showed her, she wouldn't do it. Why?

• Email is just easier. If she used Flickr, she would have to:
  1. Upload the pictures to Flickr, which means tagging them, etc
  2. Go to the tag set on Flickr to get the URL
  3. Paste the URL into an Email and send it out. (AND, she can't add commentary to each picture in the Email.)
• Gap between Sharees and Non-Sharees
  • Some of us have Flickr accounts, some of us don't. She doesn't want her pictures to be public. But if she makes them private, recipients have to be Flickr users in order to view the photos.
  • As a result in order to use Flickr, she has to first go through the Flickr workflow to share photos with me and Alex and then do the workflow she does today with email to get the photos to everyone else. Just not worth the effort.
• Lack of a feedback loop: She doesn't feel the pain we do. She has a centralized repository of her photos in iPhoto, we end up with photos littered throughout email. However, as the person who is the source of most family photos, she's the one who decides whether we use a specialized sharing technology or Email.
• In other words, unless Sharing is as easy to use as Email, Email almost always wins.

What would her workflow look like in Chandler?

• She might "share" a Photo album with us.
• Add Photos to the Share
• Multi-select and Stamp 5 Photos to "send" to us
• A unified Detail view allows her to add comments to each Photo in 1 feel swoop
• A single click Send, sends us a capital-N notification about the 5 Photos that have been added to the share
• At the same time, she can have other people on the Message who aren't necessarily sharing the Photo album.

For more on this topic: See: http://wiki.osafoundation.org/bin/view/Journal/EmailAsAVerbAndInvitations

Comments

MimiYin 20060706 Brian K and I reviewed the Stamping Storyboards to talk about how email threads might work in the Beta / 1.0 timeframe and along the way, I noticed a few errors in the storyboards, some things that have changed since the storyboards were created and some things that should be changed based on Brian's feedback.

As Brian K moves forward with email work for Alpha 4, it seems this is an opportune moment to revisit the Storyboards to flesh out design and engineering issues.

Please review the new storyboards and respond with any questions or comments. http://wiki.osafoundation.org/bin/view/Journal/StampingStoryboards#StampingWorkflow

Sheila, we will need to work together to update the Stamping Spec accordingly. Brian K, please reply with amendments if I have misrepresented or missed anything.

Main changes:

1. In an effort to simplify the design, the Addressing Stamp in the Mark-up bar no longer displays different icons in tandem with the Communications status column.

2. Sent on, Updated on and Edited on dates have been added to the detail view.

3. Brian K pointed out that users might be confused about why the Send/Update button grays out sometimes. So I made the following changes. Other suggestions are welcome:

• After sending an item, the Send button label changes to 'Sent'
• After sending an item, the 'Send via' in the detail view changes to 'Sent via'
• After sending an item, the detail view displays the 'Sent on' date

The above is also true for Updated items

Some issues that came up:

1. Security. If users can receive event items in Chandler via email, how do we prevent someone from spamming users with recurring events that could potentially crash the repository (e.g. 10,000 recurrences, etc).

• e.g. When we pull down new event items via email, we don't automatically construct a stamped communications/event item from the email. Instead, we first ask users if they want to view the event and display the contents of the event in the body of the email, just like mail apps do with .ics attachments.
• Question: Is this just an email issue? Is this also a problem for sharing? RSS?

2. When displaying message headers, we need to be able to display both the short message headers, the long message headers and the raw source. The long message headers and raw source will be too long to display in the detail view. We will probably need to find a way to either pop them up in a separate window or put the text into a scrollable field like the notes field

Stamping and Ecosystem: What happens when a Chandler User sends out an invitation to other Chandler Users, Scooby Users and People outside of the Ecosystem

• Storyboards_Diagram.ppt: Storyboards_Diagram.ppt
• Storyboards_Diagram.pdf: Storyboards_Diagram.pdf

Edit and Update Scenario

A creates an invitation to send to BCDE

• B is a Chandler user sharing the invitation with A
• C is a Chandler user, not sharing
• D is a Scooby user
• E is an email user

B the Chandler User, Sharing with A

• B receives the invitation in their email client; AND
• B receives the invitation in their Chandler / Dashboard NOW section
• B can reply to the email in their email client; OR
• B edits the item in Chandler
• (A and D can see B's edits in Chandler and Scooby respectively, even before B has hit the Update button to Send out his edits.)
• B updates the item

• A receives the update in their email client as a separate email in the same thread; AND
• A receives the update to the original invitation item in their Chandler / Dashboard NOW section
• B receives the update in their email client as a separate email in the same thread
• C receives the update in their email client as a separate email in the same thread; AND
• C receives the update to the original invitation item in their Chandler / Dashboard NOW section
• D receives the update in their email client as a separate email in the same thread; D can click on a URL ticket to view / edit the item on Scooby
• E receives the update in their email client as a separate email in the same thread

C the Chandler User, Not-sharing

• C can see the invitation in their Chandler, in the collection they share with A as soon as A has created the item and a sync happens. The invitation is auto-triaged in C's Dashboard to Later, because it is an invitation for an event scheduled in the future.
• When A sends the invitation, C receives the invitation in their email client; AND
• C receives the invitation item pops into the NOW section of C's Dashboard
• C can reply to the email in their email client; OR
• C edits the item
• C updates the item

• A receives the update in their email client as a separate email in the same thread; AND
• A receives the update to the original invitation item in their Chandler / Dashboard NOW section
• B receives the update in their email client as a separate email in the same thread; AND
• B receives the update to the original invitation item in their Chandler / Dashboard NOW section
• C receives the update in their email client as a separate email in the same thread
• D receives the update in their email client as a separate email in the same thread; D can click on a URL ticket to view / edit the item on Scooby
• E receives the update in their email client as a separate email in the same thread

D the Scooby User

• D receives the invitation in their email client
• D can reply to the email in their email client; OR
• D clicks on a URL ticket to view/edit the invitation on Scooby
• D edits the invitation
• (A and B can see D's edits as D is making them (assuming background sync)
• D updates the invitation

• A receives the update in their email client as a separate email in the same thread; AND
• A receives the update to the original invitation item in their Chandler / Dashboard NOW section
• B receives the update in their email client as a separate email in the same thread; AND
• B receives the update to the original invitation item in their Chandler / Dashboard NOW section
• C receives the update in their email client as a separate email in the same thread; AND
• C receives the update to the original invitation item in their Chandler / Dashboard NOW section
• D receives the update in their email client as a separate email in the same thread; D can click on a URL ticket to view / edit the item on Scooby again.
• E receives the update in their email client as a separate email in the same thread

E the Email client User

• E receives the invitation in their email client
• E can reply to the email in their client

• A receives the reply in their email client as a separate email in the same thread; AND
• A receives the reply to the original invitation item in their Chandler / Dashboard NOW section as a separate email in the same thread
• B receives the reply in their email client as a separate email in the same thread; AND
• B receives the reply to the original invitation item in their Chandler / Dashboard NOW section as a separate email in the same thread
• C receives the reply in their email client as a separate email in the same thread; AND
• C receives the reply to the original invitation item in their Chandler / Dashboard NOW section as a separate email in the same thread
• D receives the reply in their email client as a separate email in the same thread