[Design] 0.7 Planning and Plausible Scheduling [Summary]
mimi at osafoundation.org
Wed Dec 7 13:11:58 PST 2005
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
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
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
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,
> 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Design