[Design] [Cosmo] Re: 0.6 casual collaborator functional requirements

[Priscilla Chung]

Brian and Mimi,

I am in the middle of designing the workflow which will answer these  
questions, and of formatting the workflow in a way I believe Brian  
will understand.  This takes a little time.  I expect to have a clear  
set of workflows and a clear explanation in two days time.  If we can  
pause this discussion, I think you will find it worthwhile.

-Priscilla



On Oct 31, 2006, at 4:28 PM, Brian Moseley wrote:

> On 10/31/06, Mimi Yin <mimi at osafoundation.org> 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