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

[Mimi Yin]

Hi Brian,

Thanks for writing this up. It clarifies things for me a lot.

I'm wondering if it helps or hurts to cut 2 features that would  
drastically simplify the workflow. The 'login and temporarily  
subscribe to a calendar' workflow is elegant and desirable for a  
number of reasons, but it's complexity is a bit risky from a  
usability standpoint and adds functionality that isn't top priority  
for preview.

1. Disable automatic login if user is clicking on a URL for a share  
they are not already subscribed to in Cosmo.
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.

1 and 2  would get rid of the need for temporary subscriptions in the  
pulldown menu.

I have a preliminary mockup here: http://wiki.osafoundation.org/bin/ 
view/Journal/CosmoMagicURLStoryboardsTake2

Note: Priss is working on a proposal for the chrome design, which  
would include subscribing to shares with Chandler and iCal, or as a  
feed. What I have in the mockups are just temporary placeholders.  
Priss's proposal for the chrome will address workflows for  
Unsubscribe and Rename.

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.

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.

Apologies for the change in plans. Priss had expressed reservations  
about the temporary subscription design during the session last week  
and immediately after the meeting, we discussed chucking the  
temporary subscription workflow in favor of a simpler model. We  
should have piped up sooner to let you know sooner. Hopefully, this  
only affects part of bcm's write-up and most of it is still applicable.

Mimi

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.


On Oct 30, 2006, at 5:18 PM, Brian Moseley wrote:

> i wrote up a draft of the functional requirements for the casual
> collaborator feature in 0.6 at
> <http://wiki.osafoundation.org/bin/view/Journal/ 
> BrianMoseleyCosmoZeroDotSix>.
>
> this is mainly a way to understand the storyboards and design notes by
> writing out in english how the  CC interacts with the app and by
> describing (fuzzily) the various widgets, controls and other elements
> of the ui.
>
> note that there is one outstanding question: what happens when a
> free-busy ticket is used to access a calendar? do we want to display
> free-busy time in 0.6?
>
> please read and respond with any questions or comments. i'll be using
> the func reqs to work out the major code design elements and a task
> list.
>
> thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20061031/b94a31f0/attachment.html