Proposal for Contact additions

Chandler would like to support importation of Contact items from other applications, including but not restricted to Microsoft Outlook. Early invesigation into this indicates that there are a lot of foreign contact properties that do not have corresponding Chandler Contact attributes. This is a rough proposal for how to deal with those.

The proposal should also work for the synchronization case. We'd like to support synchronization of Contact information between Chandler and a PDA. We will certainly find in those cases as well, that a user's PDA is likely to have some fields that we haven't put into the core Chandler content model.

Fields proposed for addition to Chandler Contact model

• Suffix
• Department
• Profession
• TTY/TTD Phone --> added to phone TypeEnum^?
• Title (this is not job title but a title that goes along with the name like "Sir" or "Professor", I think -- or maybe "Ph.D." going after the name. What about multiple titles?)

Less obviously useful fields

After the set of fields that could reasonably and usefully be added to the Chandler Contact Model, there are many fields in Outlook (and surely in other applications like Macintosh Address Book) that we don't see as clear a need for, are rarely used, or are confusing. We don't want to add dozens of such fields to the Chandler Contact model in such a way that users are confronted with more options than they want. For example, a user could try to customize the contact detail view to show extra fields but be confused about whether to add or use "organizational ID number" or "government id number". Even if the fields are clear, like "assistant's phone", having a large number of rarely used fields is still a burden to browse through. Here is a sampling of some of these.

• Email type (definitely less useful today when many people have multiple email addresses)
• Categories
• keywords (not identical to category. There are likely only 3 to 10 categories but could be hundreds of keywords)
• mileage
• Assistant's phone
• Manager's name
• Initials
• Email display name
• Language
• Hobby
• Government ID number
• Organizational ID Number
• Billing information
• Account
• Internet free busy
• Location
• Office location
• Priority
• private
• referred by
• sensitivity

More fields will certainly show up when Chandler attempts to synchronize to or import from other formats and applications -- this is simply a set of examples that happened to arise from Outlook import work.

We'd like to come up with something to do besides ignoring these fields. If we ignore them then data importation becomes a lossy process. We came up with a few ideas what to do...

Add rarely used import fields to "notes"

This preserves the information and makes it visible to the user. Not so bad, only it makes it hard to deal with the information semantically.

Add fields to Chandler Contact model at import time, if used

This approach, suggested by Katie, would involve dynamic extension of the Contact model. Imports are rarely done, and when done, most of these fields we expect to remain empty. If any of these fields do happen to contain information that we want to preserve during the import, the import engine could modify the Contact model on the fly by adding a new attribute to the Kind description. This way, a user that always filled in "Language" in their Outlook contacts would find that Language appeared in their Chandler contacts as well after the import process.

Add "hidden" fields to Chandler Contact model

Brian Skinner came up with the idea of including all these fields in the Contact model from the start, because unless these attributes exist in the schema it's hard for developers to refer to them. However they'd be marked "hidden", and an attribute would only be changed to "visible" when data actually became available in that attribute.

Next step

next action is to review with Mitch.

Related

• ContentModelInteroperationProject

Notes from discussing ExportableAddressesJun2004

Mimi suggested that use cases be grouped according to how visible the exportable address would be:

Address is invisible

• Chandler<--> chandler true sharing
• Chandler<-->chandler remote browsing by following links (e.g. starting from a shared event, link to a shared contact, then link to another shared contact)
• Chandler <--> chandler remote browsing starting at root

Address is visible but not used

• Navigate to one's Chandler server when off-site, in order to navigate to contacts and see an HTML representation of both a list of contacts and each individual contact.

Address is visible and used

Are there any use cases here? So far we're trying to avoid these.

Skeleton removed from ExportableAddressesJun2004 proposal

This skeleton was originally in the ExportableAddressesJun2004 proposal. It was designed to have deep structure and short names, which is optimized for Unix-like use cases where screen space is limited, navigation is extremely primitive, and users have to type in names a lot to get around. Thus, it may be a poor model for Chandler scenarios. OTOH, if exportable addresses are to be used by parcel developers to name Kinds and other schema items, this would probably feel the most natural to them.

- [ ] Chandler                                                            The "root" -- might not be named
    - [ ] Schema
        - [ ] Core
        - [ ] <parcel-name>                                               Arbitrary #'s of parcels schemas
    - [ ] Lisa                                                            A user's user data
        - [ ] Mail                                                        May contain more than just mail...
            - [ ] <account-name>                                             ... may not contain all the mail
                - [ ] Inbox                                                  ... but it's a useful place to start
                    - [ ] Msg336
                    - [ ] <IMAP folder name>
                - [ ] Outbox
        - [ ] Calendars
            - [ ] Personal
                - [ ] <Appointment name>
            - [ ] Work
        - [ ] Contacts
        - [ ] Tasks
        - [ ] Sharing
            - [ ] knitting-group                                          Ex. heterogeneous coll'n
                - [ ] Appt3
                - [ ] sweater-photo
                - [ ] Msg337
        - [ ] Views
            - [ ] Email containing "eclipse"
            - [ ] All items of kind "Contact"
            - [ ] Tasks not yet completed which are due in <1 week
    - [ ] <other-user-name>
        - [ ] Mail...
        - [ ] Calendars...
        - [ ] Contacts...
        - [ ] <etc...>

-- LisaDusseault - 22 Apr 2004