I think in my mind, it's not so much a binary decision: Do
conventional email, don't do conventional email. It's more like:
let's extend conventional email to support a use case that any good
Communications tool should support.
There are use cases where 'conventional email' suffices: e.g. having
a back and forth conversation. And then there are use cases where
conventional email doesn't suffice (editing and updating)...and so we
want to support those edit/update use cases without foregoing the
ease of use of email workflows. (As in, we don't want to force people
to click on some link in an email and go off to same specialized
shared document UI to edit shared notes, tasks and events, the way
people do today with shared content management systems from things
like MS Sharepoint to wikis.)
As for why would an user reply/forward versus simply editing and
updating a message. I think people make that decision several times a
day, everyday. When do you decide to edit a wiki page versus reply in
email? Can others chime in on this?
At a high-level, some factors include:
+ Etiquette.
- If I'm collaborating with someone I work with very closely (e.g.
Sheila, Priss), I will just go ahead and edit and update the document.
- If I'm collaborating with someone I am less familiar with, I will
reply with comments implying, here's my input, take it or leave it.
+ Content.
- If I'm adding to a list (e.g. Packing list for New York), I will
edit and update the item.
- If someone writes up a whole proposal and then at the end says:
what do you think? is this ready to go? I would reply with my thoughts.
- If someone writes up a proposal and leaves in a blank section that
says: Mimi, could you fill in this part? I would just edit and update
the item.
Mimi
On Nov 16, 2006, at 1:29 PM, Brian Kirsch wrote:
On Nov 16, 2006, at 11:14 AM, Mimi Yin wrote:
So, one way to think about this is that, as soon as you're editing
a message that has already been sent, that item is not really a
message. It's a note that you are collaborating on with other people.
e.g. A packing list that you're adding stuff to. A draft of a
proposal you're writing up. Etc.
It's the same as if you could embed the contents of a wiki page in
an email...which people often do when they send links around to
wiki pages because they know people would prefer to read the
documents without having to click away from their email client.
The bummer about that is that the text you put into an email can't
be edited and updated the way a wiki page can.
So imagine that when Chandler users edit and update messages, it's
similar to the way people might like to update wiki pages if they
could be embedded into email messages. Instead of clicking on the
wiki link to go edit the contents on the wiki, I can just edit the
text right in the message and hit Update to send my edits back to
everyone else.
That shouldn't change the original From: and To: of the item, in
the same way that the last person who edited a wiki page doesn't
change the original person who Created the wiki page.
Does that make sense or is it just more confusing? :)
I think what is confusing to me is sometimes email is suppose to
function like traditional email in Chandler and sometimes it is not
as in the Invitation case.
For example, why are we supporting the traditional reply, reply
all, forward cases if we are changing the way 'email' works (send
as, edit, update)?
It seems to me reply and reply all are the same as update. The
forward case is unique but could be accomplished by a "Start new
communication
based on this discussion" type of feature which clones the current
mail / invitation and adds me as the sender.
If I can simply update the existing email conversation why would I
want to reply all?
-Brian
Mimi
On Nov 16, 2006, at 11:14 AM, Brian Kirsch wrote:
My understanding of the design is this: When Chandler is
displaying an invitation, i.e. an event stamped as an email, the
main focus is on the event, i.e. who is organizing it, who is
attending, who is being notified (but isn't attending). The fact
that the invite is being transported via email is secondary; in
fact, if the item is shared, some of the people in the
addressing fields will find out about it via syncing a share
instead of email. You can also imagine a future Chandler where
the invite is transported via other mechanisms (jabber, atompub,
CalDAV scheduling, ...).
So to clarify for myself what Grant is articulating. If a message
is also an event (Invitation) then do this rerouting of the from
etc to provide a better collaboration user experience. Now what
happens if the item is just a mail message and not an Invitation?
Does this rerouting still take place or do we use the traditional
mail from, to, cc that we currently support in the detail view.
So, that is what the design was designed to support. You can
still get at the email fields via a menu item, but that's not
enabled by default. One point of contention, that we discussed
in the past, was that users might find the new use of the terms
"from", "to", "cc" confusing. This may well be possible, but
really we won't know for sure until we've gotten the app in the
hands of real users.
I would think this *would* be confusing especially if the
behavior changes for a mail message vs. an invitation. If this
is the case I would vote for a different nomenclature for the
invitation workflow's such as "Organizer" instead of "From".
-Brian
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
