Notes from brainstorm between Mimi and Sheila to discuss alternatives solutions for a possible free-busy workflow solution in 0.6.

Publishing Free-Busy

We see a couple of different workflows for publishing free-busy information.

• • A. Share free-busy info the same way you would share your calendar. There would be 3 options: readonly, readwrite, free-busy. The user would select a server and get returned 3 tickets which they could forward on to users. This implies that that the user is simply thinking about this workflow as another sharing alternative.
  • B. Some independent menu item/workflow for sharing free-busy info in 1 step. Selecting a menu item would make your free-busy available. We would likely assume that your free-busy info gets published to your default sharing server. The user model here assumes that I think of publishing my free-busy as something quite different than sharing/collaboration and I would like an independent workflow to do this.
• Assumption: we would not support publishing to more than 1 server.

• For option B we could consider 2 scenarios
  • The user is returned a free-busy ticket that they give to others via email etc.
  • The free-busy information is just published on the server. When a person wants to subscribe, they will have to figure out how to find it (addressed in subscribing section below).

Subscribing with Tickets

• The ticket would be passed around and subscribed to using the same workflow as we have today for sharing. When a user's receives a ticket and tries to subscribe we can consider a couple of scenarios.
• A A share is added to the sidebar just like subscribing to a read only or read write share. Viewing a collection like this would show non-editable events on the cal with no details. The free-busy view could simply be acheived by overlaying these calendars.
  • This sounds simple but have a number of issues.
  • It doesn't scale well...we might want to schedule with a large group of people ~20 and the sidebar would be really cluttered.
  • At a user perspective, there is a subtle difference between subscribing to someone's free-busy and subscribing to calendar info with all the details. In the case of free-busy, the context in which we want to use that information is so the user can schedule this person's time. It's unlikely they will be want this calendar "in their face" in the same way they might share a calendar with a few select individuals.
  • Right now we have the abillity to share any collection with events, calendars, tasks etc. We haven't thought about how this might muck up the virtuality when we subscribe and add it to the sidebar. See issues below.
  • Adding free-busy shares to the sidebar doesn't seem like a good idea. It doesn't scale well and would add too much clutter to the sidebar if you wanted to schedule with a pool of let's say 20 people.
• B When you subscribe to a free-busy ticket, Chandler would detect this and, under the hood, add this to some list. There would be a separate UI to display this list and choose (with a checkbox) the people whom you want to have in your free-busy view when you try and schedule. We would have a separate affordance off the calendar to bring up a view where we would have a list of people (those we had checked off in the master list) and have their free-busy info appear in the composite.

• The drawback of this alternative is that there would be quite a few steps to set this up intially. The user would kind of have to know what they are doing.

Under the hood publish, no ticket

• If you could just publish to some server in one step and not have to know anything about tickets, this would require us to have some mechanism to find people when I want to schedule.
• I guess we could see a directory of people who have free-busy information published on that server. This would be ok if the group were small but Cosmo will be a public server and the list of people might grow pretty large. Also, if we look at user names, can we obviously identify the people who's fb info we are looking for.
• In short, there would be no groups or no way to limit the search.

Issues/Questions

• Right now we can share anything. If I share from the All app area, do I get 3 tickets or just one. Does the free-busy ticket only appear if you share from the calendar? Does it appear only if you have events?
• What happens if we add this collection to the sidebar - can you change this and share email as well? We should probably run through the virtuality with this and see if integrating the free-busy to the sharing workflow causes any weird problems.
• What happens if I share two calendars...do I then have 2 free-busy collections? If we had sharing free-busy as a separate menu item this restricts this to a one-action scenario and we could make sure the free-busy info consists of all events in your My Calendar. Do we just rely on the fact that the user has to know to share all their events or sharing their work calendar only could be just a subset of their real free-busy.