Based on the more detailed scheduling summary that was posted to the list last week, Mimi and I have put together a proposal for staging these features over the 0.7 timeframe. We did this by thinking about the user scenarios that could be executed after each stage. Basically, we are taking the approach that we don't have to have all of this working to get something up and running in the app that people can experiment with. This gives the design team some flexibility to spec out the first phase so developers can start working, then continue discussions on some of the more difficult areas in phase 2 or 3. Keep in mind, this is at a product perspective and we have not done any scoping with development to understand additional dependencies and how these phases would line up with a particular milestone. + Phase #1 -> Goals - get something experimental up and running quickly - use infrastructure that exists today - free-busy -> reduce depencies on requiring backend caldav free-busy report as well as any new gui widgets (special panel in sidebar). - notifications -> simple solution for both outbound and inbound notifications that doesn't rely on much email work -> Free-busy - use the existing publish and subscribe workflows to publish and subscribe to free-busy information - upon publishing, a 3rd url will be returned for the free-busy info (fake free-busy not using CALDA reports - just calculated using the published calendar) - subscribing works the same way as today - when subscribing to a free-busy calendar, it appears in your sidebar just like all other shares - free-busy shares are read only - we would use the same sharing icons as today - the detail in the calendar would appear like any other calendar lozenge - with no event title in lozenge - blank detail view fields (except for date/time) - you can overlay calendars exactly like you do today - unpublish/resubscribe works using the same workflows -> Event Notifications(Invitations) - make stamping work for sending an event notification - stamp event as mail and send - fix a number of the existing stamping bugs - when you stamp an events as a mail, copy the date time information into the notes fields - dnd mail, ics files, text into Chandler to create an event
+ Phase #2 -> Goals - free-busy - use CALDAV and look at improvements for handling list of free-busy calendars - event notifications - make progress on some of the email work for 0.7 and focus on workflows for Chandler-Chandler users
-> Free-busy - hook up the free-busy view to the free-busy backend - using caldav free-busy report - investigate different sidebar area for managing free-busy calendars - individual design proposals TBD - iterate on different calendar displays - individual design proposals TBD -> Event Notifications(Invitations) - receive email in Chandler then you stamp as event (this might partially work for phase #1 but we may have bugs that block this) - sending and receiving an item in Chandler - event urls would also be an alternative solution - a user can receive and item and it will be automatically updated on their calendar + Phase #3 -> Goals - add iMip support for event notifications - iron out snags in free-busy workflows -> Free-busy - ? potential bugs/enhancements tbd -> Event Notifications(Invitations) - sending iMip requests - receiving iMip requests - dnd iMip invitations into Chandler - handling updates - between Chandler-to-Chandler sharees - handling updates - between Chandler-to-Chandler users (?maybe) - maintaining persistent copies of updates (versions) For those that want more background detail, see the notes we posted last week Sheila |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
