I can see where you're coming from. Few serious calendar users will want to create a Cosmo calendar from scratch. Chandler users will have their Chandler users already published to Cosmo. And Casual Collaborators are mostly concerned with other people's calendars or group calendars. So why have an out of the box (OOTB) 'personal' calendar'?
Let's look at the specific usage scenarios for 0.6 and Preview: 1. Signing up for an account to manage their subscriptions to other people's or group calendars and does not have a calendar of their own to import/subscribe to in Cosmo. This is what we think will be the case for the Casual Collaborator. In that case, I think we should provide the user with a Calendar out of the box, because all of the calendars they have in Cosmo will be other people's and if we are looking to persuade them to try managing their own calendar in Cosmo, a separate 'personal' calendar OOTB will help our cause. 2. A Chandler user who has published collections on Cosmo and knows that they can see the calendars they published in a browser via the Cosmo web app. This person does *not* need to have an OOTB Calendar. In fact, that would be actively confusing because we don't really have a notion of repository sync between Cosmo and Chandler and events the user adds to the Cosmo Calendar won't show up in Chandler. However, since the Chandler user is not the target user for 0.6 or Preview, we can probably live with this confusion for now. 3. Someone checking out Cosmo to play with it. (They'll need a Calendar OOTB to do that.) 4. Someone wanting to try out Cosmo as a standalone Calendar app. Currently, there isn't end-user UI for importing calendars. Creating a calendar from scratch or Publishing a calendar onto Cosmo from a 3rd party Calendar client are the only 2 options. If there was an import tool, we could/should give users an option to either import calendars as new collections, or import them into the default Cosmo Calendar. In 3 of the 4 cases above, having a Calendar out of the box makes sense. In the 1 case where it doesn't make sense, we should either auto-detect that the user is a Chandler-Publisher and get rid of the OOTB collection, or just deal with the funny-ness until we can implement a Dashboard / Library collection. The way I see it, in the Preview timeframe, 1 (CC) and 3 (Checking out Cosmo) are the ones we really need to get right. 2 (Consultative Chandler user) needs to be stable and nominally useful, but it's okay if it's a little bit confusing so long as 'users in the know' can figure out how to work around the lack of a 'repository sync' construct in the end-user mental model. 4 (Standalone calendar user) is a nice to have user, but we haven't spent nearly enough time flushing out scenarios and workflows to make it something we can realistically target for Preview. So, given the usage scenarios, does an OOTB calendar make more sense? Mimi On 1/4/07, Matthew Eernisse <[EMAIL PROTECTED]> wrote:
Brian Moseley wrote: > i've always thought that "Cosmo" collection was a little bogus. i feel > like the user, upon logging in for the first time, should see a page > that says "you have no collections. you should share one with > chandler, or add somebody else's shared collection, or import a > calendar from another application, or make a new empty collection". +1 -- great idea, definitely better than the magic, behind-the-scenes creation we have going now. Maybe add something like "If you're not sure what to do, just create an empty collection to start with -- you can do any of those other things later on." _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
