Lisa Dusseault wrote:
We were just discussing, offlist, simplifications to
free-busy which
would make it much cheaper to implement than a full, whizbang,
tailored and finished free-busy browse/view feature:
This is clever.. we could probably go a long way with it - grey out
sections of the existing calendar that are busy, and so forth.
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?
Obviously all of these questions have specific, solvable technical
solutions, it just seems like a lot of work. I may be very
wrong :) Perhaps it really is as simple, for a first go-round, to just
enter a bunch of e-mail addresses in a popup dialog, and look them up
on all the servers we subscribe to or something?
That said, generally one tries to decide the desirability
of a feature
independently of its cost, to a certain extent. Are simple
invitations more important than free-busy if you assume that the cost
is the same?
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.
However, for within-the-workgroup scheduling, obviously Free/Busy is
pretty useful and important.. I just don't know if we're going to be
dogfooded for that (outside of OSAF) as early as 0.7?
Alec
Lisa
On Nov 30, 2005, at 2:57 PM, Alec Flett wrote:
Sheila Mooney wrote:
-> Dogfood Sharing/Calendar #2 - Move the
calendar towards feature complete by adding features like free-busy.
Respond to bug fixes and/or enhancements that block calendar usability
as users discover them.
While I think free-busy is an interesting problem, and supporting it
would certainly make us look cool, I'm not sure it is as practical or
useful as very, very basic invitations... on top of this 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.
I haven't seen use cases yet, but say the use case is "A user should
be able to set up a meeting with another user in the same work
environment" - I see two basic, dogfood workflows:
1) user A talks to user B, user B says "I'm free tomorrow afternoon"
- user A makes a meeting on their calendar, invites the user B to it
by sending an e-mail with a vcf/whatever attachment (Jeffrey can set
me straight here) - user B either accepts it or rejects it. If they
accept it, its put on their calendar.
(I don't think we'd need to keep track of what invitations were
sent/accepted/rejected for a first round - I mean honestly 90% of the
meetings you're going to schedule are going to be accepted anyway
because our target users are in small workgroups and probably already
talk to each other about the meeting in the first place. A rejected
meeting could simply generate automated e-mail message that said
'[EMAIL PROTECTED] has
rejected your meeting "Business Lunch" Please reschedule it.')
Requires: (maybe) user A and B talking ahead of time... if they work
closely enough together, this might not matter.
Technical requirements: A button that says "invite other users" in
the detail view. Ability to create an e-mail message, attach an
iCalendar file to it, and send it. (we do much of this already)
Ability to load a received attachment and insert it into a calendar.
2) user A looks up free/busy information for the other user, and
schedules a meeting on a shared calendar.
Requires: a shared-calendar relationship that is already
established.. either:
scenario 1: user A and B share a calendar OR
scenario 2: user A has write-access to user B's calendar
Technical requirements: Free/busy UI, server support for free/busy
queries based on a user, ACL support (scenario 2)
I guess I just think that all the parts of the workflow required for
a barely usable Free/Busy implementation are fairly complex, require a
lot more design and implementation work, and introduce tighter
dependencies on Cosmo implementation. If we're trying to minimize the
amount of work in 0.7 and still make noticable gains in terms of
features, bare-bones invitations seems like the most bang-for-the-buck.
[All of that said, if we do end up doing Free/Busy, sign me up,
because it sounds like a lot of fun to design and implement.. :)]
Alec
-> Plausible Dashboard - Basic working table
with sort, search and UI polish as well as infrastructure to lay
foundation for innovative PIM features around task and project
management.
-> Application Infrastructure - Continued
work on performance, widgets, undo framework.
-> Developer Platform - Schema upgrade, content model
as
well as refactoring and documenting APIs that 3rd party developers can
use. This includes work refactoring CPIA.
-> Release Packaging - now that some portion of the
product is usable, investing more time to enable users to download and
run Chandler on all 3 platforms. In particular, distribute via
conventional means on Linux distributions.
Questions/Issues:
-> How much calendar work do we do? Do we focus on bugs
fixes or tackle new features such as free-busy? How do we bound this
tenet around a clear goal so we can prioritize the work?
-> Should we be considering PDA sync or is that out of
the question for 0.7?
-> How much email work should we do in 0.7 and what are
the consequences of delaying this further? There is some email work
planning to support of the dashboard tenet what happens if we have to
make some tough choices and don't do this?
-> What do we really mean by plausible dashboard? If we
do the basic table work, what other aspects of the dashboard and task
management features do we need to add in order for us iterate and get
some valuable user feedback on some of these designs?
-> Should we focus on trying to have a shorter release
than 0.6 by doing less? Maybe we have 2 short releases instead of one?
-> What is appropriate to tackle in the infrastructure
tenet and what could be deferred? Undo? ACLs?
I realize some of these tenets are very high-level and it's hard for
people to comment on the dashboard when we are still trying to
determine what that is for 0.7. The goal of this exercise is less
about debating the details and more about getting some feedback from
those close to the project about what features or areas of the app,
they feel we should be working on (ie: building out innovative
features like the dashboard or getting to a usable email client).
It's tough to think about 0.7 without some context for the larger
product roadmap so I have included a link to our latest "1.0 stickie
plan" (view in firefox) which is a possible scenario for
getting to a usable product in the 1.0 timeframe. This is a work in
progress will be evolving with every dot release but we wanted to give
folks a sense of where certain features fall on the roadmap that are
NOT part of the 0.7 tenets. This demonstrates how we see certain
application areas evolving in the product life-cycle.
http://wiki.osafoundation.org/pub/Projects/ChandlerHome/roadmap.html
Comments on the tenets, issues or new questions for us to ponder are
all welcome. Based on all the feedback we receive, the product team
will make the final decisions on the 0.7 tenets, taking into account
all the various comments. Please send all replies to the design list.
Sheila
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
|
