[Design] 0.7 Planning and Plausible Scheduling [Summary]

[Mimi Yin]

  I'd like to take a moment to summarize and the free-busy  
discussion. Please respond to this email if you think there is  
anything missing or any viewpoints have been misrepresented.

I think what we're hearing is that even if we treat free-busy and  
scheduling as "experimental" UI for 0.7, as part of that experiment  
we should consider low-hanging fruit in the realm of simple  
invitations and notifications. This would result in a more "workflow- 
centric" approach to implementing and delivering functionality.

Perhaps we could call it "Plausible Scheduling".

Below are excerpts from individual perspectives posted to the  
discussion thread.

We started with the idea that even minimal free-busy functionality  
without any support for invitations would be an attractive feature to  
add to Chandler's basic calendaring support. We heard some dissenting  
opinions...

=====
CLOSED LOOP SUPPORT FOR SCHEDULING that automatically populates  
people's calendars with invitations IS CENTRAL TO CALENDAR ADOPTION:

Integrated free-busy and invitations itself builds an important RAMP  
to calendar usage. People who would otherwise not use digital  
calendars, find themselves with automatically filled up calendars as  
a result of application support for streamlined scheduling workflows.  
In calendaring systems where closed-loop invitations are supported  
end-to-end, the burden of maintaining an accurate calendar is  
essentially shifted from the invitee to the invit-er. Additionally,  
the "work" involved in keeping calendars up-to-date is reduced by a  
factor "n" where "n" is the number of people invited to the meeting.  
Instead of everybody receiving an email and then entering the meeting  
onto their calendars by hand, the invit-er enters the event onto  
their calendar once and plops it automatically onto all invitee  
calendars auto-magically via invitations.

"I'd like to share why I feel supporting "free-busy" and "invite" is  
so important. I've been working in places where Outlook/Exchange was  
heavily used. I was not a heavy calendar user before but, once in  
these organizations, I maintained a full calendar. Most of it was  
actually filled up automatically: I'd accept/reject invites and  
things would get magically updated."


=====
BASIC INVITATIONS WOULD BE MORE USEFUL AND EASIER TO IMPLEMENT:

"I'm thinking that very basic, useful invitations would be a lot  
easier (in terms of hours of labor) than a useful free-busy  
implementation - we've done most of the work in 0.5 and 0.6 for  
simple invitations anyway.

To make free-busy really useful requires a lot more work:
I just think there's a lot more to it beyond just the display of the  
free time, to make it very useful - there's coordination with a bunch  
of contacts - do we pop up a dialog that allows users to add people  
from an address book? do we even have an address book? How do we  
determine which users are on which WebDAV server? Do we record THAT  
in an address book, if we have one? Then once an appropriate free  
window has been decided, how do we schedule the meeting?"

=====
INVITATIONS ARE MORE USEFUL THAN FREE-BUSY FOR EXTRA-GROUP SCHEDULING:

"Personally, and this is VERY personal - I find simple invitations  
more useful because I tend to schedule my personal events with people  
that aren't on my calendar server (especially since I don't have  
one :)) - It would be far more useful to me, who schedules much more  
outside of my workgroup, to just send out invitations.. be it in the  
form of VCF (which outlook understands) or ICS, I don't care... then  
if I can launch chandler from thunderbird with a VCF/ICS attachment,  
and chandler would ask "Which calendar would you like to put these  
events in?"

I know there are all sorts of standards around this (iMIP? I dunno)  
but the fact that outlook already does things like VCF attachments,  
made me aware of how simple basic interoperability could be."

=====
INVITATIONS ARE UNDOUBTEDLY AN IMPORTANT PART OF THE SCHEDULING  
WORKFLOW, BUT THAT DOESN'T MEAN FREE-BUSY ON IT'S OWN ISN'T VERY USEFUL.

Of course, these opinions aren't really mutually exclusive. Whether  
free-busy or invitations is more or less useful is highly personal.  
The "fundamental truth" that's emerging is that both are critical  
parts of a single workflow: scheduling.

=====
COMPROMISE: LET'S THINK OF FREE-BUSY AS AN EXPERIMENTAL FEATURE,  
perhaps supported by rudimentary notifications/invitations, A FIRST  
STEP TOWARDS SUPPORTING COMPLETE SCHEDULING WORKFLOWS:

"Given that, can we take an iterative approach to this issue, build  
out some low-cost features that hint in the direction of fully  
integrated scheduling workflows (ie. just be able to view free-busy,  
but not be able to select a time, send out an email ping from  
chandler, but not actually send out an event or be able to manage  
acceptances and declines.)

I think even such small things could dramatically enhance the  
calendaring experience and leave us wiggle room to figure out what  
the next steps are based on user behavior."

=====
There was also a proposal for introducing the notion of groups so  
that users could subscribe to all available free-busy information for  
your work-group without having to enter a separate URL for each work- 
group member. (See quoted text below.)

> Lisa Dusseault wrote:
>> So the answer boils down to:  yes, for members a cohesive group  
>> that has their calendars hosted in the same place, each person in  
>> that group will be able to use a single Cosmo URL to find their  
>> own calendar and those of the others in the group.  Beyond that,  
>> sorry.
> You'll have to forgive my ignorance on WebDAV, but does it have any  
> concept of groups? i.e. if you can "look up" a user and ask for  
> view-free-busy, can you look up a group and get information about  
> the group?
>
> The reason I ask is perhaps its possible to look up a group, and  
> get back a set of URLs that the client can go check for free-busy  
> information. So if you can look up "OSAF Apps" and get a set of  
> URLs that correspond to the members of the group, perhaps those  
> URLs could also refer to users/urls on other servers as well.
>
> then it would be up to the client to merge this information  
> appropriately.
>
> Alec
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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/20051207/647358f9/attachment.html