[Design] [Sum] Editable Email versus Editable Attachments

[Mimi Yin]

Hi Phillip,

I think we're beginning to wander back down well-worn discussion  
paths and in the interest of staying on track of Preview, I'm going  
to try and summarize your concerns so that I know I understand them,  
but reiterate what we've already agreed on for Preview.

Your concern is that users won't always want to do edit/update and  
that there are valid use cases for sending just messages and having a  
good old-fashioned email conversation. You'd like to see Chandler  
provide users with a choice to either send a traditional, non- 
editable, plain email message and/or attach a Chandler Note/Task or  
Event item that can be edited and updated.

Does this fairly capture what you're saying?

What we're doing for Preview:
We are only satisfying the 2nd use case, but not the first. Every  
'message' item that gets sent from Chandler gets a 'Chandler' item  
attached to it in the form of an EIML attachment. There is no such  
thing as a 'plain', non-editable Email message. The reasoning behind  
this is that:

1. For Preview, Chandler is primarily a Notes, Tasks and Events  
management system with Email functioning as a way to transport  
Chandler items around. Chandler is *not* meant to replace all forms  
of email communications, in particular: traditional email  
conversation/communication.

2. Nonetheless, if users *do* want to just engage in a 'normal' email  
conversation, there is nothing in the current design that stops them  
from doing that.

3. From our user interviews, it is unclear that users themselves  
*know* a priori whether the missive they're about to send out is a  
*normal* conversation or candidate for Edit/Update. To repeat, many  
message threads exhibit signs of both kinds of interaction:  
collaboration on the original message item as well as an attendant  
conversation thread.

In the end, I don't think we're really disagreeing on the mechanism  
by which edit/update functions. Either way, we're using EIML  
attachments to transport Chandler items around. I think the  
disagreement lies in how workflow options are presented to users:

A. Explicitly: Choose between a non-editable conversation versus an  
editable attachment; versus
B. Implicitly: When the time comes, Edit if you want to, Reply if you  
want to, either way, the message you send out will support both, so  
you don't have to decide now. (Another way to think about it is: Why  
do users need to be able to choose to send a non-editable  
conversation message, when the edit/update option supports both  
workflows?)

Finally, how do we resolve this issue: What kind of dogfood feedback  
do we look for to resolve this issue?

Mimi

On Feb 22, 2007, at 6:21 PM, Phillip J. Eby wrote:

> The same way email programs distinguish between the content of a  
> message, and an attachment to the message.  That is, I suggest that  
> edit/update workflow should be started by "attaching an item to an  
> email", rather than making the email itself be the subject of the  
> edit/update.  Sending out subsequent updates, of course, can be  
> done without doing further attachments, which means that the user  
> then perceives this as a time-saving feature compared to the  
> equivalent workflow in other email clients (where you have to  
> explicitly attach the item each time, keep track of which version  
> is which, etc.).
>