[Design] Options for Invitation workflow in 0.7

[Mimi Yin]

As many of you already know, we're starting on Plausible Invitations  
in 0.7. We're still quite not sure what that means, but we have a  
good sense of what the range of options are.

Please feel free to reply and add to the list of what we think is low- 
hanging fruit below. Also, technical issues and high-level swags  
would be great input too.

Part I: Publishing and Subscribing to Free-busy
Separate Publish my free-busy information... item under the  
Collection? menu with the option to choose which server(s) you want  
to make it available on. Returns a ticket(s) you can pass out to others.

AND/OR

Provide a free-busy option on a per collection basis, in addition to  
read and read/write. (Would allow someone to publish say a Resource  
free-busy schedule, but might be less discoverable. Some people may  
only want to publish free-busy and it might not occur to them to look  
under sharing.)

Subscribing to free-busy behaves the same way as subscribing to read  
and read/write shares. You receive a ticket, you paste it into the  
Subscribe dialog and a collection appears in your sidebar. The only  
difference here is that:
+ when you go to view the events in the calendar, you can only see  
blank blocks.
+ when you go to view the events in a table, you can only see date/ 
time info + event stamp

You can overlay free-busy calendars with other free-busy calendars  
and with other normal calendars as well.

You can't write to free-busy calendars.

You can drag and drop non-event items into free-busy calendars, just  
like you can in read-only calendars today, but they won't be shared.

=====

Part II: Workflows for scheduling

Truly Basic: More Notifications via email than invitations per se.

1. Overlay free-busy calendars with your own
2. Select a time
3. Add an event to your calendar
4. Stamp the event as an email (No auto-filling of invitees.)
5. Send event (as an email) (Convert, date/time info into text in the  
email.)

Fancier Add-ons

+ Send event with special Chandler headers so that Chandler users  
receiving the item can parse it as an event. Event automatically  
plops on your calendar. To get it off, you either have to delete the  
item or un-stamp it as an event.

+ Edit and send again (Send button turns into an Update button),  
Chandler keeps track of updates through UUIDs. Updates automatically  
over-write previous versions of the item.

+ Maintain previous versions of Updates, but retire them from the  
calendar so they don't show up there.

+ Send email with an .ics file attached so that non-Chandler users  
can receive the event as well.

Other email features to consider in support of invitations:
+ Reply
+ Reply all
+ Forward

Here's an old write-up of invitations. It's a little out of date, but  
it captures some of the "ultimate direction" of invitations and more  
importantly, "item sharing" via email.

http://wiki.osafoundation.org/bin/view/Projects/CommunicationsDesignNew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060106/08ceb461/attachment.html