[Chandler-dev] [Proposal] Web UI Work Q

[Mimi Yin]

Grant, there is a question for you re: generating sharing tickets for  
collections created on Chandler Hub/Server.

On Feb 13, 2008, at 4:28 PM, Travis Vachon wrote:

>> Yea I have same concerns. This was simply the cheapest solution I  
>> could think of. We could 'smarter' things like hook up the OOTB  
>> Hub collection with the Desktop Dashboard collection, but that  
>> road feels long and fraught with peril :)
>>
> It is :-) I'd say that's definitely out of the question, since the  
> dashboard collection in the desktop isn't an actual collection.
>
>> We could also zap the user-defined collection under specific  
>> circumstances: e.g. If an user doesn't do anything to the OOTB Hub  
>> collection (edit items in it or create new items) then we zap it  
>> when they set up their Hub account in Chandler Desktop.
>>
>
> This would also be technically difficult, since we'd have to come  
> up with an algorithm for deciding when we should zap. The cost of  
> bugs in that algorithm would also be particularly high.
>>
>> We could:
>> + Add an 'Invite...' link which would generate 2 tickets in the  
>> 'Collection Details / Sharing dialog.
>> + I think we would also need to automatically generate 2 tickets  
>> if the user invokes 'Invite' from the Desktop
>>
>> I was looking for the cheapest solution possible. FWIW many if not  
>> most Desktop users publish collections to the server, not to share  
>> with others, but just to back it up for their own use. So I'm not  
>> sure if this distinction between shared versus not shared is that  
>> clear. Or if it is, we should offer it for the Desktop as well.
>
> Yeah, especially given the security model changes Randy is working  
> on I think the cheapest solution is the one I proposed since it  
> doesn't require any server work and requires a minimum of client  
> work. Basically, we'd make the ticket creation process transparent  
> and on-demand when users want to share calendars read-write.

Hrm, so I think to solve the user workflow problem we'd mostly have  
to tweak the Desktop. Basically, create tickets when the user invokes  
Share>>Invite... Grant, does that seem reasonable?

I will mock up something for the web UI.

>>>
>>> This is basically along the same lines as (I), in that most of  
>>> these changes are focused on cleaning up the "get sharing  
>>> instructions/information" process.
>>>
>>> I think perhaps a better idea would be to come up with a new  
>>> dialog that is specifically focused on giving users information  
>>> about how to share and subscribe to collections. This will let us  
>>> really emphasize the "sharing" idea in the web ui and leave us  
>>> some room for making the save/delete buttons a little prettier in  
>>> the collection info dialog. To minimize development time the  
>>> dialog should be pretty much the same in "ticket collection" and  
>>> "regular collection" mode, though minor things like number of  
>>> ticketed links and "share link" ui could of course be different.  
>>> This will make development faster and minimize the amount of  
>>> futzing we need to do with the current ui.
>>>
>>> Pursuing this strategy would probably take 2-3 days of dev and  
>>> testing, while making all of the changes you suggest would  
>>> probably look more like a week at least.
>>
>> Would we remove the subscribe and download stuff from the current  
>> collection details dialog?
>
> Yeah

We could also consider allowing users to edit the collection name in- 
place in the sidebar if that's easy with new Dojo widgets + add a  
'Delete' button next to 'New Collection'. That would mean no more  
collection details :) We can work through options in more detail when  
you're actually ready to work on this.

>
>>
>> Do you have some ideas about how the sharing dialog might be  
>> invoked? I'm concerned about adding more UI elements to the  
>> sidebar, but an open to alternatives.
>>
>
> This
>
>> If creating a new dialog is much easier, could we just get rid of  
>> the old dialog and create a new dialog along the lines of the mock- 
>> up?
>
> is basically what I'm proposing, except that we keep around the old  
> dialog for the name change/deletion ui. The new dialog would pop in  
> ticket view whenever users clicked a sharing related link and in  
> the logged in view when they hit a "share" link we put either in  
> the side bar or at the top of the page. Given that we're trying to  
> emphasize sharing I think this would be a pretty reasonable  
> addition. If you're really set on having that (i) graphic be the  
> point of entry to the sharing dialog I'd be fine with that too,  
> though I don't find that particularly intuitive, and it would mean  
> we should find a different entry point for the deletion/name change  
> ui.

I'm not attached to the (i) graphic. There's a bug to change it to a  
down arrow. Again, we can work through what the options are when you  
have more time to think about this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20080214/4ff60a32/attachment.htm