About a month ago, I sent out this email to generate discussion around technical pros/cons for various alternatives to bridging the gap between email clients and Chandler desktop. As a reminder, the list of options we are discussing is as follows... + 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 Not all of these were addressed directly but I will attempt to summarize what conversations did materialize and add in the design team perspective. Two new suggestions were also added. + Emailing items to a collection - This option generated the most discussion which prompted Mimi to start a second thread. - It's more productive to summarize this separately but the overall outcome is that there is probably a workable solution so we can test out the workflow but it probably won't meet our usability requirements ie: email addresses are complicated to remember. - Seems like there is something doable in the Beta or 1.0 timeframe. - The design team likes this option since it requires minimal work for the user. + Drag and drop emails and attachments from other email clients. - This works today but not reliably for all email clients. - Not really appropriate for people who want to pull down a large number of items. - A nice to have since people may discover this pretty easily. - It would be enough to have this work for one client so we can validate the workflow. + Pull down emails that have special headers - There was very little dialog around this option. - Katie asked about other advantages beyond reducing the size of the repository. - The design team likes this alternative since it means that I can use my existing email accounts but will only receive items sent from other Chandler users. It requires users to do minimal work. - Some initial conversations with Brian K indicated that this was a doable solution. - Basically if I send notifications from Chandler, they can be received by other Chandler users. - IT WOULD BE NEAT IF - I send a notification to someone using another email client and they reply, we would be able to receive these back in Chandler by preserving this special header somehow. Grant implied this was doable but would be more work. + Handle a one-time import of an Inbox - Assumes people want to bring in an entire inbox or a folder. - As new items sync to Chandler as they get added to the inbox or folder. - Again it restricts the size of the repository. - Seems like it's not too difficult. + Subscribe / Sync to select IMAP folder(s) ie: Inbox, manage design list in the desktop. - Same as above. - You can create a rule to copy items as they come in, vs moving them by hand. - We will make no attempt to keep them in sync ie: I delete an item in Chandler or add stuff in Chandler, it would not sync back to the IMAP folder - A one-way mechanism to get stuff into Chandler + The desktop as an IMAP server - Another possible option. - Create a rule to copy all flagged items in to Chandler. In Chandler I triage, tag, stamp etc. Don't have to type in all these items again. - Travis has been experimenting with a parcel for this. - At a design perspective, we prefer the above 2 options since this solution only works locally (email client and Chandler are on the same machine). - This option seems easier to implement at an engineering perspective and is already in progress. + The desktop as an IMAP client - This one wasn't really discussed. + RSS in and RSS out via desktop/web access - Someone could subscribe to the shared Office calendar as an RSS feed, meaning that they would RSS style updates. - It's more suitable for someone tracking tasks or a calendar. - For notification only - not read write. - It sort of duplicated email and having the notifications received in email is enough to validate the workflows for Beta. - No discussion around this one as to the technical pros/cons. - The design team doesn't think we need this for Beta/1.0. + Thunderbird extension - Create a Thunderbird extension to add a toolbar button that will stamp mails as an event or task. - Custom headers are added to identify this as a chandler item - it's sent to Cosmo and appears in the Chandler dashboard. - Extends Thunderbird's handling of email headers beyond RFC standards. - Established known user community. - Interesting project but maybe too big for Beta. + Hosted service email accounts - This has come up a few times before. - Some work for Jared - hosting email accounts. - People don't necessary want to have to give out a new email address, they would rather use existing ones. - You will have to know all the email addresses for the other Chandler users. - Other users will need to find out your OSAF email client in order to send you email. - Other users will not know if you would prefer to receive their communication in Chandler or in your normal email client (different emails). - At the receiving end, you will need to add the OSAF email account to you existing email client in order to receive email sent to that account. - You will probably still receive email to your normal email accounts that you would like to have in Chandler. As a result, this solution doesn't necessarily help users move data between their existing email client and Chandler. - Doesn't really get us further on bridging the gap. In terms of satisfying the most likely "bridge the gap" scenarios for Beta, the PPD wish list would be... + Pull down emails that have special headers + Subscribe / Sync to select IMAP folder(s) ie: Inbox, manage design list in the desktop + Email submission to collections + Dnd support for one particular client as a proof of concept If you have any additional comments please forward to the list. I will be summarizing the "emailing items to collections" thread separately. Sheila |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
