[Chandler-dev] Contacts/Address Book project

Ernesto Rivera rivera.ernesto at gmail.com
Mon Jul 3 07:32:05 PDT 2006


(http://wiki.osafoundation.org/bin/edit/Journal/AddressBookProject)

The project's plan has changed -upon several requests- giving highest  
priority to the "conforming to vCard" task, which will be continued  
by the import/export to vCard task.

The main problem for the coming days will be creating "dynamic"  
detail views allowing (like OSX's Address Book):

- Visually creating an arbitrary number of entry fields (3 email  
fields, 4 phone numbers, etc.).
- Visually tagging each of this fields (home, work, etc.).

Is out there something like this anywhere on Chandler? I guess I will  
have to create my own specialized "blocks". In this case where to start?

Now some answers to past emails (all this topics are also on the wiki  
page):


Ted,

>
> I think that you should spend some time thinking about how contacts
> are linked to other items.   We are going to have tasks which are
> assigned to people (or waiting for someone to complete something
> else), events which involve people, and so forth.   One way of
> looking at people/contacts is that they are a hub for organizing
> information.   I may have a meeting scheduled with Katie and want to
> know which tasks I am waiting for her to complete so that I can
> continue.    I might want to know all the meetings that I have with
> Bobby in the next week.   I think that the interesting use cases
> around Contacts revolve much more around data which is linked to
> contacts, as opposed to stamping items as contacts.

I was thinking about a "see everything related to this contact" popup  
report.
Most items already create a bidirectional link to the contacts  
involved (event participants, item creator, group membership, etc.)

>
> In the section "Implement the role of groups" you say "propagate
> actions to group members".   Which actions are you talking about here?

For instance 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.
I see propagate as a "do this action for each member on 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.

> While I agree that it should be possible (actually, it should be
> trivial) to have contact items show up in the All collection, I'm not
> sure that there is much utility in this.   The All collection might
> have quite a bit of stuff in it, which will probably make it hard if
> you are just trying to find the contact for a particular person.
> Also, once we get the dashboard view in place, contacts aren't going
> to fit in well with that usage of the summary view area.     It
> should be very easy to create an address book collection which
> contains all contacts, and this would certainly be a way to get
> something up and running quickly.   But I think that we are
> ultimately going to want to have an optional pane which can appear in
> any application area.   I would encourage you to talk some more about
> the design with Mimi.   For Chandler 1.0 we are trying to support a
> specific set of workflows and functionality, and we want the contacts
> functionality to mesh well with what we are already planning to do.

I will detail this point on the project's page.



Mike,

> Another thing I thought of as I was reading your tasks on the wiki  
> page
> was this: Couldn't Contact Groups be handled by using the existing
> Chandler concept of a Collection?  I'm not sure if this has been
> thought of and rejected but my thought was that any Contact could be
> added to any number of collections and that would allow you to
> manipulate the Contact's membership separately from the actual Contact
> data item.

Currently a ContactPerson and ContactGroup are subclasses of Contact  
abstract superclass, so you can use as you like single persons or  
groups anywhere.
To make groups also a collection would require it to be also a  
subclass of pim.CollectionItem, which shouldn't be an issue on Python  
right? While allowing drag and drop functionality.

However:
a) Adding them to the sidebar (or worse requiring groups to live  
there) doesn't look practical.
b) Allow adding non-contact items to the group collection? yes/no?  
why? Any collection should become a group collection if at least a  
contact item is contained?

>
> I would also urge that you keep an eye out for the fact that almost
> every item you have in a "normal" Contact schema will have multiple
> occurances.  Note I said "will" and not "could" - someone somewhere
> will want 20 phone # while another person will want 20 addresses and
> yet another will want 3 different name fields.  Not that you need to
> support that now, just keep it in mind

Yes, this will be part of the "conforming to vCard" task. However  
certain fields (as the name field) should only contain one entry to  
avoid vCard conflicts.

Creating the schema for this should be quite easy. The difficulties  
will come when implementing details view's "dynamic" behavior (like  
OSX address book's view).





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20060703/b2424877/attachment.html


More information about the chandler-dev mailing list