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.


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

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!

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

Reply via email to