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

[Mimi Yin]

Hi Brian, Thanks for the quick feedback...see inline

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"?

Basically the '[x] Remember me' feature. If you already have an  
account and you've already logged in. The next time you come to Cosmo  
UI, we automatically log you in.

>
>> 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?

Yes. That's a mistake on screen 03_CC_previews_in_cosmo.png, I am  
uploading a correction now.

>
>> 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.

I've renumbered the worfklow to be hopefully more understandable. As  
Priscilla mentioned, this wiki page was intended to be a rough draft,  
she is working on a more full-blown workflow sketch, but Ted felt it  
would be beneficial to share this information sooner rather than later.

>
>> 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?

Yes.

>
>> 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.

Ah, I was too vague. It's not how many CC would bother subscribing.  
It's more for each individual CC, how many times will they subscribe  
to a new share on a daily/weekly basis.

>
>> 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.

Kewl.

> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design