On Feb 13, 2008, at 4:08 PM, Mimi Yin wrote:
Hi Travis,
Thanks for taking the time to review the proposal. See more in-line...
On Feb 13, 2008, at 3:07 PM, Travis Vachon wrote:
Hi Mimi
I. REDUCING # OF CONCEPTS DESKTOP USERS NEEDS TO UNDERSTAND TO
START SHARING
+ Remove OOTB Hub collection
- This is confusing Desktop users who have a different set of OOTB
collections and end up seeing the Hub OOTB collection when they
set up their Hub account on the Desktop. Grace thought that the
OOTB Hub collection contained all the stuff she was putting into
her Chandler Desktop Dashboard collection (which she never
published) and couldn't understand why she wasn't seeing items in
the Dashboard collection in her OOTB Hub collection and vice versa.
I'd be pretty concerned about how confusing this would be for stand
alone users. That said, this would probably be Randy work and I
don't plan on blocking it, so I'm just -0.
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.
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
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 -1 on doing any work on this before the dojo 1.0 work has
landed unless there is overwhelming opposition to that sentiment.
Is it even possible to do this work without finishing dojo 1.0 work?
I imagine it would be like working against yourself to do that.
Anything is possible :-D
You imagine correctly, though, that adding this to the pre-dojo1.0 ui
would hinder our efforts to get this thing ported considerably.
-Travis
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
