[Design] In Out collection logic proposal refinements

[Brian Kirsch]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20061116/6b242ed0/attachment.htm