[Design] Replying and Forwarded stamped items.

[Mimi Yin]

I am forwarding a conversation we've been having off-list about  
replying to and forwarding stamped items to the design list.

The current design proposal on the table is to:
1. Replies are ONLY messages. If the user replies to a task request  
or an invitation, the reply does not inherit the task/event stamps of  
the original message. This makes sense since the reply itself is not  
a task or event, but is instead simply a message in reponse to the  
original task request

2. Replies to invitations should include in the event information in  
the 'quoted message text'.

3. Forwards are also ONLY messages. Originally we thought we could  
get away with preserving stamps on Forwards so that invitations and  
task requests remained invitations and task requests when forwarded.  
However, that leads to the sticky situation where the sender (forward- 
er) ends up with multiple event on their calendar or multiple tasks  
on their task list.

When/If we have more sophisticated support for clusters, we could do  
things like:
a. Keep track of forwarded task requests and invitations as 'task and  
event items' but not display them on the calendar or task list,  
similar to the way we would 'preserve, but demote' previous versions  
of an item after it has been edited/updated.

b. Embed the original event item inside the Forward message item.

In the mean time, the proposal is to treat Forwards as messages PLUS  
an .ics attachment (for the sender). Recipients receiving the forward  
in Chandler will see the item rendered as an event invitation.

This means that on the Sender's side, the item would look something  
like this:
1. Item is only stamped as a message

2. Original event item is attached to the message as an .ics file.

3. We add "1 attachment: xxxx.ics" in the body of the message, either  
at the top or the bottom. Deleting the text won't actually remove the  
attachment from the message. It's just an FYI. Alternatively, we  
could display "1 attachment: xxx.ics" in a separate read-only text  
field below the Notes field, whichever is easiest.

4. We add the event info into the 'quoted message' portion of the  
Forward so that users receiving the message in their email clients  
can see the contents of the .ics file before or without actually  
adding the event to their calendar.

See mockups below:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Forward_Alt.png
Type: image/png
Size: 146301 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/design/attachments/20061002/168bc4ca/Forward_Alt.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Forward.png
Type: image/png
Size: 145720 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/design/attachments/20061002/168bc4ca/Forward.png
-------------- next part --------------




On Oct 2, 2006, at 12:38 PM, Brian Kirsch wrote:

> Hello,
> I think we need to take a step back and really think about what we  
> are try accomplish here. It does not feel like these latest set of  
> solutions really get the heart of the problem which is a forward,  
> reply, and reply all just create new mail message items with  
> certain values set. At that point these new items can be used in  
> Chandler in many ways that a traditional email client can not.
>
> For example, I create a forward message then stamp as an event and  
> share it but never email it.
>
> Is this a likely scenario? Probably not but it could happen and we  
> have to consider these possibilities when talking about reply,  
> reply all, forward.
>
> For example, sticking an .ics attachment in a forward to me assumes  
> that the user is going to create the message then immediately send  
> it. But this may not be the case and even worse we have no way of  
> showing in the current UI that an .ics is attached so the user may  
> get confused and then stamp that message as an event. This would  
> result in two potential contradictory .ics attachments getting sent.
>
>
> Here is how the current mail logic works. On send if the item is  
> also an event then an .ics is generate and attached to the message.  
> We want to keep that logic for Alpha 4 otherwise we are changing  
> fundamentally how mail works in Chandler and now is not the right  
> time.
>
> I really don't think it makes sense to come up with all this custom  
> behavior that will potentially generate race conditions and bugs.  
> Especially, in the final bug phases of Alpha 4. We want a stable  
> release.
>
> I think the reply, reply all cases are fine. If the mail message is  
> stamped as an event we add the event info as text in the reply. If  
> the user then stamps that reply message as an event an  
> additional .ics attachment and Where: When: text are added to the  
> body. It is the forward case which concerns me.
>
>
> My suggestions for forward are:
>
> 1. Copy the event info from the original message and stamp the  
> forward message as an event. This will generate an .ics attachment  
> on send.
>
> 2. Add the event stamp from the original message as a reference to  
> the forwarded message. The difference here is any changes to the  
> event info via the detail view will also result in changes to the  
> event info of the original message since they share the same  
> reference (Not even sure this is possible with the new stamping  
> changes but I think its is doable. Grant?).
>
> 3. Repeat the logic performed for reply and reply all which is to  
> stick the event info as text in the reply section of the mail  
> message body. This makes a lot of sense since we now forward  
> messages as in-line text instead of attachments. The current  
> checked in mail code adds the original message body as an  
> attachment to the forwarded message. However, after discussions  
> with Mimi the new mail code I have locally adds the body of the  
> original message to the forwarded message with '>' just like the  
> reply and reply all cases.
>
>
> Thoughts?
> -Brian
>
>
>
>
> Mimi Yin wrote:
>> Yes, Sheila is working to extract from the Stamping Spec the  
>> things that are specifically relevant to Email and expand on them.
>>
>> So I'm suggesting that we lose the stamp on the forward, but still  
>> forward an .ics file as an attachment. Grant? Is that possible in  
>> Chandler? to have an item with an .ics file attached, but not  
>> rendered as an event. Just asked Grant, Grant says yes.
>>
>> If the user CC's themselves on the Forward, then upon receiving  
>> that Forward in their Chandler again, we would need to reconcile  
>> that the Forward is really the same event as the original event  
>> that was Forwarded.
>>
>> As for replies, I'm not sure it's problematic if someone stamps a  
>> reply as an event again...there will just be some duplication in  
>> the Notes field, but the original event info will be clearly  
>> marked with angle brackets...
>> =====
>> *Stamps: [Mail] [Event]*
>>
>> *From:* Tom
>> *To:* Laurel (me)
>>
>> *RE: Lunch tomorrow*
>> *Tom's Diner*
>>
>> [ ] *All-day*
>> *Starts:* 09/30/2006 at 12:30PM
>> *Ends:* 09/30/2006 at 1:30PM
>>
>> *Event status:* Confirmed
>> *Occurs:* Once
>> *Alarm:* Before event
>> 15 minutes before
>>
>> *Notes:*
>> You still okay with the time?
>>
>> On Sept 26, 2006, Laurel wrote...
>> > Title: Lunch tomorrow
>> > Location: Tom's Diner
>> > Sept 30, 2006 from 12:30-1:30PM
>> > etc...
>>
>> ===
>>
>> On Sep 29, 2006, at 11:08 AM, Brian Kirsch wrote:
>>
>>> H Mimi,
>>> There is an additional issue with the reply logic we discussed  
>>> yesterday.
>>>
>>> To sum up for Grant and Sheila, reply and reply all will not copy  
>>> the stampness of the original message but will if the original  
>>> message was also stamped as an event include that event info as  
>>> text in the reply body.
>>>
>>> For a forward we no longer will attach the original rfc822  
>>> message text but instead will do a "forward as in line text"  
>>> which takes the body of the previous message and add the ">" in  
>>> reply to token at the start of each line. In addition, the  
>>> headers of the original message (to, from, reply-to, subject)  
>>> will be included in the forwarded body.
>>>
>>> The stamping on a forward is preserved and thus if the message is  
>>> also an event an .ics attachment will be sent with the forward.
>>>
>>> The issue with reply, reply all is with including event info as  
>>> text. This will not work as the new message item can also later  
>>> be stamped as an event itself.
>>>
>>> In this case, you get the same sending of two events logic that  
>>> plagued the original forward design. The first event is carried  
>>> over from the original mail / event stamped item as text in the  
>>> body and second event comes from the stampness of the item which  
>>> produces both an .ics attachment and an update to the body text  
>>> of the message to include an additional:
>>>
>>> Where:
>>> When:
>>>
>>> So my suggestion is to not copy any event or stamping info on  
>>> reply and reply all.
>>>
>>> I would also caution that we really spec out in intricate detail  
>>> all the different entry and exit points for mail that we  
>>> discussed on Tuesday such as update. I have a feeling we are  
>>> going to run in to more of these challenges rectifying tradition  
>>> email work flows with Chandler work flows.
>>>
>>> Thanks,
>>> Brian
>>>
>>>
>>> Mimi Yin wrote:
>>>> I humbly ask for your forgiveness. I realized that in various  
>>>> rounds of email discussion and revisiting issues I have led us  
>>>> astray.
>>>>
>>>> According to the email spec that Sheila wrote up a month ago?  
>>>> Forward should work like Reply in that it is JUST A MESSAGE.
>>>>
>>>> However, if there is an Event stamp on the item being forwarded,  
>>>> we should attach the event as an .ics file in the Forward.
>>>>
>>>> This is because...if we make the Forward itself an Event as  
>>>> well, 2 events will appear on the calendar at exactly the same  
>>>> time. Doh!
>>>>
>>>> In the future though, when we have clusters, we should be able  
>>>> to treat Forwards as stamped items that like previous versions  
>>>> of an item, don't show up on the calendar, but display in the  
>>>> detail view as events.
>>>>
>>>> I think in discussing clusters and whatnot, I got confused and  
>>>> conflated designs.
>>>>
>>>> I will mock up screens to clarify all of this as well.
>>>>
>>>> Mimi
>>>>
>>>
>>> -- 
>>> Brian Kirsch Internationalization Architect / Mail Service Engineer
>>> Open Source Applications Foundation
>>> 543 Howard Street 5th Floor
>>> San Francisco, CA 94105
>>> http://www.osafoundation.org
>>>
>>
>
> -- 
> Brian Kirsch Internationalization Architect / Mail Service Engineer
> Open Source Applications Foundation
> 543 Howard Street 5th Floor
> San Francisco, CA 94105
> http://www.osafoundation.org
>