[Design] 0.7 Chandler scheduling phasing proposal

[Sheila Mooney]

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

http://wiki.osafoundation.org/bin/view/Journal/ 
FreeBusyInvitesSummary20060201

Sheila

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