Use Cases

• Generic IMAP issues
• How are IMAP folders represented?
• I move emails from one IMAP folder to another.
• I mark emails to be deleted using another IMAP client. When I come back to Chandler, what does Chandler do with the "marked for deleted" email?
• I mark emails as Junk using another IMAP client. When I come back to Chandler, what does Chandler do with the "marked as junk" mail?
• I delete emails using another IMAP client.
  • Brian, how do other IMAP clients deal with this issue?
• I cancel my IMAP account, what happens to my IMAP folders and email in Chandler?
• Subscriptions
  • Not supported in Canoga
• Server-based search
  • Not supported in Canoga
• Server-based filters (including Junk filtering)
  • Not supported in Canoga: Users will have to rebuild rules using Chandler affordances
• Downloading headers / bodies / attachments separately
  • Headers are downloaded first. Then Chandler will continue to download message bodies and attachments. Users can immediately move, triage, mark-up and label items even if only the message header has been downloaded.
  • All headers for new IMAP messages will be downloaded first before bodies. If the users click on an email item that has not finished downloading the body and / or attachments, the detail view pane will display a progress bar (similar to web browsers' download managers).
• If a user's existing IMAP account is deactivated what steps will Chandler need to be aware of?
  • What happens to Chandler collections that are collecting mail from that IMAP account? A The existing mail is cached, but there is a visual cue / error message to show that the IMAP account is no longer live.
  • What happens to Chandler collections that contain emails from that IMAP account? Are they cached? A Probably.
• What happens when you move an email from a folder belonging to one IMAP account to another folder belonging to a different account, possibly residing on a different server?
• Email message MIME parts can contain complex internal components such as a forwarding a message with in a message. An entire email message including attachments can be inserted with in body of another email. We need a clean way to express this relationship visually and with in the content model.
  • Questions from Mitch
    • How often does this happen?
    • How do other IMAP clients handle this problem?
  • As per conversations with Mitch, users must explicitly drag attachments out of an email to promote them to be first class items in the repository.
  • The copy of the attachment in the email is NOT the same as the copy of the attachment that has been promoted to become a first class Chandler item.
  • Sending emails with attachments are treated differently from doing a 1-time send of Chandler resource items.

• Chandler-specific
• First-time import. We want to make it easy for users to switch from their old email clients to Chandler. Chandler's target users will most likely have very elaborate folder structures that they have invested a lot of time in creating. We need to support an easy and intuitive way for users to, at the very least, do a one-time import of not only their data but also their organizational taxonomy into Chandler: I want to start using Chandler as my primary IMAP client. I have 600 messages in 10 folders some of which contain folder in folders on my IMAP server.
• I move emails between folders using another IMAP client. Do those folders correspond to Chandler collections at all?
• [OI^?] How is the IMAP hierarchical folder structure represented in Chandler?
  • A Using the "See also" section in the Detail view
  • Only import top level of folder hierarchy
  • Visually capture hierarchy with icons [insert sketch]
• How does IMAP's "1 item = 1 location" interact with Chandler's "1 item = n locations" mental model?
• How do IMAP filters interact with Chandler rules? Can we translate IMAP filters into Chandler rules?
• Chandler-specific attributes
• [OI^?] When user elevates an attachment item to appear in the summary table view as a first class item, does the user know that Chandler is creating a copy of the item? Does the version the user edits "appear to" stay in sync with the attachment in the original email?
  • A When you elevate an attachment item to become a first class Chandler item, Chandler creates a copy of the attachment item. The original attachment item stays the same in the original email regardless of susequent edits to the Chandler copy of the attachment item.
  • If the elevated attachment item is an email message itself, we just flatten the tree and present it as inline text. Files that were attached to the attached message are also flattened and become attachments to the parent message. ( a la Apple Mail) We will NOT do what Outlook does, which is allow users to see and interact with attached messages as discrete items inside of another message.
• If you delete an email from an IMAP account from a non-Chandler IMAP client, and this email was also present in the Chandler repository, should the email also be removed from all Chandler collections?
• A Chandler Collection can contain non-email items, should those be reflected on the IMAP account in some way? In particular, should the trash and junk folders on IMAP account contain only email items?

Proposals

• There is a difference between an IMAP email item and the Chandler representation of that item
• There is a difference between an IMAP folder and a Chandler collection "linked" to the IMAP folder.

Here are 3 proposals for how to handle IMAP - Chandler interactions.

1. There are no IMAP folders in Chandler. All mail on initial account set up, and all subsequent new mail goes into the Processing section of the Dashboard view and the In collection. Users must build collection taxonomies from scratch.
   • This is our approach in 0.4 except all mail goes only into the In collection
   • Beyond 0.4, we may at the very least want to honor emails marked as Junk and for Deletion.
2. Have a separate pane on the sidebar that display IMAP folders belonging to a particular IMAP account.
   • This pane of folders behave like traditional email clients i.e the folders are not Chandler collections.
   • Users can copy an item from a folder to a collection, but there are no bi-directional links between items and folders, just collections.
   • More elaboration needed.
3. Create an IMAPFolderCollection that links and corresponds to an IMAP account folder
   • Chandler discovers new IMAP folders on initial account set up. Subsequently, Chandler can manually be made to discover more folders.
   • For each newly discovered IMAP folder, a user can choose to
     1. Ignore the new folder
     2. Perform a one-time import of this folder: this creates a new Collection importing all the emails present in this folder. No attempt is made to link or synchronize this new collection with the new folder thereafter. This newly created collection has all the capabilities of an ordinary Item Collection
     3. Link a new Collection with this folder: This is a special Collection (we can call it an IMAP Folder Collection and it will be visually different from ordinary Collections) that also imports all email from the folder, but then continuously synchronized with the corresponding folder on the IMAP server account. Because of this special requirement, IMAP Folder Collections have only a subset of capabilities of a ordinary Item Collection. The restrictions of an IMAP Folder Collection are discussed below
   • IMAP_LinkedIMAPCollections.gif:
     
   • Alternatively, a user can also create a new IMAP Folder Collection from scratch and link this collection to an IMAP account . This creates a new top-level folder on the IMAP server account corresponding to the newly created IMAP Folder Collection.
   • Nested folders: IMAP folders may contain more folders. We propose that corresponding Chandler Collections do not reflect this hierarchy, rather the hierarchy is flattened, and all folders are treated in the same manner. However, the "see-also" section of these Colllections will list Collections that correspond to the IMAP folder's parent or child.
   • Unique characteristics of IMAP Folder Collection (vs. ordinary Collections)
     • No associated rules. At least for 0.5. We may relax this restriction over time if there is a compelling user need
     • When an item is DnD from one IMAP Folder Collection to another, the resulting action is a "Move" rather than the regular "Add". An email cannot be added to more than one IMAP Folder Collection.
     • IMAP Folder Collections can only contain items stamped as email communications. It can also contain other stamps. We may relax this restriction beyond 0.5.
     • The IMAP Collection link to an IMAP account folder can be severed by the user at any time. [OI] Once severed, can the link be established again? (definitely not needed in 0.5). Once severed, the folder appears in the list of "unlinked" IMAP folders.
     • IMAP Folder Collection needs to visually show that either it is "online" (actively synchronized with the IMAP account folder) or "offline" (not connected to IMAP server and thus folder). If the IMAP account is deleted, the IMAP Folder Collection will always be in the "offline" state; users can then choose to severe the IMAP Folder Collection link with the account.
   • IMAP Folder Collections have all other normal characteristics of a Collection. Thus, you can add an IMAP Folder Collection's item to any non-IMAP Folder Collection.

• Following proposal #3, IMAP issues largely boil down to how IMAP folders are synchronized with IMAP Folder Collections, especially when either Chandler or the IMAP server has been offline or unconnected. This turns it to a similar challenge that all modern IMAP clients need to face. We describe the main issues in synchronization below:
  • TBD Next Step: Brian Kirsch to write up how traditional email clients synchronized IMAP folders.
• 1 Suggestion from Sheila: Do a one-time mapping of IMAP folders to Chandler collections by flattening the hierarchy and renaming sub-folders to represent hierarchy. (ie. Computer, Computer>>Web, Computer>>Email)

Suppositions

• At a minimum...
• The Junk mail and Trash collections in Chandler will remain synchronized with their IMAP flagging counterparts. Marking a message as Junk in Chandler will result in the message being marked as Junk on the IMAP server.
  • That means that items that are Junked or Trashed in other IMAP clients will be reflected as such in Chandler upon Sync
  • Emails that are Junked and Trashed in Chandler will be reflected back to the IMAP server (even if they didn't originally live in linked IMAP Folder Collections)
• If I mark for Deletion or Junk emails from another IMAP client, Chandler will remove those messages from all Chandler collections and move them to the Junk / Trash collections.
• All incoming mail goes and stays in your Chandler Inbox (unless explicitly removed from the Chandler Inbox collection) even if you've moved it to another IMAP folder from a different IMAP client
• All items in both IMAP and Chandler collections are always Chandler items with full Chandler affordances
• Edits to emails in Chandler are not propagated back to the IMAP server.

• ZeroPointSixIMAP

-- BrianKirsch - 25 Jun 2004 -- MimiYin - 25 Jun 2004