[Re-Proposal] Re: [Proposal] Goals for Item-Sharing vis-a-vis: Re: [Last call] Re: [Chandler-dev] Shipping ticketed-URLs around for individual items via email

[Mimi Yin]

On Mar 12, 2008, at 10:47 AM, Grant Baillie wrote:

> Hi, Mimi
>
> One random thought: If we are going to require emailed items to be  
> on the server, then we don't need to send out the eimml at all. In  
> other words, we could send an attachment that tells chandler how to  
> get to the item on the server, but we don't need to send a local  
> copy of the item, and therefore we wouldn't run into the whole  
> email vs shared item conflict issue.

That sounds reasonable. It won't work when you're offline, but I  
think we can live with that.

>
> The downside of requiring the item to be shared means that there  
> are now two servers we need to converse with before sending email,  
> so twice the chance of an error. Also, I think the UI needs to  
> reflect that the item is being "shared", not  "emailed" (i.e. so  
> there is no confusion with what is expected of a "regular email  
> client").

Yea. Not sure how to address this issue yet. So we might need to live  
with new design a bit, get feedback and then tweak accordingly. The  
fact that you start out with notes and events and then add addressing  
fields to them is already kind of strange as far as "normal email  
workflows" go. I imagine that if/when we expose the ability to choose  
between read-only and read-write item sharing, the difference between  
Chandler "email" and normal email will be even more apparent.

Also not sure how much the user needs to understand explicitly. (I  
still don't really get how Exchange invitations work. That's a hybrid  
email / sharing thing too.)

Other than that, do you feel we have a solid proposal for what the  
Desktop needs to do? Are there any remaining open issues for the  
Server / web UI?

Mimi

>
> --Grant
>
> On 12 Mar, 2008, at 10:14, Mimi Yin wrote:
>
>> Here is what I understand:
>>
>> 1. If we want users to be able to click on something in an email  
>> and subscribe to an item with Chandler Desktop (without going  
>> through the Hub), the best way to do that is to keep the EIMML  
>> attachment around so that Desktop users can click on it (like .ics  
>> attachments).
>>
>> 2. It also seems like we *do* want to keep around the ability to  
>> download email directly into Chandler to facilitate item-sharing  
>> scenarios so that Desktop users can receive invitations to  
>> subscribe to items directly in Chandler Desktop.
>>
>> Both #1 and 2 are nice to haves however, they complete the item- 
>> sharing workflow, but they're not things we have to have in the  
>> short-term.
>>
>> On the other hand, we already do #s 1 and 2, so there's an  
>> argument to be made that keeping them around isn't a big deal so  
>> long as any bugs they cause are also not a big deal.
>>
>> My current feeling is that "spurious conflicts" caused by Edit/ 
>> Update are not that common and something we can live with. Does  
>> anyone else been experiencing a lot of 'email-related' bogus  
>> conflicts?
>>
>> That being said, we *still* need to solve this problem where today  
>> users can send out an item via email and then put it on the server  
>> after-the-fact.
>> - The original item is sent out without a read-write ticket.
>> - The recipient could then put the item on the server and prevent  
>> the sender of the item from gaining access to that item on the  
>> server, or vice versa.
>>
>> I think this pretty much means that we need to *always* publish  
>> items to the server when they're emailed. Meaning, item-sharing is  
>> done via the server, not email, but email is used as a way to  
>> address items to specific recipients and transport the item to  
>> recipients' email clients.
>>
>> Proposed Workflow:
>>
>> 1. Create new message.
>>
>> 2. Hit Send
>> - Item is automatically published to the server + read-write  
>> ticketed URL
>> - If user doesn't have sharing account, they are prompted to get  
>> one ;)
>>
>> NICE-TO-HAVE
>> - Ability to specify read-write versus read-only in the DV or a  
>> pop-up or something...
>>
>> 3. Recipients receive email + ticketed sharing URL + EIMML  
>> attachment in their email client.
>> - Casual Collaborators click on ticketed sharing URL to access  
>> item on Hub;
>>
>> NICE-TO-HAVES
>> - CC can add item to their account
>> - Desktop users can click on attachment to automatically subscribe  
>> to item with Desktop, if they are not online when they click on  
>> the attachment, they should still be able to see the item added to  
>> the Desktop client
>>
>> I know we've gone back and forth on whether to keep the EIMML  
>> attachment + inbound email functionality, but I think I'm finally  
>> getting a better picture of what's required to make the item- 
>> sharing scenarios work smoothly. So in other words, I think we're  
>> close!
>>
>> Still, I'm interested to hear if I'm still making assumptions that  
>> aren't necessarily necessary ;) and/or if anyone else has  
>> alternative workflow ideas that would simplify the way we do item- 
>> sharing without compromising the user experience too much.
>>
>> Mimi
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev