On 10/31/06, Mimi Yin <[EMAIL PROTECTED]> wrote:
1. Disable automatic login if user is clicking on a URL for a share they are not already subscribed to in Cosmo.
can you explain what you mean by "automatic login"?
2. Disallow login when user clicks on a URL for a new share. Users can only log in by adding the share to their Cosmo account.
is what you're saying here that you don't want the login form to show up on the calendar page? in essence, getting rid of the "logging in from the calendar page" section of my writeup?
1 and 2 would get rid of the need for temporary subscriptions in the pulldown menu.
i can't agree or disagree with this assertion until i understand what 1 and 2 mean ;)
I have a preliminary mockup here: http://wiki.osafoundation.org/bin/view/Journal/CosmoMagicURLStoryboardsTake2
hate to sound like a broken record, but i don't understand the workflow description on this page. you have steps 1 through 10, which imply the user goes through that entire sequence, but then i see lots of "and"s and "or"s in the text, which implies there are choices and subflows. could you perhaps use separate lists for the subflows, and use "goto" statements or something like that to show where one flow leads to the next? maybe a flowchart would help.
While this proposal is flexible for the end-user, it's simpler to understand and it's arguably not that important to provide a seemless way for users to navigate between shares they're previewing (temporary subscriptions) versus shares they've already subscribed to.
hm. if you really think that's the case, then i suggest removing any ability to navigate the app from the preview screen. no calendar selector at all. was that part of the idea as well?
Another way to think about it is: How often are Cosmo users going to be subscribing to new shares in the Preview timeframe? All things being equal, probably not that often.
really? do you think casual collaboration will be that casual? i'd think that if somebody wanted to share a calendar with me, i'd be more interested in the calendar than just looking at it for a couple minutes. in fact, the example that you guys have been using for this use case is one where the hub and the cc iterate several times over an event. seems to me that the cc would definitely want to subscribe to the share in that case.
PS As for free-busy, is there a reason why it can't be treated like any other calendar subscription? We just simply don't display any event details? Instead, we only show blocks of confirmed and tentative time? That's what we're doing in Chandler today.
that's what i figured. i don't see any major problems with doing this. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
