[Design] Re: Forwarding Chandler Items around

[Brian Kirsch]

Hi Mimi,
After reading through this proposal I have to wave some large flags  
that I personally don't think this is doable for Preview. I think we  
should focus on the simpler Edit / Update workflows and get those  
right before tackling any complex forwarding logic. It is just too  
late in the development cycle to add significant and challenging new  
features.

See the rest of my comments in line.

-Brian


On Feb 17, 2007, at 12:08 AM, Mimi Yin wrote:

> So as I mentioned in my last email announcing the Email spec  
> updates, spec'ing out Forwarding turned out to be more painful than  
> I had anticipated, and I was already dreading quite a bit.
>
> So here goes. In a world where we're shipping 'real Chandler items'  
> around, not just text. What does it mean to 'Forward' a Chandler item?
>
> Outlook's model:
> + Outlook doesn't allow invitees to events to directly 'edit' other  
> people's invitations to say, add other invitees.
> + Instead, invitees can add other invitees by Forwarding an invite  
> to somebody 'on behalf of' the original event organizer.
> + If the recipients of the Forward accept the invitation, they are  
> added to the invite list.
> In other words, Outlook essentially Forwards the original invite  
> and updates from recipients of that Forward, affect the original  
> invite.
>
> For some reason, I don't think we want to follow this model in  
> Chandler. For one, we *already* allow recipients of Chandler items  
> to directly edit and update 'other people's items'. So Forward  
> should do something different.
>
> PROPOSAL - I badly need a reality check on how feasible this is.  
> This is just my first random design swipe at the problem. Let's  
> follow up with more discussion to do something that's reasonable  
> for Preview.
>
> + Forwards are just message items.
doable
> + Forwards contain EIML and .ics attachments (if necessary) to  
> capture non-email metadata
doable
> + EIML attachment is a hybrid mix of the stamps from the original  
> forwarded message + Addressing and Notes fields from the Forward  
> itself (bkirsch: Is this significant, extra work?)
This is not something I am willing to commit to in the Preview  
timeframe given my other tasks.

> + Chandler recipients parse the EIML attachment and can edit/update  
> the Forward.
I would need more clarity here. If the forward is just a new Edt /  
Update workflow then it might be doable.


>
> + This means that the original Forward message could get Updated to  
> become a full-fledged event on the calendar and/or task on the task  
> list. As a result, the sender of the Forward might end up with 2  
> versions of the same event on the calendar or 2 versions of the  
> same task on the task list...being updated by 2 different sets of  
> people.

This concerns me. Why would the sender end up with two copies?

>
> I think that's okay, because there are use cases where this is  
> useful. I remember this being something we discussed at great  
> length a year ago with Alec Flett and Mikeal. Sometimes you want to  
> collaborate on the same item with 2 different sets of people, we do  
> this all the time by splitting email threads. For example, you  
> might be coordinating 1 Wedding rehearsal dinner with the caterer  
> and the bridal party and want to keep those conversations separate.
>
> Here's what's in the spec.
>
> Forwards do not inherit the task/event stamps from the original  
> message Item. Forwards are separate message Items with their own  
> UUID. However, Forwards contain the original item as an EIML and/ 
> or .ics attachment under the the same conditions described above  
> for Sending Items. The Forward message Item itself looks like the  
> following:

If a forward has the EIML of the other item then it has no identity  
of its own. Meaning what if I stamp the forward as an event and add  
data. That data would not be reflected in the EIML unless two items  
EIML info was wrapped in the message (the original and the forward).  
Again, I think this is getting too complex for Preview.
> Forwards are addressed in the following way:
> From: (Original msg) = From: (Forward)
> To:, CC: and BCC: are blank
> Fwd: is prepended to the Title of the Item
> Chandler will automatically place the cursor at the top of the  
> Notes field.
> Chandler will add: Begin forwarded <KIND-COMBINATION>: to the top  
> of the Notes field, 2 line breaks down from the top of the Notes  
> field. For a list of all the possible Kind-Combinations, please see  
> both the 'Sending Items' and 'Receiving Chandler Items in generic  
> email clients' section above.
> Chandler will "forward the item as in line text" which will look  
> like: (Fields appear, only if applicable.)
> Begin forwarded <KIND-COMBINATION>:
> From:
> To:
> CC:
> Sent by xxx on yyy
> <TITLE> at <Location> from/on <DATE/TIME> <OPTIONAL TIME ZONE>  
> until <OPTIONAL RECURRENCE END-DATE>
> <NOTES>
>  A ">" token at the start of each line.
> Chandler will attach an .ics file and an EIML file to the Forward  
> if the message being forwarded was a task, event or had irregular  
> Addressing fields (as per the rules outlined above in the 'Sending  
> Email' section).
> The EIML attachment will inherit any Task or Calendar stamps from  
> the forwarded message.
> The 'Notes' field of the EIML attachment however will be taken from  
> the body of the Forward itself.
> Users receiving the Forward in Chandler will parse the EIML  
> attachment, if there is one.
> Users receiving the Forward in other email clients will see  
> the .ics attachment if there is one.
> We realize there will be information duplicated in the message body  
> and in the attachment and that is actually by design, to provide  
> email client recipients with a way to preview the event Item before  
> adding the .ics file to their calendars.
> Chandler recipients of the Forward can edit and update the Forward  
> like any other Chandler communication. Doing so, will update the  
> Forward message item for all recipients of the Update.
>
> Mimi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070220/611c2022/attachment.html