Communications Design

Status Starting to put process proposal together for Communications design

Motivation We're hoping to put into one seamless user experience package, all use cases and workflows having to do with communications including:

• Email
• Communicating information
• Quick note
• Personal correspondence
• Organizing info
• Status reports

• SPAM and almost SPAM
• SPAM
• Newsletter
• Mailing list discussion
• External reminders (ie. Bank statements, stock quotes, sales, new movies)
• Forwards: Links and jokes

• Stuff that should really be items in Chandler
• Invitations
• Tasks
• Reminders to yourself
• Notes
• Contact info

• IM
• Characteristics Quick, easy, fun, low band-width, on-demand synchronous but can also be asynchronous, great way to multi-task, lightweight affordance for maintaining social bonds

• Social interaction
• Chit-chat conversation
• Informal invitations: Hey want to go out for lunch today?
• Share files and links: Check this out...
• Gossip

• Work
• Multi-tasking during meetings
• Work coordination
• Quick question
• Ping to see if someone is around for a conversation using a different mode (ie telephone, face to face, chat room)
• Presence management
• Reminders

• Sharing
• Views / collections: [OI^?] Which views?
• Task
• Invitations
• Contacts
• Notes
• Documents / attachments?
• IM?
• Email?
• Logs?
• Filters / Rules / Attributes (Schema)?

• Messages
• Voicemail

• Notifications
• Errorr: ie Rule violations
• Chandler activities: Synchronization, IMAP activity, Sharing activity, Maintenance, Log all actions?
• SPAM status
• Filter status
• Ticklers

• Sharing notifications
• Sharing circle status: Invitation offered, Accepted, Pending, Declined
• Share status: invitation offered, Accepted, Subscribed to, Pending, Declined
• Share termination
• Changes to share: Add to item conversation, changing an attribute, changing collection members, changing view layout
• Changes to ACL: Adding sharees, setting ACL
• Displaying share threshold
• Displaying changes in the detail view

• How do notifications appear?
• As an item in the Dashboard view
• As a contextual dialog
• In the status bar
• ChaoLam: What about OS-specific notifications (e.g. Mac OS: bouncing dock, Windows: system tray activity)
• [OI^?] Log of all notifications organized by time?

Brainstorming proposal

• Brainstorm each communications mode. Look for areas of overlap.
• Why do we send email? Can we categorize emails into types of email.
  • ie Personal correspondence (replaces letters)
  • Tasks
  • Calendar invitations
  • Share documents
  • Ask a question
  • Coordinate something
• What are different examples of notifications?

Use cases demonstrating why different modes of Communications needs to be discussed together
I need to ask my friend Jen if she can meet me at 7:30 instead of 8PM tonight for dinner tonight. If she can, I'd like to make a hair salon appointment for 4:30PM across town. If she can't, then I'll just make the appointment for some other time. It is 1:20PM right now.

I may not know how I will accomplish that (ie send an email, send an IM, change our shared calendar event, look up her phone number and give her a call). That will probably depend on

1. how quickly I need a response
2. how badly I want to this hair salon appointment
3. whether she's on IM
4. whether she's online
5. how frequently I think Jen checks her email / Chandler repository / voicemail or phone
6. if I'm going to have ready access to my email / Chandler repository / voicemail or phone for the rest of the afternoon

Workflows

Emailing Chandler task and calendar items back and forth

It would be nice if users can email Chandler task and calendar items back and forth without feeling like they have to send the task or calendar item as an attachment. The proposal below outlines how users can stamp incoming email as a task or calendar and then choose to either "update" the task / calendar item by "resending" it (effectively moving the stamp from the original email to the new "resent" email) OR simply continue a discussion about the stamped task / calendar item by "replying" to it. This is analogous to the distinction between editing a core attribute of a shared item / collection / view versus adding comments about a shared item / collection / view.

Scenario 1

1. Abe sends Barb an email
2. Barb stamps the email as a task
3. Barb edits the stamped email / task
4. Barb can either a Reply to Abe's original email OR b Resend her edited email / task

* Email_items_sc_1_01.gif:

• Email_items_sc_1_02.gif:
  

Scenario 2

1. Abe emails Barb a task
2. As soon as Abe hits send, the emailed task appears as a stamped task in Abe's Outbox
3. Abe edits the task and "resends" it, effectively moving the stamp from the original email to the "resent" email
4. Barb receives both emails. The stamp also moves automatically from the original email to the "resent" email in her Inbox
5. Barb can either a Reply to Abe's resent email OR b Edit the task and "resend" it, effectively moving the stamp again for a second time

• Email_items_sc_2_01.gif:
  

• Email_items_sc_2_02.gif:
  

• Email_items_sc_2_03.gif:
  

Hopefully by borrowing from the exising "reply to" v "resend" paradigm that exists in email clients today, we can help users understand the different between communicating about a task / calendar event and resending a new version of task / calendar event. Probably what will happen is that relatively beginner users will never "move" stamps just as novice users don't really know about the "resend" feature in email. More advanced users looking for more accurate and subtle representations of their information will "resend" Chandler tasks / calendar events in the same way they "resend" emails today.

Users will also be able to move stamps manually by dragging the stamp icon from one item to another in the summary view.

All of these emails, email / tasks, resent email / tasks should be automatically collected into a single communications ad-hoc collection thread.

An alternate mental model
Do we dare to the break the paradigm of the "uneditable email". Currently, emails that have been "sent" or "received" are not editable. However, with versioning, Chandler has an opportunity to allow users to edit their emails without losing data. For example, when users stamp emails as tasks / calendar items, the new item is essentially a task or calendar item and the original email is preserved as v.1 of the task / calendar item. Similarly, when users email out tasks / calendar items and then edit them, the original email they sent out is v.1 of the subsequently edited task / calendar item. The advantage of this proposal is that the detail view isn't cluttered with emails and task / calendar notes fields that in most cases will simply duplicate each other. However, by modeling emails stamped as tasks / calendar items as "versions" of the task / calendar rather than as closely related but separate items, users end up with fewer items to manage and don't have to think of email as a set of functionality orthogonal to or separate from tasks and calendars.

How would this work

1. User receives email
2. User stamps email as task
3. User clicks Edit (something like the Edit button in Apple address book)
4. An editable v.2 of the same content item is automatically created.
   • A banner at the top of the detail view tells the user that this is v.2 of the item and that the original v.1 of the item was received on...
   • Text and attribute values from the original v.1 of the item look different from any edits the user makes in v.2
5. User can click on v.1 to view original message, opening the ad-hoc collection in place
6. User can now reply to v.2 of Email / Task or resend v.2 of the Email / Task.
   • Replying to the Email / Task adds an email to the Email / Task's email thread ad-hoc collection
   • Resending the Email / Task "moves" the stamp from the original email to the resent Email / Task and creates a v.3 of the Email / Task.
   • You can think of "versions" of a content item as being orthogonal to an "email thread" about a content item.
   • Versions of the content item that have been sent out live in the same ad-hoc collection as the other emails in the email thread about the content item.
   • When you reply to an email, you reply to the most recently received, unedited version of the item.

• Stamped emails display "time received / sent" in the Inbox / Outbox, but they display "calendar time" in mixed views.

Stamping and Sending

Email v Sharing

What would make someone email an item as opposed to share an item? where an item is either a task or a calendar event?

1. Can't share. The recipient is or isn't a Chandler user.
2. Won't share. Privacy, user doesn't know recipient well enough to want to give them automatic updates.
3. Don't want to bother to share. User is sharing a casual item and user / recipient(s) don't want to bother setting ACLs or managing update notifications.
4. Afraid to share. User doesn't know what sharing is.

What are more specific scenarios for category #2?

1. Contact information, especially other people's contact information.
2. Item that has been shared to you by someone else.
3. Calendar event where the recipient is just an FYI recipient and isn't an active participant in the event / meeting so you don't want to bother them with constant update notifications.

What are more specific scenarios for category #3?

1. Passing on a party invitation.
2. Passing on FYI events.
3. Passing on a task that is short-lived and unlikely to change. (ie. Can you pick up some milk on the way home?)

Proposal for user mental model of emailing content items.

I'm proposing that we expand the notion of stamping to include all "items" that hold more than 1 bag of attributes. Thus far we have referred to stamping purely in terms of the ability to take an incoming email and adding bags of task or calendar items to it. Redefining stamping in more general terms would allow users to:

1. Directly send and receive tasks and calendar events as already stamped emails as well as
2. "Stamp" existing email (sent or received) as tasks or calendar events.

This makes stamping a more symmetrical user experience so that "emails stamped as tasks" don't look and behave differently from "emailed tasks".

Workflow proposal

Sending an email / event / task

1. Create new item (note)
2. Stamp it as email / event / task (in any order)
3. Click Send
4. Continue editing item (creates a new "modified by..." version of the item)*
5. Option to:
   • Send update of edits (aka Resends the email / event / task item)
     • There should be an option to only send update to newly added contacts
   • Send new email re: selected item (just an email communication about the email / event / task item)
6. Recipient must manually resolve updates

Receiving an email / event / task

1. Recipient receives email / event / task
2. Recipient edits email / event / task (creates a new "modified by..." version of the item)*
3. Recipient has option to:
   • Send update of edits (aka Resends the email / event / task item)
     • There should be an option to only send update to newly added contacts
   • Forward edited email / event / task item
   • Reply to email / event / task item (just an email communication about the email / event / task item). Chandler auto-populates the body of the reply email with the text from the Notes field of selected item.

Receiving an email and then stamping it as an event / task

1. Receive email
2. Stamp it as an event / task (creates a new "modified by..." version of the item)*
3. Recipient has option to: * Send update of edits (aka Resends the email / event / task item)
   • • There should be an option to only send update to newly added contacts
   • Forward edited email / event / task item
   • Reply to email / event / task item (just an email communication about the email / event / task item). Chandler auto-populates the body of the reply email with the text from the Notes field of selected item.

• If you edit a sent / received item thereby creating a new "modified by..." version of the item, your dashboard view / calendars / taskpads will display the most recent version of the item. Only your Outbox / Inbox will display all sent / received versions of the item.
• If someone else sends you an update of an item, you have to manually replace the existing version with the new updated version.

• sending_stamped_item.gif:
  

• stamping_an_incoming_email.gif:
  
  • Where things live
• All sent / received versions of the item exist in the Inbox / Outbox. All are editable.
• Only the most recently self -modified version exists in the Dashboard view / Calendar / Taskpads.
• User must manually replace old versions with modified versions that have been modified by someone else.
• All "non-current" versions of and communications [[http://www.illusivecreations.com/] [Calgary Web Design]] about the item live together in a single ad-hoc collections.

Below is an ad-hoc collection of an "email / thrask thread" exchange consisting of "resent" updates and email communications re: an email / task item. The same exchange is depicted twice, first from the requestor's viewpoint and then from the requestee's viewpoint. The ad-hoc collection gathers items from multiple collections. I've put the "official home" of each item in parentheses.

• Requestor's ad-hoc collection
• -->Sent Task: Please pick up milk on the way home (Outbox)
• Reply to Task: Sure thing (Inbox)
• -->Sent Update to Task: Please pick up milk and cookies on the way home (Modified by Requestor) (Outbox)
• Reply to Update to Task: Got it (Inbox)
• Received Update to Task: I'll pick up milk, cookies, ice cream on the way home (Modified by Requestee) (Inbox, Dashboard view)
• -->Sent Reply to Update to Task: Ooh, good idea (Outbox)

• Requestee's ad-hoc collection
• Received Task: Please pick up milk on the way home (Inbox)
• -->Sent Reply to Task: Sure thing (Outbox)
• Received Update to Task: Please pick up milk and cookies on the way home (Modified by Requestor) (Inbox)
• -->Reply to Update to Task: Got it (Oubox)
• -->Sent Update to Task: I'll pick up milk, cookies, ice cream on the way home (Modified by Requestee) (Outbox, Dashboard view)
• Received Reply to Update to Task: Ooh, good idea (Inbox)

Toolbar candidates

• Create new (Note, Email, Task, Calendar event)
• Reply to (Email)
• Reply all
• Forward
• Send update (aka Resend for Emails)
• Junk
• Delete
• Send / Receive

Sending as separate from Stamping

Below is an alternate proposal for a more traditional approach to sending Chandler items simply as email attachments.

• Email a Task / Event
• User can create a Task or Calendar event and then hit an "Email this" button to launch an email with the Task / Event as an attachment.

• Email and Share a Task / Event
• User can Share a Task / Event
• User can hit Notify to both initiate Sharing and send an Email with the Task / Event as an attachment or formatted text
• User can also hit "Email this" button to launch an email with the Task / Event as an attachment where the To: field is auto-populated by the non-sharing participants.

• Stamp an Email as a Task / Event and then Email the Task / Event
• User receives email
• User stamps email as a Task / Event
• User hits "Email this" button to launch an email with the Task / Event as an

Email as Notes

Oftentimes, we receive emails that simply contain important reference information that we would like to save, file and perhaps even edit and send / share with others. In our current sending / stamping framework, emails we send are really just notes with To: From: CC: BCC: fields. Should we allow users to edit their email (both sent and received) and save them as new "versions" of the email in a way that is consistent with the way we're treating Sent / Received Tasks and Calendar events?

This could easily become a basic, but powerful way for people to accomplish "wiki" like things just by using Chandler notes, email and sharing.

• Workflow proposal
• Receive email
• Click update
• Edit email
• Changes From: Ed, Updated by: Me, To: Me
• Creates new "version" of email / note
• optional Click send update

OR

• Receive email
• Click Reply, Reply all, Foward
• Creates new email
• Click Send

• Hairy issues
• What happens when you share an email?
• what happens when you share an email as a part of a larger collection?

Integrating IM / Email / Sharing

Probably not for Canoga, but IM and any other communications transport should be integrated a la Email and Sharing. Users shouldn't have to care about transport mode if they don't want to.

• Workflow
• Jenny: Want to go see a movie tonight?
• Chandler sends IM if Jenny is online.
• If not, Chandler sends an email.
• If Jenny is a Chandler user, Chandler shares calendar item invitation with Jenny.

There are other agent like features one could imagine that might try different modes of communication in different orders depending on the contact, urgency setting, other preferences set by the Sender.

180 degree turnaround: 3 types of content items

• Messages (Transport: Email, IM, VoIP^?)
• Information items (Tasks, Events, Notes)
• Resources (Contacts, RSS feeds, URLs, Documents)

• Messages
• Cannot be shared (except as a result of sharing a collection that contains messages)
• Cannot be edited (essentially functions as a communication log)
• Can be "converted" into Information items "destructively" (Chandler preserves original message in the Inbox / Outbox)
• Can be assigned Triage status, @context
• Can be marked as Needs reply, To be filed, Private
• Can be labelled

• Information items
• Can be "shared". Options:
  • Auto-updates
  • Manual updates
  • Sends text along with Chandler "item" so item is readable by non-Chandler clients
• Can be edited
• Item-kind specific people attributes
  • Task: Requestor, Requestee, CC:, BCC: (cannot do auto-updates to BCC: people)
  • Event: Organizer, Participants, CC:, BCC:
  • Note: From:, To:, CC:, BCC:
• [OI^?]Can be "converted" into a message destructively
• Can be "converted into each other destructively
• Can be assigned Triage status, @context
• Can be marked as Needs reply, To be filed, Private
• Can be labelled

• Resource items [Very much a strawman]
• Can be "shared". Options:
  • Auto-updates
  • Manual updates
  • Sends text along with Chandler "item" so item is readable by non-Chandler clients
• Only contacts so far can be edited
• RSS and documents can be assigned Triage status, @context
• Can be marked as To be filed, Private
• Can be labelled

Information items first

Anatomy of an item
In Chandler, "information items" are of primary importance where information items are items containing content of substance. ie. Tasks, Calendar events, Notes, Contacts, Documents, RSS items, Songs, etc.

How information items are "transported" and conversations about information items play a secondary, supporting role.

Today, the opposite is true. Email (the transport mechanism) is the center of our PIM universe and users go through all kinds of contortions in order to extract what they're really interested in (aka the information) from their email clients.

Hierarchy of items

• Primary information items
• Tasks
• Events
• Notes

• Resource information items
• Resource items are generally characterized by the following traits:
  • Relatively slow rate of newly created items
  • Relatively static (not edited very often)
  • Generally do not provoke "actions"
• Contacts
• Documents
• Mailing lists
• Newsletters
• RSS feeds

• Communications items
• Conversations via
  • Email (asynchronous)
  • Sharing comments (asynchronous)
  • IM (synchronous)
  • VoIP (synchronous)

Natural Task Workflow Tree
In Chandler, users will be primarily concerned with information items. Once an information item has been created, users can choose from a number of different transports to convey the information item to other people. (ie. Sharing, Email. In Canoga IM and other transports will be less integrated). This essentially turns the existing workflow tree on its head. In current PIMs, users generally decide a priori which application or transport they're going to use and then they tailor their content to fit within the constraints of the transport.

Workflow proposal

1. Create information item
2. Add people
3. Select transport
4. Send

Chandler will also help users distinguish between their transported "Information items" and supporting "Conversation items." Today your Inbox is littered with both, but it's very hard to tell the difference between emails that contain real information and emails that are simply "conversations" about the real information. (This is not to say that conversation threads about information items do not themselves contain valuable information. However, it's probably safe to say that most users intuitively grasp the difference between pre-digested "drafts" of a document and un-digested free-form comments about a "document".)

Workflow proposal

1. Create information item (original version of information item)
2. Send
3. Receive re: information item (conversation item)
4. Update information item
5. Re-send (new version of information item)

Replies to and forwards of information items are considered supporting communications about the item. Edited re-sends of the item are considered newly modified versions of the information items. That being said, we understand that it is still very hard to judge when a conversation item might turn into an information item. In truth, it's often less of a binary decision (Communications v. Information) and more of a gradient (80-20, 70-30, 40-60, 20-80). As a result, we don't want to lead users through a heavy-handed workflow where they must choose to explicitly flip a switch to turn conversation items into information items. ie. Click here to turn email (communications item) into a note (information item) that has been emailed.

Instead, users should be able to express both

1. that they have a desire
2. and the extent of their desire to treat a communications item as an information item (or vice versa) in a direct workflow.

• Use case
• Martha is drafting a cover letter to apply for a job. She has enlisted the help of her friend Jane who will act as an editor while Martha remains the primary author.
• Martha sends out a first pass at the cover letter with a little note at the top: Blegh, this is crappy but it get's the main idea across. Having trouble with structure.
• Jane replies: Can't look at it now. Will look at it tonight. (Clearly a communications item.)
• Later on that night, Jane reads over the letter and makes edits as she reads, creating a second, modified version of Martha's original draft. When she's done, she writes a little note at the top: Good first try. Here are some minor edits and comments about each paragraph in-line. I've also moved your last paragraph to the beginning. I think it works better as an opener. Jane clicks Resend or Send update (20:80::Communications:Information)
• Meanwhile, Martha has been editing the original draft she sent Jane. When Jane's newly revised draft is delivered, it appears as a new, unread item in Martha's Processing bin as the version that Martha, not Jane was editing with a flashing dialog overlay that says: Jane has sent a new version of this item, do you want to override your changes with hers?
• Martha clicks no and Jane's draft becomes v.2 of the item while Martha's draft becomes v.3
• Martha goes back to Jane's draft to look over her changes and sends back a quick reply: Wow thanks Jane, I was heading in the same direction. (Clearly a communication item.)
• Martha goes back to her draft v.3, finishes it off, sends the letter to the hiring manager and BCC:s Jane. (Clearly the final version of the cover letter, but ironically in this case the information item is a communication itself: a cover letter.)
• Jane receives it as v.3 of the cover letter.
• Note In all places that the information item appears, only the latest draft appears. All previous drafts are accessed through an ad-hoc collection. Only the Inbox / Outbox display multiple versions of the same information item because they act as logs of everything that "came in" and "went out". [OI^?] Perhpas Inbox and Outbox should include all in and out traffic, not just email?

Editing for ourselves
The "Resend" feature already exists today in email clients. However, it is generally hidden as a power user feature in the menus. We're proposing to not only make it more accessible to users, but to allow users to edit their emails (sent and received) without first clicking "Resend". Oftentimes, we receive information items as communications items (email) and wish to treat them as information items for ourselves without sending them out again (aka annotating email).

Centralized list of who's got what
Another added bonus of this model is that users can keep a centralized list of the people they have "shared" this item with. By treating "emails" as first and foremost information items (ie. 101 dirty jokes about Buddhist monks), users can simply add contacts (there will be an affordance to send an update just to newly added contacts) and keep track of everyone they've sent this item to. This is most useful for keeping track of everyone you've already sent an event invitation to. Instead of hunting through all of your email for a complete invitation list, it should all be in one place on the latest version of the invitation. If your invitees are also using Chandler, they can "edit" the To: field and send an update so that you can even keep track of everyone they've "fowarded" the invitation to. Who needs Evite?

• Use case
• Miracle of all miracles you got your mom to start using Chandler
• Day 1: Joke forward from Mom...A rabbi, a priest and a monk...
• Day 2: Amazon forward: Look they're having a sale on these lovely vases.
• Day 4: Here are some iPhotos from our trip to Maine.
• Day 5: Fwd: Here are some iPhotos from our trip to Maine.
• Day 5: Re:Fwd from you: Mom you already sent me these. Don't hit forward, the next time you want to send out the same thing, just add me to the list you already made.
• Day 7: Mom runs into Rabbi Lieberman who tells her a joke...A rabbi, a priest and a...
• Mom says: Hahaha, yes I know that one. I got it as an email. I must send it to my son.
• Mom races home to find the email
• Instead of hitting forward like she used to, Mom has been slowly trained by Chandler to think of her items first and foremost as "Information items". So she just adds you to the To: field
• Chandler pops up a dialog: Your son is already in the To: field
• Another spam from Mom averted

Fall out: Wiki product for free
The most interesting fall out of this approach is that inspite of ourselves we're going to end up with a workable wiki replacement in Canoga after all (knock on wood.) By

1. depricating email to "transport" status
2. elevating the notion of an "information item",
3. distinguishing it from "communication items" and
4. making the transition between the two seemless and easy, it will become easier than ever for members of a small working group to create collaborative documents with centralized "who can see this" lists that are also linked to relevant correspondence about the document.

What this model doesn't provide is a way to collaborate on a centralized taxonomy to organize collaborative documents. However, it is precisely this decoupling of "content" from "organization of content" that might save Chandler from sallying forth down the miserable path to failure of most collaborative documentation systems. Shared taxonomies are notoriously hard, a science unto itself. Libraries employ legions of workers just to maintain them, much less build and invent them. In our so-called modern jell-o digital world, it is simply too easy for well-meaning collaborators to f*&(#$-up even the most carefully plotted out taxonomies by simply misfiling or worse by "changing" the very structure of the taxonomy.

Ease means speed and in no time at all (usually about 2 weeks for a group of 5 people collaborating in one taxonomy), the "shared" understanding of how things are organized is neither shared nor organized.

As a result, it will be interesting to see how well a "decentralized" content collaboration system can work. The downside is that the world can't simply go looking for stuff that hasn't been specifically sent to them. (It's a by invitation only party.) However, the reality of current shared taxonomies is that

• It's incredibly hard if not impossible to find useful information without knowing where to look (ie. getting a link or invitation from someone)
• The most frustrating thing is that once you've found it, it's impossible to find it again without bookmarking it and filing the bookmark...which is essentially a "decentralized" content collaboration system.
• The only thing left to ask is: Why not build this "decentralized" taxonomy affordance into the collaboration product to begin with?

Advantages of the Chandler collaboration system

• As easy as email
• Integrated into your PIM and what a PIM
• Seemless transitions between Email (communications) about content and Content itself
• Ad-hoc collections keep it all together (versions and communications)
• Decentralized taxonomies (you can file it anyway you want and find it anyway you want)
• Centralized "To:" fields (Right now, for any wiki page, I have only a vague idea of who knows that the page exists and who doesn't.)
• By invitation only, you only have to deal with the information you need

Caveat Shared taxonomies are good for large groups (ie. OSAF community) where the users are unlikely to need to customize the taxonomy to fit their personal needs. In these situations, community participation is best channelled into "comments", but on the whole the interaction is more akin to a Revivalist "Call and Response" and less like a Quaker worship meeting where every participant carries equal weight. Shared taxonomies are bad for close-knit, heavily collaborative working groups.

How do we extend this model to all Resource items (Word documents, Photos, MP3s)

Integrating IM into Communications

Proposed workflow

1. Activate communications affordances in mark-up bar of detail view
2. Default is send message
3. Click + hold to select alternative
4. Choices: Send message, Start conversation

• Conversations can be added to any kind of item: Task / Calendar / Resource / Contact even
• Conversations can even be asynchronous, you can IM someone who is not online and then wait for them to respond
• [OI^?] Notification system for alerting users when conversations they have started, start up again spontaneously. In this way, you can actually keep track of separate conversations and log them as separate items. You can also have conversations ABOUT Chandler items.

Difference between sending an email

• And an email as an item that can be versioned.
• Emails are both an email and an item.
• So while resent emails are technically two separate emails, in Chandler, resent emails are two versions of the same item.

• [OI^?] How do we distinguish between the email wrapper and the core content of an item? What's in the wrapper? What's the item? OR Are they one in the same?
• Sidenote Rather than having a Send message stamp on the mark-up bar, there should be an Add people stamp with the option to send it out.

[Insert] Sketch out the UI for this.

-- MimiYin - 10 May 2004