I'd like to take a minute to
reframe this discussion.
Instead of trying to evaluate whether free-busy or pda sync or invitations are more or less important than the others.
Could we instead try and come up with user populations and usage scenarios and talk about whether there are any that either:
1. Use Chandler even if it did NOT have these features OR
2. Only use Chandler if it DID have these features
Especially in the context of the many things that are unique to Chandler.
- Free, read-write sharing
- Cross-platform
- Standards based
How will these features change the way people use calendars, what they use it for and how they use it?
Can we think outside of the traditional office environment?
1. How would a small art gallery use it to coordinate front-desk shifts?
2. How would a photographer's studio use it to coordinate scheduling equipment, traveling and client jobs?
3. How would a family use it to keep track of vacations, school holidays, doctor's appointments and school activities?
And within the context of these real-life scenarios, what are features we absolutely have to have to meet the bar of use-fulness?
To put it another way, can we imagine that there are users out there who could use Chandler in ways that wouldn't require free-busy? pda sync? invitations?
OR Can we imagine that there are users out there who would be happy ot use Chandler with bare minimum versions of some of these features? I think there are people specifically saying that "just seeing free time for even just a subset of the people I need to coordinate with" would be very useful.
Instead of trying to evaluate whether free-busy or pda sync or invitations are more or less important than the others.
Could we instead try and come up with user populations and usage scenarios and talk about whether there are any that either:
1. Use Chandler even if it did NOT have these features OR
2. Only use Chandler if it DID have these features
Especially in the context of the many things that are unique to Chandler.
- Free, read-write sharing
- Cross-platform
- Standards based
How will these features change the way people use calendars, what they use it for and how they use it?
Can we think outside of the traditional office environment?
1. How would a small art gallery use it to coordinate front-desk shifts?
2. How would a photographer's studio use it to coordinate scheduling equipment, traveling and client jobs?
3. How would a family use it to keep track of vacations, school holidays, doctor's appointments and school activities?
And within the context of these real-life scenarios, what are features we absolutely have to have to meet the bar of use-fulness?
To put it another way, can we imagine that there are users out there who could use Chandler in ways that wouldn't require free-busy? pda sync? invitations?
OR Can we imagine that there are users out there who would be happy ot use Chandler with bare minimum versions of some of these features? I think there are people specifically saying that "just seeing free time for even just a subset of the people I need to coordinate with" would be very useful.
And finally, given that there is
no equivalent of iCal on the PC, could we imagine that since we have
all the features iCal does (minus a few bugs and custom reminders)
PLUS a whole lot more, let me repeat that louder, PLUS A WHOLE LOT
MORE. Can we imagine that we can get a lot of PC users without doing
ANY new features?
(One last thing, when we say, get
more users, what do we mean by that? 100? 1000? 10,000?)
That was original theory at the end of 0.5, that the bar was much lower for calendar and that by just doing iCal for PC, we would get users.
Mimi :o)
At 2:53 PM -0800 12/1/05, Alec Flett wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
