[Chandler-dev] [Proposal] Web UI Work Q
mimi at osafoundation.org
Thu Feb 14 11:00:22 PST 2008
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?
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.
>> 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-
> 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
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...
More information about the chandler-dev