The PPD team has working on a proposal for the 1.0 email strategy. Up until now, the email product roadmap has been somewhat fuzzy. Chandler has always been intended to someday become a full fledged email client, a replacement for whatever email client you use today. Our roadmap has reflected this by having email features scattered through out the dot releases. However, many of these features have been deferred repeatedly in an effort to focus our development resources on supporting calendaring and task management workflow. Nevertheless, email work items persist in our plan of record. Problems: There are several problems with the roadmap as we have it today. + On the technical side, it's very difficult to build a desktop email client that will replace what people use today. The usability bar and expectations are very high and we think this presents certain barriers. + Innovative aspects of chandler, make a smooth transition from the hierarchy-based IMAP world impossible in the short term. Once we started going through the exercise to identify the ecosystem target users and their needs for collaboration, we found that strategically, we could think about email a bit differently. The users we are really targeting use products other than email for managing their calendar and task information. They are hubs, busy bodies and coordinators that manage multiple projects and an email client just isn't enough for managing everything they need to get done. They don't live solely in their email clients and for those who do, we are unlikely to get them to switch over anyhow. Proposal: Out proposal is to focus our efforts on making Chandler better than Email clients at handling the GTD and small group collaboration workflows (e.g. Drafting invitations, Task management). We can support Chandler ecosystem collaboration scenarios by: + Allowing users to get data in and out of their Chandler world via Email + Allow users to share data with others via Email + Web access + Allow users to send sharing notifications via Email This implies deferring some of the other usage scenarios for Email, e.g. + Email client as data hub for all kinds of personal information, which is how Andi uses Pine. + Email client as data hub for consuming and managing Media: mailing lists and RSS feeds + Email client as word processor for composing long communications. This really means not trying to be a replacement for a desktop email client but focussing on an email strategy that bridges the gap between the Chandler desktop client and whatever other email clients these individuals use today. In addition to prioritizing features based on the needs of this target user, we also think it's important to deliver some notion of plausible promise that we will someday have full-fledged email support. There is a basic set of features we need to support for facilitating collaboration + Send and receive + Reply, reply all, forward + Basic message compostions (support for rich text editing). + An email status column in the table with affordances for draft, queued, sent, read, unread, needs reply, replied to, forwarded. + Email threading support (this is part of the overall clustering solution). + General stamping communications workflows (edit and update). There are also a number of other known features we can phase in for plausibility + SPAM + Simple rules and filtering + Spellchecking + Attachments We are currently in the process of examining a variety of options for bridging the gap between the desktop and existing email clients. We are hoping that opening up the discussion will perhaps generate other alternatives. + Emailing items to a collection on Cosmo ie: Send a /Event to [EMAIL PROTECTED] + Drag and drop emails and attachments from other email clients. + Pull down emails that have special headers. + Handle a one-time import of an Inbox + Subscribe / Sync to select IMAP folder(s) ie: Inbox, manage design list in the desktop. + The desktop as an IMAP client + The desktop as an IMAP server + RSS in and RSS out via desktop/web access There is a larger question around strategy for operating an email service that still needs to be worked out. Next Steps: + Mimi will follow-up with a post detailing the email usage scenarios. + We will then be initiating a discussion around "bridging the gap" to explore all the options with technical pros/cons that we could consider. === This proposal is the result of numerous PPD discussions, presentations and a design session we held in April: Design Session Agenda: http://lists.osafoundation.org/pip ermail/design/2006-April/004507.html Sheila |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
