[Design] Email plan

[Sheila Mooney]

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.

http://wiki.osafoundation.org/bin/view/Projects/PlanningProcess

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  
officecalendar at cosmo.osafoundation.org
+ 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
Meeting notes: http://wiki.osafoundation.org/bin/view/Journal/ 
NotesEmailDS0411

Sheila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060705/9059acb8/attachment.html