Mimi did an excellent job summarizing our current thinking. I just
wanted to add a few extra points.
See comments in line.
Mimi Yin wrote:
Sorry, I was an idiot and had no subject line. Sending again.
We are continuing to figure out our email plan. Here was the last,
most complete summary (from Sheila) of the various 'Email - Bridging
the Gap' options we have available to us:
http://lists.osafoundation.org/pipermail/design/2006-August/005225.html
The two candidates at the top of our list is subscribing to IMAP
folders and implementing special Chandler headers so that Chandler
clients can communicate with each other directly, without forcing
users to pull down all the email in their Inbox.
Brian Kirsch has proposed a stop-gap measure for IMAP folders, which
is perhaps even better than allowing users to pull down arbitrary IMAP
folders.
When users fill out IMAP account information, we provide them with an
option to set up special "Chandler IMAP folders" that allow them to
not only add messages from their email clients into Chandler, but also
to specify whether they want the message to be added to the Task list
or Calendar. (All messages are automatically added to Mail.) (The
option should probably be checked by default, with a [Configure]
button that allows the user to choose which of the 3 folders they want.)
There is an additional option for POP users as well which is to leverage
the Chandler IMAP server parcel that Travis worked on. In a POP context
there are no server side folders and thus no easy way to
intercommunicate between Chandler and the mail client. In this case
having an IMAP account that points to Chandler is key. The Chandler IMAP
server parcel would expose three folders Chandler Mail, Chandler Tasks,
and Chandler Calendar. Whether a person is working in a POP or IMAP
environment the user experience is the same. However, when using POP
there is a limitation currently that Chandler hosting the IMAP server
parcel must be running.
In addition, it would be great to have some scripts that could
pre-configure the IMAP server parcel account information in the most
used mail clients such as Apple Mail, Thunderbird, and Outlook / Outlook
Express. This way the complicated aspects of setting up an IMAP account
can be abstracted from the user.
Eventually, we could also add support for web mail applications such as
Gmail and Yahoo Mail using the same folder / labeling strategy. For
example, Chandler could pre-create three folders in a users Yahoo mail
account Chandler Mail, Chandler Tasks, Chandler Calendar. Placing a
message in one of these folders has the same results and behaviors as
working with an IMAP client.
Thus, we have a unified experience across a variety of clients and
protocols.
The 3 folders would be:
+ Chandler Mail: Messages in this folder are added to the Mail Dashboard
+ Chandler Tasks: Messages in this folder are added to the Task Dashboard
+ Chander Calendar: Messages in this folder are added to the Calendar
Dashboard
The natural language / date parsing tools that Bear and Darshana worked
on would be used to determine context when messages are placed in the
Chandler Calendar folder.
This of course, doesn't allow users to add the same message to both
the Task list or Calendar. But it's a huge improvement to not being
able to specify a context at all.
Actually that is not true. Each mail message has a unique message id. If
a user copied a message to both the Chandler Calendar and Chandler Tasks
it is conceivable that our mail service could be smart enough to
determine that the user wanted the message to be both a task and a event.
However, this is advanced logic that would take some development work.
I would propose holding off on this and consider it an enhancement in a
future version of Chandler.
For mock-ups, see:
http://wiki.osafoundation.org/bin/view/Journal/UnifiedDataInAndOutProposal#CommentsSection
Brian also raised the excellent question of: will our target users
have IMAP accounts? How widely deployed is IMAP amongst small
workgroups with scarce IT resources?
Yes, I am concerned that our target users may not be leveraging IMAP.
However, with the foldering strategy proposed I think we can also
provide a decent experience for POP and eventually Web Mail users.
-Brian
Thx,
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
--
Brian Kirsch
Internationalization Architect / Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
