Comments inline
On Tuesday, Ed and I took an hour-long whirlwind tour of all
issues relating to Contacts in Chandler. Here is the briefest
summary I could pull together on what we discussed. I'm not
looking for straight out answers to the huge list of questions
below. There needs to be a bit more context for each of them to
have a productive discussion.
I am thinking that Ed and I need to loop in some brains from
development to proceed. Philippe, as Ed's mentor, I'm looking for
some assistance on next steps.
Thanks!
Mimi
At OSAF we've talked about Contact Management in myriad ways:
1. A digital rolodex (Outlook, Palm, Apple Address Books) - would
probably need to support mobile devices to truly fill this niche.
IMO this is a necessary feature for chandler to be usable.
2. A lightweight Customer Relationship Manager tool, a la
Salesforce. A way to manage relationships, where managing
relationships is essentially your job. Each contact entry is
really a profile complete with a history/log of your interactions
with this person: Calls, IMs, email exchanges, sharing history,
mutual contacts, etc.
Could we just call this a relationship management tool? Very few
people really know what a CRM system does, and those that do,
associate them with salesmen and call center workers. Frankly, I
think that this is where the long term value of contacts is, but
we don't support enough information types to make this really
plausible.
+1 to not using CRM or Customer or anything that screams sales to me
+ Contact <--> Task / Calendar It might be handy to use Contacts
as a way to keep track of David Allen-style @People agenda lists,
in which case you might want the Contact to show up on your Task
list and Calendar as a recurring 1:1 event, especially if the
Contact also has pointers to every item that references the
Contact. This scenarios will be less obvious to people though,
but it's maybe worth leaving them out there for now and see what
people do with them.
I would definitely use this.
I would also
+ Triaging Contacts If you understand the triage statuses to be a
way of deciding whether or not you're doing, deferring or done
with processing an item of information, then assigning triage
status to Contacts makes sense. However, if you think of
Contacts simply as archival information, triage status is
understandably confusing. Would it make sense to add a 4th triage
status for something along the lines of Archive?
I think you should have to stamp a contact before you can triage it.
That way you can triage a contact in more than one way, i.e. I can
stamp a meeting with Contact A as done, but can stamp a different
task with Contact A as later or now.
2. Edit/Update and Contacts
Contacts should probably work just like other Items when it comes
to edit/update. The scenarios are pretty much the same.
The biggest problem with sharing contacts is updating as contact
information changes. If I share contact A with person B and then 2
weeks later Contact A's information is updated. Should we update
this info for person B? What if contact A does not want person B to
have there new information?
Also someone could do this without realizing what they are doing.
3. Referencing Contacts,
+ Do items point to contacts or bits of contact info: email
addresses, nicknames, full names, IM buddy names.
I personally think they should be separated into bits of contact
info. Thats how I would expect it to work.
We could use stamping to stamp an email or note into a contact that
only contains a human readable form of the contact.
i.e. I get an email that has the address and phone number of a great
restaurant from a friend, I can stamp it as a contact and look it up
later.
I don't however think this should be the standard way.
+ Are contacts embedded in items as sub-items or is it just a
reference?
I think references are the way to go here. Easier to update and store.
+ Do contacts point back to all the items that point to them?
This last feature would certainly enhance search workflows but
would also start us down the path of becoming a lightweight CRM
tool.
It struck me as a sign of how far we've come that this is even a
question. Not that long ago, everything was supposed to be
connected by bi-directional references/collections. Is it bad
for us to start down the path of becoming a lightweight
relationship management tool?
wow - I agree with Ted. If we lose any aspect of the bi-
directional design I would consider it a major flaw. We may as
well just offer up a way to open the Address Book and call it done.
Definitely, I think Chandler would work best at a lightweight
relationship management tool.
4. Sharing and Contacts
Morgen, Sheila and I have already spent a lot of time agonizing
over the many complicated sharing issues that come up as soon as
we have Contacts. Here is a poor-man's summary of them. I don't
think we need to have answers to all of these right away, but
depending on what other functionality we want to have and what
use cases we want to support, some of these will be more pressing
than others.
+ If A and B share an item that points to a contact: C, do they
share that contact as well? Or just whatever portion of contact
information appears in that item.
+ If A and B each have their own contact for C, can we reconcile
that?
+ What happens if A eventually shares contact C with B?
Sharing Contacts with others needs to have a couple security
related issues before it can be done properly IMO. For the first
version I think Contact Sharing should be only for the current user.
Sharing info between other users requires that the various contact
fields can be flagged as public/private - this way you can share a
contact name or address but not email or phone #'s, etc.
Again what happens if you have an email that 6 months ago you flagged
as public, changes and now should be public. It would be very easy
for someone to accidently share the wrong thing with the wrong person
possibly without even realizing it.
I agree that the first version of contacts sharing should probably
not address these issues and only allowing current user sharing is a
good way to do so.
6. What set of attributes do we need / want for Contacts?
If we don't have all the possible vCard options, how do we
display vCard attributes?
There's also the problem of user create attributes.
user created attributes are important
There is a note property in vCard that we could possibly store the
user created attributes in.
3. Access Privileges
+ Are there ways to share parts of Contacts? Work info, but not
Personal info?
+ Can you share different parts with different people?
+ Do you / can you share all the things that are are part of the
contact log? ie. All the emails you've sent/received. All the
tasks you've assigned/received
Multiply the difficulty of 2/3 because it intersects the security
model for the server as well.
I think one model is that if you are sharing a contact with someone
else, then they only get that contact's info that is marked
sharable and not any of the linked information you may have for
that contact. Think of it as more like exporting a vCard or as
shallow linking instead of deep linking.
I like the shallow linking idea.
-Ed
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
