[Design] Options for Invitation workflow in 0.7

[Mimi Yin]

Alec, this would be a great alternate proposal to sketch out at a  
Design Session. I think scheduling workflows will probably be the  
next item on the agenda after the Dashboard. In the mean time, see  
more comments below:

On Jan 6, 2006, at 5:31 PM, Alec Flett wrote:

> Mimi Yin wrote:
>> 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
>>
> Personally I think this sounds fairly workable, that users could  
> get used to, but I just wonder if the workflow is something the  
> user is going to be able to discover and thus find intuitive. They  
> have to go through this translation in their head between desire
>
> First desire: Find free time for me and persons A, B, and C.
> Actions:
>     - uncheck whatever overlays are currently in use (right there  
> you've lost me - I have to throw away whatever overlay  
> configuration I'm using)

The question to ask here is: what percentage of the time for what  
percentage of the users will there be more than 2-3 calendars overlayed?

>     - among the (say) 20 collections in my sidebar, hunt down A, B  
> and C's calendar and click the checkboxes next to each one. (so I  
> have to manually search for human-owned calendars among an  
> arbitrary set of collections, only some of which are calendar, and  
> only some of which correspond to humans)

Again I think 20 collections in the sidebar in the .7 timeframe is  
unlikely. We're also imagining that people would only bother to trade  
free/busy URLs with the few people in their workgroup that they meet  
with regularly.

>     - click on (select) my own calendar to make sure my own free/ 
> busy time is overlayed (shouldn't this just happen? most of the  
> time you're scheduling meetings with yourself)

If you already have your calendar selected, it will stay selected.  
You don't need to view your own free/busy time if you already have  
your calendar turned on :o)

> Next desire: pick a meeting time
>     - double click on a white space in the calendar - the easy part!
> Next desire: Send out invitations
>     -... (obviously, unimplemented as of now)

Well sort of implemented already (at least the UI part is): Just  
stamp the event as an email, address it and hit send.

>
> I guess what I'm getting at is that the setup to get to the state  
> where you see all the free/busy times is fairly complex. Now  
> obviously long term we'd want a totally different workflow, but  
> perhaps we can tweak this:
> when you subscribe to someone's free/busy time using the ticket  
> mechanism, it doesn't show up as a separate collection. Instead, a  
> general collection, "Contacts" shows up in the sidebar, and the  
> user gets added as a contact. The detail view for a contact would  
> include the URL for the free/busy ticket.
Maybe the contacts panel could show up as a 4th pane between the  
summary pane and the detail view? That way, the workflow wouldn't  
have to be modal.

> A "Schedule a meeting" menu item/toolbar item opens a dialog box.  
> This dialog box just shows you the human-specific calendars - i.e.  
> the people who you know about. You select the people who you want  
> to have a meeting with.
> One alternative here is to be able to select multiple people in the  
> contacts list, and have the detail view have a button "Schedule a  
> meeting" which would schedule a meeting for these contacts.
We could combine the contacts panel with the free/busy calendars (ie.  
show an icon next to each contact that has made their free-busy  
available to you.

What happens if you want to invite somebody who isn't already in your  
contacts list? Entering a list of people into a To: field might be  
easier, also minimizes on hunting down individual contacts in a long  
list of people.

> When the dialog closes (or the "Schedule a meeting" button is  
> pressed), the sidebar is disabled, though the old state is there.  
> The Calendar now shows free/busy information for these people. The  
> user uses the calendar to create one meeting (i.e. by double- 
> clicking in a free space) That meeting shows up in the detail view  
> (like it does today when you double-click to create one) The detail  
> view includes two buttons, "Send Invitation" and "Cancel".
I wonder about this being modal, as it makes it hard to add more  
people/resources mid-stream in the workflow.

> When one of these buttons are pressed, then the sidebar reenables,  
> and we go back to our old collection configuration. The calendar  
> event shows up in "My Calendar" and all is good.
> Thoughts?
>
> Alec
>
>> 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
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060118/554a49e8/attachment.htm