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.).
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
