[Design] Re: [Please review] Updates to Stamping, aka Edit/Update Spec

[Phillip J. Eby]

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.).