I am in the process of summarizing all the various email threads on the design list by starting with those that are slowing down. The question we are asking: Is there a bare bones feature set that would allow early adopters to use Chandler as an email client? What is that feature set? We realize that in the long-term a full email client is very important to the vision of Chandler. Solving the problem in the short-term is more challenging. We are trying to tease out is there some minimum bar that people would tolerate in order to switch to Chandler for email.We realize that we also need to solve the "bridge the gap" issue as well. But, if they were to switch, what is essential. Ted: + tracked email operations for one morning + view messages by thread + delete a message + select a message and execute an Applescript/zsh script suite to kill comment spam postings off my blog (outlier feature) + some filing + click on a URL embedded in a browser + mark some read messages as unread for later re-processing - give me a triage based workflow for this + reply to messages, including editing the to/cc lines because our default list reply to is wrong, i did work on several replies simultaneously. + send new e-mail messages (to remembered previous recipients) + nice to haves that I do less frequently + paste text from the clipboard into a composition/reply window + verify/decrypt a PGP signed/encrypted message + search for a particular message + look at the raw source of a message + work offline + send again + download an attachment + attach a file via a standard file dialog (I don't do drag and drop attachments) + doesn't do + compose HTML mail + stamping and triage make up for the loss of other email features John: + doesn't use compose HTML mail either but we need to be able to read HTML mail + would give up composing HTML mail for stamping and triage Bear: + would also need viewing by thread and delete messages + rules + click on a URL embedded in a browser + mark some read messages as unread for later re-processing - give me a triage based workflow for this + reply to messages, including editing the to/cc lines because our default list reply to is wrong, i did work on several replies simultaneously. + send new e-mail messages (to remembered previous recipients) + paste from the clipboard into composition window + search + look at the raw source of a message + doesn't work offline + attach a file via a standard file dialog Dennis Lynch: + predicts that people won't accept more than a 10-15% decline + people would be willing to accept this though if there were other big features such as integration with calendars and tasks. Jared: + works offline at some point most days - BART + requires full IMAP folder synchronization and operations + would fit into the category of people that couldn't switch and would use interop path + uses 2 email clients simultaneous, both synching through IMAP + likes the option for dragging a message to an IMAP folder and have Chandler sync with that folder Jeffrey: + needs a few additions to what Ted mentioned + read my existing IMAP inbox, treat messages there as NOW + move messages marked LATER to a LATER IMAP box + scan that LATER mailbox to see if I triaged through a non-Chandler mail client + similarly, move DONE messages to my filed box + if an email Chandler knows about used to be in one of these mailboxes but isn't anymore, it puts the message in the trash + creates tasks and emails them to himself but this will likely be solved in Chandler by triage + uses quote handling a lot, both in reading messages, and composing them - could live without it + doesn't compose of read HTML mail |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
