Hi Ernesto,
Let me say again how happy I am that someone is seriously working on
contacts!
I agree with several things that have been said in this thread so far:
1. The importance of vCard import/export and the ability to represent
at least as rich a schema as vCard can
2. Lowering the priority of a contact stamp
New stuff:
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.
In the section "Implement the role of groups" you say "propagate
actions to group members". Which actions are you talking about here?
Today during IRC <http://wiki.osafoundation.org/script/
getIrcTranscript.cgi?
channel=chandler&date=20060628&startTime=1100&endTime=1210> we talked
a little bit about possible UI views where contact could appear.
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.
Ok, I think that's enough for now.
Ted
On Jun 24, 2006, at 7:21 AM, Ernesto Rivera wrote:
Hi,
My name is Ernesto Rivera, I am a Google SoC student working on the
Contacts/Address Book side of Chandler. My mentor is Grant Baillie
who set-up a wiki page to track the project's status:
http://wiki.osafoundation.org/bin/view/Journal/AddressBookProject
I know this subject interests many of you, so please go to the page
and give your suggestions editing and commenting/linking as needed.
Briefly I intend to:
- Use the existing and PyCon's 2006 contacts implementation.
- Work the integration of contacts within chandler (custom views,
stamping, etc.).
- Conceive simple and nested group of contacts (which should work
on prev. scenarios just like single contacts).
- Only then review contact item's attributes, comply with vCards
and deal with importing/exporting contacts.
Cheers,
Ernesto
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
