At 06:06 PM 2/22/2007 -0800, Mimi Yin wrote:
I'm wondering if walking through a specific scenario might help.
Think the really simple use case of:
Here's a list of places to go visit in London, add one to the list:
British Museum
Hyde Park
Parliament
Fleet Street
Picadilly Circus
This message gets sent out to 2 friends who have visited London
before. Each friend edits the email by adding 2 suggestions to the list.
In traditional email, this would generate a long thread, with perhaps
each person adding 1 or 2 items. The thread might get split and then
you have to backtrack through the thread to compile all the suggestions.
The list also gets broken up by these things reply thingies: >>
In edit/update...it's just one list. If you file that list into your
Travel collection, all subsequent updates to that list also show in
the Travel collection, you don't have to keep re-filing it. And there
isn't a long string of emails to compile...it's all just 1
item...which is what you wanted in the first place, a single list of
places to visit in London.
Actually, in the actual edit/update feature we're about to have right now,
what happens is that everybody ends up having to edit the email over again
in order to merge the changes made by other people -- and then *again* if
they happen to resolve the order differently. It's no more or less
convenient than the usual way of doing it in email, but it's *different*,
which means users will blame Chandler for the inconvenience, whereas if
they have the normal inconvenience they won't even notice it.
Of course, this presupposes that users even *notice* that they can do
something different in Chandler, and don't simply *do* their familiar reply
dance. Not all email programs allow you to edit received email, and even
fewer advertise their ability to do so.
In any case, if we actually end up with transparent change merging for the
body field in the future, then the editing could actually be more
convenient than a "normal" email conversation. But we don't have that
feature now, and I don't believe we are planning to have it for Preview.
If we don't support edit/update for non-task/calendar items...I'm not
sure how users could collaborate on meeting agendas prior to stamping
the message to add it to the calendar.
The same way people do in email now.
By the way, I'm not saying we should abandon the idea of edit/ update for
non-calendar items, just that it seems like it should be
a different process from the normal sending of an email. I think
that the idea of attaching a document (or any other item) to a
message should be distinct from the idea of having a conversation
with someone *about* a document (or other item).
I think I'm having trouble figuring out how we would make the
distinction.
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
