[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]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20080312/9e73ede1/attachment.htm