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._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
