Status Brian K has asked me to put a stake in the ground as far as design is concerned with regard to IMAP, both in terms of

1. the long-view: "How will we Chandlerize IMAP so that it's integrated into the Chandler data model and user experience?" AND
2. the short-view: "What can we do in the short-term (0.7?) so that we can expose and validate IMAP work at the GUI level?"

This proposal has not been discussed with any members of the Apps team, therefore, it should not be taken too seriously. It's simply so we have something concrete to talk about.

1. Syncing your IMAP:

1. Fill out your IMAP account information
2. Sync mail
3. Dialog: User can choose to pull down all of their folders OR select to pull down just a few folders.
4. Pulled down folders appear as collections in the Sidebar with special IMAP folder icon
5. All messages get dumped into All my items, All my mail, In and Out (respectively)
6. Users can specify if they want Incoming email to arrive into the NOW section of their Dashboard view or the DONE section of their Dashboard view.
7. IMAP hierarchies are represented with a naming convention. (ie. Parent.Child)

For example:

• Mailing lists
  • Bugzilla
  • Devlist
  • Designlist

Would become:

• Mailing lists
• Mailing lists.Bugzilla
• Mailing lists.Devlist
• Mailing lists.Designlist

Brian Kirsch:

The main issue with this mailbox naming scheme is that '.' is a valid IMAP folder name character and is used extensively for newsgroup lists i.e. #comp.test.mailist. Using the '.' for folder hierarchy will work but it may cause confusion and in random cases a user could have an IMAP folder named "mail.test" and another IMAP folder named "mail" with a subfolder named "test". With this proposal Chandler would flatten the later creating two collections with the name "mail.test".

2.Interacting with IMAP folders and the IMAP server from the Chandler perspective:

1. When a user clicks on an IMAP collection, Chandler goes to fetch the message headers from the corresponding IMAP folder on the IMAP server.
2. When a user clicks on an IMAP message, Chandler goes to fetch the message body from the corresponding IMAP folder on the IMAP server.
3. When a user adds an IMAP message (1) from one IMAP collection (A) to another IMAP collection (B), Chandler adds a copy of the IMAP message (1') to the corresponding IMAP folder (B') on the IMAP server.
4. When a user removes an IMAP message from an IMAP collection, the message is also removed from the corresponding IMAP folder on the IMAP server.
5. When an IMAP message (1) that belongs to 3 IMAP collections is removed from one of the IMAP collections (A) it is a member of, the corresponding copy of the IMAP message (1') is removed from the corresponding IMAP folder (A') on the IMAP server. The other copies of the IMAP message (1'', 1''') remain in their respective IMAP folders on the server.
6. When a user deletes an IMAP message that belongs to multiple IMAP collections, all corresponding copies of the IMAP message are deleted from their respective IMAP folders on the IMAP server.

3. Interacting with Chandler IMAP collections and the IMAP server from the IMAP server or another IMAP client:

1. When a user moves an IMAP message from one IMAP folder (A') to another IMAP folder (B'), the IMAP message is moved accordingly in Chandler from one corresponding IMAP collection (A) to another corresponding IMAP collection (B).
2. When a user deletes an IMAP message (1') from an IMAP folder (A'), the corresponding IMAP message (1) is deleted (or placed in the Trash collection) from the corresponding Chandler IMAP collection IF the IMAP message (1) only lives in a single IMAP collection. OTHERWISE, the IMAP message (1) is simply removed from the corresponding Chandler IMAP collection (A).
3. When a user copies an IMAP message (1') from one IMAP folder (A') to another IMAP folder (B'), the two copies are treated as separate items in Chandler.

4. Flagging:

Users can set a preference for how they want IMAP flags to be represented in Chandler. ie:

• Stamp as a Task
• Assign a Triage status of Now.

5. Junking:

Junked IMAP messages are removed from all Chandler collections and placed in the Junk collection.

Brian Kirsch:

How is a message flagged as junk in Chandler? When a message is flagged as junk in Chandler then a \Junk flag should be added to the IMAP message on the server and the message moved to the Junk IMAP folder if one exists.

Challenges to implementation:

1. Maintain relationship between copies of the same IMAP message to a single Chandler item.
2. Brian, can you add more detail?

Brian Kirsch:

Yes, it is a challenge to have distinct IMAP messages with unique IMAP UID's in different IMAP folders mapping to a single Chandler Message Item. The relationships must be maintained by reference counting and a lot of mapping logic.

The main issue with this approach is offline mode just became a great deal harder. A users interaction with a single Chandler Message Item can result in may IMAP commands to maintain this sync between IMAP folders. If these actions are done offline trying to recreate them later on an IMAP server could lead to failures. It is certainly not impossible but it is a lot of work and error prone.

---

INTERIM PROPOSAL

Our first step however is to implement a basic version of IMAP folders in Chandler that doesn't try to:

1. Integrate IMAP folders with Chandler collections
2. Deal with maintaining the relationship between multiple copies of IMAP messages and a single Chandler item
3. Flattening out the IMAP hierarchy
4. Stamping IMAP messages
5. Including IMAP messages in cross-kind Chandler collections
6. Interact with the Appbar

1. IMAP folders will live in a separate sidebar pane
2. All IMAP folder hierarchy is preserved
3. An IMAP message can live in only 1 IMAP folder
4. DnD between IMAP folders means a move rather than a
5. When a user clicks on an IMAP folder, Chandler fetches all of the message headers from the IMAP server
6. When a user clicks on a message, Chandler fetches the body of the message from the IMAP server
7. When a user deletes a message from an IMAP folder, Chandler deletes it from the IMAP folder on the server and vice versa
8. I don't know if we're supporting Junk in the near-term

• IMAP_sidebars.png:
  

Brian Kirsch:

I think this is a good first step. My main concern with the ultimate proposal of flatten collections representing folder-subfolder names and maintaining sync of one Chandler Mail item between mutiple folders is "is this what users of mail want?". I am not convinced that this will create a better experience as a mail user. It may fit in to the Chandler model better and that certainly is of value but I want to make sure that we are not going to be spending a ton of time working on something without first testing this proposal to make sure it is usable.
Also one important issue was left out this proposal "what happens on an IMAP server when a user changes or appends to a Chandler Mail Item?". If users are allowed to modify Chandler Mail Items and we want multiple IMAP messages in various IMAP folders mapping to one Mail Item this is going to be a very difficult issue to solve.
Again, I think the initial proposal of creating a separate IMAP folder section on the sidebar is a good first step and one that can be started working on while all the other issues are being resolved. The only thing I did not see which is important is the interaction between multiple accounts in the sidebar. Chandler currently supports multiple POP and IMAP accounts so this should be specified.

MimiYin Are we discussing the usability of hierarchy in general? or just wrt IMAP mail clients? I think there is a high-level question to be answered which is: Are we primarily an attribute-centric personal information manager or are we primarily an IMAP client? Hierarchies simply don't map onto our data model. We don't have a notion of collections living inside of collections the way IMAP has a notion of folders living inside of folders. For example in the following hierarchy:

• Colors
  • Red
  • Yellow
  • Blue
• Hair colors
  • Red
  • Black
  • Blonde
  • Brown

It's unclear if the collection "Red" should be an intersection of "Colors AND Red" and "Hair colors AND Red" or if it's the same collection of items in both places. Also, if a user adds something to the "Red" collection, does the item automatically get added to the "Colors" and "Hair colors" collections?

An attribute-centric data model by definition means a faceted classification system, which is the conceptual opposite of a hierarchy.

We could certainly try and shoe horn Chandler's data model into a hierarchical GUI, but I think that in itself would be a lot of work and the end result might be worse than if we just had a separate IMAP section that didn't related to the Chandler collections at all.

That being said, we HAVE discussed plans for being able to save "attribute-centric" hierarchies where each level of the hierarchy has specific attribute-centric semantics. ie.

• Genre
  • Artist
    • Albums

This would in turn yield the following tree:

• Genre: R&B
  • Artist: Natalie Cole
    • Album: Unforgettable
  • Artist: Aretha Franklin
    • Album: RESPECT
  • Artist: Erykah Badu
    • Album:Baduizm

• Genre: Classical
  • Artist: Vladimir Horowitz
    • Album: Horowitz plays Looney Tunes classics
  • Artist: Glenn Gould
    • Album: French Suites

• etc.