Pieter has prodded me to revive Contacts management sooner rather than later, even if only to solidify a design approach for post-Kibble implementation.

Contacts as the Fourth Dimension

We've talked about Status, Kind and Topic being the three main organizing dimensions of any basic information management system. (See OrganizeDesign). However, perhaps something even more basic than Topic is People. Who or what organizations / entities does this item belong to? Or the converse, what are all of the items associated with this person or entity?

[Several of Chao's LPFI interviewees filed their email and organized their tasks primarily by person or entity. Certainly who or client is extremely important in most project management applications as well.]

In OrganizeDesign we barely managed to stuff the 3 dimensions we are dealing with in Kibble onto a 2 dimensionsal UI. The difficulties of finding room for a 4th dimension both in the UI and the content/data model is a large part of why we decided to defer Contacts management as a whole until after Kibble.

However, here are some of the ideas we had along the way.

The problem with Contacts in current PIMs

Contacts are becoming more integrated into PIM applications. Even in web clients, address books are generally hooked up to email clients to facilitate addressing and easy access to contact information from email To: fields. However, structurally, Contact managers are usually silo-ed in that they either appear in a separate application or window altogether (ie. Apple Address Book, gmail) or they replace the main view of the PIM (ie. Outlook). Very rarely are Contact management views integrated into the main PIM views.

Visual integration v. Data integration So something modest we can do is to simply do a layout tweak. Instead of popping up Contacts in a separate window or replacing the main PIM view with a Contacts view, we can open up a PIM pane in the same view. But this is a cheap solution that perhaps only succeeds in 1) making the UI more complex - too many panes! and 2) doesn't allot enough screen real estate to display contacts.

Contacts need to be more integrated at the data level as well:

• For every item, you should be able to see all the People or Entities related to that item either directly (ie. a People attribute on the item) or via the addressing attributes (ie. To, From, CC, BCC)
• For every collection, you should be able to see all the People or Entities related to that collection either directly or via the items that make up the collection
• Conversely, for every Person or Entity, you should be able to see all the items related to it either directly or via the addressing attributes.
• For every Person or Entity, you should be able to see all of the collections related to it either directly or via the addressing attributes.

Proposal (in-progress)

• The UI is divided into 4, potentially 5 panes: Sidebar, Summary, Contacts, Detail
• Users can open and close all of these panes
• The panes are loosely hierarchical. What is displayed in the summary pane depends on what is selected in the sidebar. What is displayed in the detail pane depends on what is selected in the summary pane.
• The contacts pane however can be either controlled by the sidebar or the summary depending on what mode it's in. Users can either see all of the contents associated with a sidebar collection OR only see the contacts associated with a particular item
• Conversely, by users can also narrow the items in the summary pane by a particular contact by essentially "searching" on that contact
• Contacts in the contacts pane are also related to each other via contact groups

Open issues

• How does the notion of "Collections" related to a Person or Entity play with the notion of Contact Groups? Can users use related Collections as Contact Groups? Can Contact Groups be related to Collections and Items? Do they remain related as Groups? or do they expand out into individual contacts?
• Leaning towards: They are the same thing.
• Does this mean that we can have collections within collections? Only in the sense that users can have a rule to automatically put items in one collection into another collection.