Proposed 1.0 Email Plan

There has been a great deal of discussion on how much email support we need to have or should have in our 1.0 product. Based on previous discussions, in particular, the Email Usage Scenarios Design Session and the work we have done thus far on the Chandler ecosystem target user definition, we have come up with the following proposal for email functionality we will support in 1.0. The goal here is to prioritize features based on the needs of our target user while ensuring that we deliver at least a plausible promise of full-fledged email support in the near future.

Primary Goal

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

What does this mean for Chandler as an Email client? This means that given the Email Usage Scenarios we went over in the Design Session we will not try to replace webmail clients like Yahoo Mail or Gmail or desktop email clients like Thunderbird, Apple Mail or Outlook Express.

Why not be replace webmail clients?

Given why people use webmail in the first place, there isn't a lot of synergy between webmail usage scenarios and Chandler.

• Unlike POP mail via ISPs, webmail is free and so is Chandler (assuming we run an email service as well)
• Webmail is portable (Chandler isn't)
• Webmail is primarily used for personal mail and "SPAM-llike" mail
• As a result, the GTD collaboration workflows we want to support are not needed for webmail usage scenarios
• We would have to turn Scooby into an email client which would render Chandler somewhat irrelevant.

Why not replace desktop email clients?

• The bar for usability is very high.
• Complex rules and filtering for auto-filing.
• Performance required for handling and syncing large quantities of email.
• Providing rich email composition
  • Large, independent windows
  • Lots of space to enter a large number of addressees
  • Rich text editing
  • Embedding images and files in-line inside of the body
• Providing rich reading experience
  • Large, independent windows
  • Displaying attachments embedded in the text

Target User

• Someone who already uses products other than email for calendaring and task management: e.g. Palm, Excel, Word, iCal, OmniOutliner, Planners
• In other words, users who feel like "just their email client" is not enough for managing everything they need to get done.
• People who are responsible for driving or coordinating multiple projects at the same time. (Hubs and Busy Body / Coordinators)
• Hubs and Busy Body / Coordinators will pull in other users via Cosmo/Scooby by sharing items and collections to aid in project management.

• We will not target individuals who only use email clients for managing personal information today. It is unlikely that these people would be motivated to switch to Chandler anyway.

Required features for supporting collaboration workflows

• Send and receive.
• Reply, reply all, forward.
• Basic message composition (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).

Phasing/Prioritizing the OUT features in order to capture an early adopter audience

Having enough Email functionality to get GTD-obsessed early adopters

• SPAM filters
  • How difficult is this?
  • Not supporting SPAM assumes that users will not be pulling unfiltered Email into Chandler (as in Email that has already been filtered by another Email client).
  • If we don't support pulling down unfiltered email in Chandler, we could implement special Chandler headers to pull down Chandler to Chandler email; OR Users can drag and drop email into Chandler from other clients instead.
  • However, even if SPAM isn't needed for a usable 1.0, is having SPAM filtering just one of those things we need to show plausible email?

• Rules and filtering
  • As with SPAM, if we don't have filtering and rules we assume people will not pulldown their email into Chandler.
  • However, is there some simple solution we could implement as experimental UI to show plausible email? e.g. Saving search queries as collections.
  • There might be some group of early adopters that are willing to forego the rich email reading and composition experience they get in their current email client in order to take advantage of Chandler's triage workflows for processing large quantities of mail.

Meeting the bar for using Chandler to share items and send sharing notifications

• Spellcheck?

Meeting the bar for using Email as a way to manage document-sharing

• Attachments
  • Needed for plausible promise?
  • What are ways to phase this? Define a small sub-set of MIME types to support (e.g. photos, text files, office documents, but not sound or video files)
  • If we handle some attachments, it would be useful to define a resource kind. Users can stamp emails with important attachments as resources.

Features not targeted for 1.0

• IMAP folder sync
• Large scale import of existing folder structure

Ways to bridge the gap between the Desktop and existing Email clients

• Emailing items to a collection on Cosmo ie: Send a /Event to officecalendar@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

Options for Email Service

• User accounts - special ecosystem email accounts
• Collection accounts - mail to a collection

Top Concerns

• What are the implications of not showing some email client plausibility in 1.0?
• The suggestions above rely heavily on people getting data into Chandler in innovative ways ie: dragging emails. This doesn't really work currently and the drag and drop performance is poor. Can we really make this usable?
• Can we realistically support allowing people to import their Inbox? What are the performance implications here? Even if we were to only support downloading emails with special headers, imagine everyone at OSAF using Chandler to send email, I could imagine my Inbox would still grow rapidly.
• Should we be proactive about looking for community help to get more email functionality done within the 1.0 timeframe?

Implementation limitations

• Performance
• 2-way IMAP sync (getting Chandler to work with all flavors of IMAP servers)
• GUI work
• Need to work against any IMAP server (ie: Thunderbird and Apple Mail have to work against any IMAP server configure however). We have identified that this is expensive.

Proposed Plan

1. Email support for collaboration workflows
2. Build bridge between existing email clients and the desktop via:
   • DnD from select email clients
   • One-time download of new mail with special Chandler headers from IMAP/POP accounts
   • One-time download of new mail from select IMAP folders and/or POP accounts
   • Set up IMAP server within the desktop to allow users to move email from their existing email account to the desktop (provided they are on the same machine)
   • Hard to do: Email items to collections on Cosmo (e.g. officecalendar@cosmo.osafoundation.org)
3. Some amount of work to capture early adopter, metrotechnicals as experimental email users
   • One-time download of new mail from IMAP and POP accounts
   • Text-based filtering
   • Integrated SPAM libraries
   • Integrate Spellcheck libraries
   • Don't solve the reading/composing experience problems

-- SheilaMooney - 09 May 2006