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).
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
