Communications design: Email as a 2nd class citizen

Status Preparing for demo at staff meeting on Thur 2 Aug, 2004.

Use cases

• Not dealing with voice or verbal communications here

• Email
• I would IM with you but you're not online
• Quick thought
• Quick question
• Check this out link

• Messages
• 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

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

• Items transported via Email
• PIM items: Invitations, Task assigments, Notes, Contacts
• Documents
• Pictures

• 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
• IM?
• Email?
• Logs?
• Filters / Rules / Attributes (Schema)?

• 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

Structure

We began with four main types of communications. These four categories are a combination content types and transport technologies.

• Email
• Sharing items
• IM
• Notifications

Our exploration of use cases yielded a similar, but slightly different way to categorize communications use cases:

• Synchronous conversations (ie chats)
• Asynchronous conversations (ie messages)
• Information items (ie PIM items: Calendar events, Tasks, Notes, Contacts, Documents, Pictures)
• Status reports (ie Notifications)

• Comm_Use_Cases.gif:
• In the diagram below, traditional distinctions between modes of communication: Email, Sharing, IM and Notifications are redefined by types of communication: Chats, Messages, Information items and Status reports.
• As a result, Email and Sharing show considerable overlap wrt Messages and Information items

As you can see, there isn't a lot of overlap between Notifications and the other three types of communications. The substance of notifications is fundamentally different from the content of Email, Sharing and IM. Unlike most communications, Notifications are impersonal, oftentimes machine-generated status messages of little interest to the user. Notifications may alert users to the arrival of new personal information. But still, the messenger is not the same as the message.

There is some overlap between IM and Email / Sharing. Sometimes, information items and short emails are conveyed via IM out of convenience and a desire for immediate delivery and reply. In such cases, users think of IM purely as a mode of transport, rather than as a type of communication unto itself. However, IM as type of interactive communication is substantively distinct from Email and Sharing. IM conversations are instaneous, interactive, informal and often social in nature. People rarely bother to save conversations. Conversations sessions aren't limited to a single topic area and when they begin and end has more to do with users' individual tolerance level for open and idle windows than anything else. Some users keep the same conversation session open all day. Others close them as soon as there's a pause of more than 10 seconds.

The most intensive area of overlap exists between Email and Sharing.

Ostensibly, Email and Sharing describe two discrete paradigms, served by distinct transportation technologies. Emails are messages. Generally short-lived, informal, never edited, easily created and rapidly dispensed with. Shared items are persistent, contain valuable information that evolves over time and is subject to frequent revisions. Emails are cheap and low-maintenance. Shares are expensive and require tender loving care.

However, Email is both a type of communication and a mode of communication. As a type of communication, messages, it is fairly distinct from Sharing. As a mode of communication, it becomes indistinguishable from Sharing as people who either don't have access to Sharing or are simply fed up with Sharing applications resort to Email to transport information items they would otherwise Share.

Users are often torn between Email and Sharing applications. Using both inevitable results in information diaspora as conversations about Shared information items live in individual Email Inboxes, separate from the Shared information item.

Relatively ephemeral Email messages and even entire conversation threads can often turn into persistent information items that should really be Shared and evolved collaboratively. It's hard to know beforehand which messages will turn into full-blown documents. Users are often paralyzed, unable to decide whether to start a new wiki page or just send a quick email. The truth be known, most items exhibit some combination of both informational and conversational qualities. It's another classic example of asking the user to organize their content (email v. wiki) before they even know what the content of their content is going to be. Some of us err on the side of creating too many wiki pages that go nowhere, diluting the overall efficacy of the knowledgebase. Others avoid wikis at all costs, making their thoughts and ideas inaccessible to collaborators. Very few of us get it just right. All of us wish that we weren't asked to make such a dumb decision at such a dumb point in the workflow.

While users are stretching the use case boundaries of Email, Email software is rapidly falling behind, resulting in

• Awkward workflows
• Labor intensive user-experiences
• and worst of all, Information diaspora

• Email paradigm
• Every item is treated as a message
• Every message is a member of a conversation
• There is no distinction between information items and conversations about information items
• No editing, updating, versioning of items

• Workflow scenario in Email
• Martha is a Forest Ranger. She is drafting an "Interesting Factoids about Marmots" guide. She has enlisted the help of her friend Jane who will act as an editor while Martha remains the primary author.
• v Martha sends out a first pass with a little note at the top: Blegh, this is crappy but it gets the main idea across. Having trouble with structure. Martha files the email into her Marmots folder.
• m Jane replies: Can't look at it now. Will look at it tonight.
• v Later on that night, Jane replies to the same email again. She reads over the draft and makes edits as she reads. 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.
• v Meanwhile, Martha hit "Send again" on the original draft she sent Jane and has been making her own edits. Martha files this new version into her Marmots folder.
• m Martha receives Jane's draft, looks it over and sends back a quick reply: Wow thanks Jane, I was heading in the same direction. Martha files Jane's edited version into her Marmots folder.
• v Martha goes back to her draft, incorporates Jane's edits and sends the guide to the other Forest Rangers. Martha files the final version into her Marmots folder.
• v Every few weeks, a new findings impels the Rangers to add new factoids. Martha files every new version of the guide into her Marmots folder.
• As old Forest Rangers leave and new Forest Rangers arrive, Martha stops sending new versions of the guide to some Rangers, adds new Rangers to her distribution list or sends one-off emails of the guide to Rangers she forgot. Sometimes other Rangers make edits and send out emails to people Martha doesn't know. When it's her turn to make an edit, she's always unsure whether she should continue sending emails to these new people or if she should just leave them alone.
• Summary All in all, there were 4+ versions of the same Marmot guide and 2 messages about the Marmot guide. Some of the versions of the guide also exhibited conversational qualities. Status quo email clients however, treat all 6 emails equally as messages. As a result,
  • It's hard to tell, which emails are information items? which emails are messages?
  • Martha does a lot of filing
  • Martha's Marmots folder is full of old versions of the Marmot guide
  • Over time, different Rangers have different versions of the guide and nowhere is there a centralized list of who has what

• comm_workflows_email.gif:

• Sharing
• Editing and updates
• Versioning (optional)
• Synchronous editing (optional)
• Discussion threads or comments about Shared information items
• Versions of the same information item are different from comments or conversations about an information item.

• Workflow scenario in Sharing
• Martha is a forest ranger. She is drafting an "Interesting Factoids about Marmots" guide. She has enlisted the help of her friend Jane who will act as an editor while Martha remains the primary author.
• v Martha posts her first pass on the Forest Friends wiki site. She sends an email to Jane with a link to the wiki page: Blegh, this is crappy but it get's the main idea across. Having trouble with structure. Marth also files the email into her Marmots folder so she can find the link again.
• m Jane replies: Can't look at it now. Will look at it tonight.
• v Later on that night, Jane edits the draft on the wiki page and replies to Martha's original email again: I've reworked the page a bit. Here's the url again. 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.
• v Meanwhile, Martha was editing v.1 of the guide offline. She prepares a new email to Jane to tell her about her edits.
• When Martha comes back online, she receives a notification that Jane edited the same wiki page. Before uploading her own edits, Martha goes to look at Jane's edits.
• Martha receives Jane's second email and files it into her Marmots folder.
• m Martha sends Jane an email: Wow thanks Jane, I was heading in the same direction.
• v Martha goes back to her draft, incorporates Jane's edits and sends out an email to all of the forest rangers with a link. Martha files this email into her Marmots folder.
• v Every few weeks, a new findings impels the Rangers to add new factoids. If it's important enough, they will send out an email announcing the edit. Martha files these emails into her Marmots folder. * As old Forest Rangers leave and new Forest Rangers arrive, Martha stops sending announcement emails of the guide to some Rangers, adds new Rangers to her distribution list or sends one-off emails to Rangers she forgot. Sometimes other Rangers make edits and send out announcement emails to people Martha doesn't know. When it's her turn to make an edit, she's always unsure whether she should continue sending announcement emails to these new people or if she should just leave them alone.
• Summary All in all, there were 4+ versions of the same Marmot guide and 4+ emails announcing each new version of the Marmot guide and 2 email messages about the guide.
  • Versions of the Marmot guide live on the wiki
  • Announcements of each version and conversations about the guide live in the Email clients of all of the Forest Rangers
  • To find the Marmot guide, Martha digs through her email for urls.
  • If Martha is offline, she's out of luck, she has to be connected to see the guide on the wiki.
  • Nowhere is there a centralized list of everyone interested in the Marmot guide

• comm_workflows_sharing.gif:
  

At this point, we asked ourselves Why make two UIs when you can have one?

Proposal
In Chandler, we would like to deprecate Email from Email as a Noun, a first-class Chandler item to Email simply as a Verb, a specific way to get an item from person A to person B. As a result, Chandler doesn't have emails per se, but has items that have been emailed.

An item can simply be a Message: a note that has been emailed, which is closest to the traditional notion of an Email. Or it can be an item that has also been stamped as Task and / or put on the Calendar. In this way, users do not have to traverse a boundary between Email and Sharing in order to Communicate items of different kinds. Notes or Messages, Tasks and Calendar events are communicated in the exact same way.

Transported items can be edited by Chandler recipients.

Editing a transported item creates a new version of the item. Subsequent edits to the item overwrite each other. User can "Send update" of their edits. Chandler only saves "transported" versions of an item and saves these snapshots in the Inbox and Outbox.

Updates are different from replies and forwards. Replies and forwards are wholly separate items.

The original version of the item, subsequent updates, replies and forwards are collected into one conversation thread cluster.

Workflow proposal

• Create an item
• Add item to Collections: Zebra, Snake, Gorilla
• Send it to 5 recipients
• All 5 recipients add item to various collections
• 1 recipient replies
• 1 recipient edits the item (creates new version of item)
• Sends update
• New version of item replaces previous version of item in all the collections it's a member of (across all of the recipients' repositories)
• Both versions of the item are preserved in Inbox or Outbox depending on whether you were the Sender or Recipient
• Both versions live in a cluster together with replies and forwards (ordered by time)

• Workflow scenario in Chandler
• Martha is a forest ranger. She is drafting a "Interesting Factoids about Marmots" guide. She has enlisted the help of her friend Jane who will act as an editor while Martha remains the primary author.
• v Martha sends out a first pass with a little note at the top: Blegh, this is crappy but it get's the main idea across. Having trouble with structure. Marth adds the guide to her Marmots, Factoids, Nature Guides collections.
• m Jane replies: Can't look at it now. Will look at it tonight.
• v / m Later on that night, Jane reads over Martha's draft 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.
• v Meanwhile, Martha has been editing her original draft as well.
• m Martha receives Jane's draft, looks it over and sends back a quick reply: Wow thanks Jane, I was heading in the same direction. Martha files Jane's edited version into her Marmots folder.
• v Martha goes back to her draft, incorporates Jane's changes and sends the guide to the rest of the Forest Rangers.
• v Every few weeks, a new incident impels one of the rangers to add a new clause and update the Guide.
• As old Forest Rangers leave and new Forest Rangers arrive, Rangers add and delete Forest Rangers from the To: field of the same Marmot guide information item

• Fallout
• Users do not have to choose a priori if an item will be a message or an information item.
• All items have the potential to be either depending on how the user treats them.
• All items have the potential to be a little bit of both.
• Users only have to file an information item once
• Collections only display the most recent version of an information item
• Information items and their conversations live in the same place
• There is a centralized list of current recipients of the information item

• comm_workflows_chandler.gif:
  

• Note: This looks very similar to Email workflow we know and love. However...
• Email forces the user to create a new message for every edit
  1. Receive item
  2. Create new item based on old item (via Reply, Forward or Resend)
  3. Edit
  4. Send
• Chandler allows users to edit the same item
  1. Receive item
  2. Edit item
  3. Send update (Option to just Send update to newly added recipients)
• This subtle, but crucial difference allows Chandler to
  • Distinguish between versions of the same information item and messages about an information item
  • Only display the most recent version of an item in collections
  • Maintain one editable, centralized list of recipients

• Email: Receive_New_Edit_Send.gif:
  

• Chandler: Receive_Edit_Update.gif:
  

Modeling people

There are two sometimes conflicting ways to model people attributes on a content item.

1. x-axis: sent by Me v. sent to Me
2. y-axis: for Me v. for Others

The first is clear cut. The second is fuzzier and while users understand it, they probably couldn't articulate it. As a result, it might be dangerous for us to try and elevate the for Me v. for Others distinction to a first-class concept.

• for Me
• sent by Me to Me (when you want a personal reminder and / or when you want to make an item accessible on a server)
• sent by Me to Me, cc or bcc Others (mostly for Me, fyi for others)

• for Others
• sent by Me to Others, cc or bcc Me (when you want to make an item accessible on a server)
• sent by Me to Me, bcc Others (when you don't want to give out everyone's email in a mass mailing)

• Use case
  • Carol sends Rita a task to write up an itinerary for their business trip next week
  • Rita edits the task and sends an update back to Carol
  • Rita technically sent out the last version of the Task, but the Task is still assigned to Rita

• for_by_me_others.gif:
  

• Full-blown proposal
• Users can stamp items as Messages
• Users can click and hold Message stamp to mark it as a verbal message or Email message
• Unsent

• 4 communications collections
  • Inbox: sent to Me
  • Out box: sent by Me
  • for Me
  • for Others

• for Me v for Others distinction is visualized with a slight indentation in the Who column for items that are for Others
• sent by Me v. sent to Me distinction is recorded in the Communications history column
  • draft from Me
  • queued by Me
  • sent by Me
  • update queued by Me
  • update sent by Me
  • sent to me
  • update sent to Me
  • replied to
  • forwarded to
• clicking on communications history icon opens up communications thread for selected item

Integrating IM

Users no longer have to decide whether to use the Email application or the IM application. Instead, in one app, users can decide to either respond immediately or respond later.

• Workflow proposal

• Clifford sends Buzz a message: What are you doing?
• Buzz sees Clifford's message come into his Dashboard view
• Buzz selects Clifford's message and clicks on Chat and converses with Clifford synchronously OR
• Clifford's message becomes a synchronous conversation OR

• Clifford adds a comment to an item he shares with Buzz
• Buzz sees Clifford's comment go by on his Activity panel
• Buzz clicks: Fetch this item
• The shared item appears in the Dashboard view as if Clifford had sent Buzz a capital N notification
• Buzz uses the Comments UI to have a synchronous conversation with Clifford (like SubEthaEdit) OR

• Clifford's boss sends Clifford a message: Did you get that proposal done?
• Clifford doesn't want to talk to his boss right now
• He marks the message as Needs reply and replies to it with an asynchronous message later

Chandler and the rest of the world

Thus far we've been assuming Chandler to Chandler interactions. What happens when Chandler users attempt to communicate with non-Chandler users? or Chandler users who also use other clients?

• Chandler items lose their item-ness as soon as they leave the Chandler world
• Non-Chandler clients will read Chandler items simply as nicely formatted text
• Communications received by Chandler clients from non-Chandler clients will always start out as Messages that have been emailed or Conversations that have been IMed.
• Chandler users can stamp these communications as Tasks, Events, and Resources. However, Chandler-specific semantics will not be propagated back to non-Chandler clients.

.5 Proposal

Status Waiting to meet with engineering to get feedback about which proposal makes more sense.

• In the spirit of not keeping track of task delegation and not trying to solve project management use cases in Canoga, for .5 we will ignore for Me v. for Others distinctions and focus in on sent by Me v. sent to Me distinctions
• Fallout
  • More traditional email interaction experience (better for v.1 product anyway)
  • Maintain benefits of item versioning
  • Add extra click to editing and updating workflow

1. Create an item
2. Send item as a message
3. Recipients can stamp, mark-up and label the item (does not create a new version)
   • Users can add date / time information when they put an item on the calendar (stamp it as a calendar event)
4. Recipients click Update in the toolbar to edit the title and body of the item (creates a new version)
5. Recipients click Send update in the detail view
6. Updates replace previous versions of an item in all collections except for In and Out
   • If user has Archived, Junked or Trashed the item, the latest version of the item will appear in the Dashboard collection pre-labeled with any labels that have been applied to the Archived, Junked, Trashed previous version of the item

• 01_Create_task.gif:
  

• 02_Send_as_message.gif:
  

• 03_Receive_task.gif:
  

• 04_Put_on_calendar.gif:
  

• 05_Update_task.gif:
  

• Replace_in_Dashboard.gif:
  

• Replace_in_user-defined-col.gif:
  

• Not_replace_in_Mailbox.gif:
  

Open issues

• Conflict resolution
• Auto updates via Email?

• 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?

• How do we treat items you sent to yourself?
• As one item that shows up in both Inbox and Outbox
• Indented with a special icon to show that the item completed a full transport circle

• How does IM factor in?
• If users are online, they can IM in the item conversation. Chandler can automatically switch from Email to IM as transport.

• How do we integrate verbal communications?
• We can treat PIM records of verbal communications the same as any other messages
• For example, if Mitch asks Esther to schedule a meeting verbally, it is just as valid a communications item as a Task communicated via Email
• If users choose to record the From: and To: fields on an item, that item should count as a communications item regardless of transport mechanism

• Shall I Chandler this to you?
• Markie suggested that rather than using a technology specific term like Email or IM as a verb, we use something specific to Chandler (in the way that "to google" has come replace "to search") to underscore the generic nature of Chandler communications

• Auto-updates on item Sharing
• Remove manual aspect of sending updates
• Global setting for how often to sync
• Can always turn auto-updates OFF
• Force to send update Now OR
• Do auto-updates via IM, only if recipients are online with Chandler
• Click Send update to send a "N"otification of change
• Option to Send "N"otification of update to only newly added recipients

-- MimiYin - 28 Jul 2004