Chandler Address Book Project

People

• ErnestoRivera: Google Summer of Code student
• GrantBaillie: Mentor

Proposal

From GoogleSummerOfCode2006:

The aim of this project is to implement, in python, a usable address book in Chandler. The first step would be to extend the existing, limited, Contacts data model, which doesn't currently support groups, or multiple field values. This would be followed by implementing import and export of vCards, and adding a UI to display contacts in Chandler's detail view. Possible further directions are to add support for digital identities, to add social networking features within a user's address book or to use the annotation feature of the Chandler data model to use contacts as a way of organizing extensible PIM data around people (examples of this would be flickr, del.icio.us, or Amazon data).

Recommended Reading

• 0.6 Chandler architecture overview: The big picture of how the pieces of Chandler fit together.
• The Parcel Developer’s Guide to the Chandler Schema API
• Another Parcel Developer’s Guide, this time using XML parcels
• Older, but related documents:
  • ContactSchemaNotes: Some notes on VCard, and interoperability with other PIMs.
  • ContactContentModel

• ContactsFeaturesForBeta: Where we’d like contacts to be in a year’s time

PyCon 2006 Sprint code (.zip)

• This is an address detail view written by PyCon 2006 sprinters.
• It's been packaged to be installed into Chandler as a Python egg. See the README.txt file on how to install.
• For more details and background on egg-based plugin development, see http://lists.osafoundation.org/pipermail/chandler-dev/2006-March/005552.html.

Project Status

The SoC 2006 program is over. The final code is available and should work with Chandler 0.7a3.

Tasks

Current active task: Documenting

N°	Task	Time (est.)	Time (real)	Status
1	Get familiar with Chandler development, source code and current contacts implementation	2 weeks	4 weeks	Done
2	Allow users to create/view/edit contacts	1 week	<1 week	Done
3	Decide and implement the role of contacts in Chandler	1 week		Paused
4	Create simple/nested groups of contacts	1 week		Paused
5	Implement role of groups	<1 week
6	Further integrate contacts within Chandler	1 week
7	Conform contacts to the vCard format	1 week	3 weeks	Done
7.1	Allow GUI-editable multi-value fields	1 week	1 week	Done
8	Import/export vCards	1 week	3 weeks	Done
?	Other proposed features

Note that contact group task's priority has been lowered in order to ensure better vCard functionality.

Source code

SVN repository:

Currently the code expects to live in the parcels directory, so it's easier to only cleanly export the source:

svn export http://svn.osafoundation.org/sandbox/ernesto/contacts/ $CHANDLERHOME/parcels/contacts

If you intend to modify it then you should checkout the code to start with your own working copy.

Note (GrantBaillie): I’ve made some small changes to get Ernesto’s code to run in the latest Chandler release (0.7alpha4). You can get this updated version at:

http://svn.osafoundation.org/sandbox/grant/Contacts/0.7alpha4/Chandler-ContactsPlugin/

(The code has been packaged to be a Python Egg-based plugin; see the file README.txt for more information).

Documentation

Please refer to the AddressBookDocumentation wiki page.

Tasks (in detail)

2 Allow users to create/view/edit contacts (basic editing only)

Goal: Use Chandler's GUI and the existing contacts implementation to allow users to create basic contact items through the 'Item->New Item->Contact' menu. Create a customized Details View for 'Contact' Items. Contacts should be listed on the main view side by side with other items as it is Chandler's philosophy to mix different kinds of information.

Results: PyCon code already creates ContactPerson objects (single contacts) with some basic attributes, adds a "new contact person" menu, adds an Address Book collection to Chandler's sidebar and provides a basic detail view. This code has been moved to a "contacts" parcel in Chandler (and should later be moved to the osaf.pim chandler). The ContactPerson was converted to a subclass of an abstract Contact class (which will also include a ContactGroup subclass). ContactPerson's detail view has been updated to include the required "headline area", and the standard appearsIn area.

3 Decide and implement the role of contacts with other Chandler items

Goal: Decide the results of both "stamped contacts" and "contact-stamped" items (tasks, mails, etc.), while keeping in mind the future addition of groups of contacts. Also decide the behavior of contacts sharing. Write necessary code to ensure according behaviour.

Progress (paused): Being discussed.

4 Create simple/nested groups of contacts

Goal: Define a new kind of item, ContactGroup, which references (doesn't contain) any Contact subclasses' instances (ContactPersons and/or ContactGroups). Create a detail view listing a group's contents and allows to add (drag & drop?) and remove them. This could be similar to OSX Server users' admin tool. Groups could also be a subclass of pim.CollectionItem which would allow groups to live on Chandler's sidebar (undesirable most of the time), and to add members by simply drag and drop of contact persons (allow adding non-contact items?).

Progress (paused): ContactGroup(Contacts) class has been created with two basic attributes: name and members (with an inverse groupMemberships attribute on it's contacts superclass). Created a basic detail view.

Next steps: Find a way to add members to the group. Alternatives:

1. Drag and drop contacts from the Summary View

   Problem

   when trying to drag an item it becomes automatically selected, thus replacing group's detail view.

   Solution

   drag items only within the summary view, instead of dragging them from the Summary to group's detail view.

2. Create a separate window to manage members with a list of available contacts on the left, a list of current members on the right and "add >>"/"<< remove" buttons in the middle.

Find the best kind of block to list members. Find a way to remove members.

5 Implement role of groups

Goal:

• Ensure that a group of contacts can be used in Chandler actions or shared as easily as contact persons.
• Propagate actions to group members: sending an email to a group of contacts should be "propagated" sending the email to each individual group member as it is not possible to send the email directly to the group. Other actions don't need such propagation: if you add "Chandler_devs" group to your office hour event, the event should keep track only of the group and not their members as they may change.

6 Further integrate contacts within Chandler

Goal: Create a 'Contacts' filter on Chandler's toolbar next to the existing All, Mail, Tasks and Calendar ones. Also enable to "contact-stamp" other items creating a new Detail View's MarkupBar icon called "Participants". Add contact person/group icons to the generic summary view. Create a customized summary view.

7 Conform contacts to the vCard format

Goal: If everything is working at this point, changes to the structure of contacts (their attributes) should be easily modified without negatively impacting stamps, sharing or other Chandler actions. Update both the customized summary and detail views.

Idea: Most attributes in a ContactPerson will be a sequence of attributes:

• Allowing the existence of multiple emails, telephone numbers, etc.
• Each attribute will be tagged as home, work, private ...
• The order of the sequence will denote the preferred attribute (default email, etc.).

7.1 Allow GUI-editable multi-value fields

Goal: vCard specification allows multi-value fields (emails, tel. numbers, etc.), each one identified by a tag (home, work, fax, etc.). Here's an example of OSX's Address Book approach:

We need in chandler to create a "detail block" capable of (in order of importance):

• Displaying multiple values.
• Editing and deleting existing values as well as creating new ones.
• Tagging values.
• Reordering values (first value will be used as the default value where only one value is required, ex. sending an email).

Idea:

1. The first solution would be to create a detail view capable of displaying an arbitrary number of fields as in this OSX's Address Book example.

However this is impossible due to a limitation on the API/architecture way of specifying the detail view tree of Blocks: The exact number of fields must be specified in advance.

1. A possible solution, and (no longer) the simplest one:
   • Display values as a comma separated list of strings: When the list is modified parse the string and recognize modified/suppressed/new fields.
   • Later add support for arbitrary tags enclosed with brackets:
   • And finally replace recognized tags with icons (home, work, fax, msn, yahoo, etc.):

1. The new simplest one: Just use a big block note to store raw vCard data with headers and footers stripped. This way users will dirty (but quickly) be able to import and export vCards, and also primitively edit vCard information.

1. Another possible solution would be to create a single GUI element capable of displaying an arbitrary number of attributes.

• • In this case creating/editing/taggin an attribute would be done in place (preferable) or through a separate popup window (as in the example). This solution requires more work and may prove too cumbersome (lists, extra buttons...) to be effectively implemented.

Progress: Decided with design to use option 3 (big block note). And move one field at the time out of using option 2.

8 Import/export vCards

Goal: Use the vobject module already included in Chandler.

Idea: With multiple valued and tagged attributes on 7, it should be quit easy to import/export contacts. It will be possible to import/export single contacts and/or a several contacts from/to a .vcf file.

9 Other proposed features

To be scheduled and ordered...

Contact Reports: Popup window showing everything related to a given contact person/group (items created, tasks/events involved on, incoming/outgoing messages, etc.). Most items already create a bidirectional link to the contacts they work with, so it would be only a matter of creating missing links and displaying them.

Contact's pane: Create a pane available anywhere in chandler to have quickly share, invite or add participants to any Chandler item. This point could be related to the next one.

Smart usage of contact information: Allow auto-completion of contacts in messages, participants' lists, etc. This could be achieved by creating "contact-aware" Blocks to be used in detail views instead of generic Blocks as text fields.

Easy contact creation 1: Allow contacts to be created whenever an email is replied (composed?) or by using an "add to Address Book" button/contextual menu over any item (thus creating a contact from the sender/owner/creator of the item). For the particular case of emails usually apps. add the new user upon replies only:

• A normal user won't reply a spammer.
• You have at least the displaying name of the person you are replying to.
• There are no email address mistyping errors as you'll be replying an a successfully sent message.

In the future users should be able to activate/deactivate this functionality.

Easy contact creation 2: Allow add quick contact the Google Calendar way: Ex. "tomorrow 2pm meeting with John" -> NewEvent(date=15/07/2006 14:00:00, participants=searchByKwd("John")) This would be applied to contacts (and why not events also). Challenge: potentially malformed and hard to decode user's text strings ("nxt week meet all SoC friends on fri or wed").

Dashboard: Test the Dashboard functionality on upcoming alpha and decide contact's behavior within it.

Import/export to hCard format: hCard is only an XML-comliant vCard representation. There surely exist Python libraries capables of handling hCard<->vCard conversions.

Import/export from vendor proprietary file formats: Should not be considered, any good PIM/email client/address book app. uses vCard import and export. Even Outlook and Win. address book are moving to vCard compliant versions for Vista.

Sync contacts

Import/export/sync with LDIF/LDAP servers

CardDAV compliance: Add CardDAV required (and optional) methods to the contact implementation to allow CardDAV interaction (reports, retrieving contacts, synchronizations, etc.).

IM launch and presence notifications: If some contacts have one or more valid IM fields (ex. X-AIM, X-JABBER, X-MSN, X-YAHOO, X-ICQ) allow their icons or text color to change according to their online status (not connected/available/busy/away). Most IM systems have a way to activate such notifications, usually just a checkbox under its preferences. Finally, if a contact is connected clicking its name in Chandler, and firing an URI request to the operating system (ex.: aim://rivera.ernesto) would suffice to start the corresponding AIM from within Chandler.

And more: Product catalogs, Restaurant directories, Local white pages and yellow pages, Artist profiles. Print labels, make calls from Chandler contacts, logging meetings and phone calls from contacts, allow users to view contact information by domain as well as by type? (e.g. All home contact info as opposed to All phone numbers). When would someone want to view contact info by type? versus by domain?

Other

• OSAF interns' mid term presentation slides in S5 format (10 Aug 2006).
• Final presentation 2006-11-Slides.zip (more technical detail).
• Subversion links:
  • 0.7alpha3: contacts
  • 0.7alpha4: Chandler-ContactsPlugin

Comments