On Jul 5, 2007, at 9:56 PM, Ted Leung wrote:
On Jul 5, 2007, at 4:57 AM, Mimi Yin wrote: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.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.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.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.
+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?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?2. Edit/Update and ContactsContacts should probably work just like other Items when it comes to edit/update. The scenarios are pretty much the same.3. Referencing Contacts,+ Do items point to contacts or bits of contact info: email addresses, nicknames, full names, IM buddy names. + Are contacts embedded in items as sub-items or is it just a reference? + 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.
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.
4. Sharing and ContactsMorgen, 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.
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
Multiply the difficulty of 2/3 because it intersects the security model for the server as well.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
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.
--- Bear Build and Release Engineer Open Source Applications Foundation (OSAF) [EMAIL PROTECTED] http://www.osafoundation.org [EMAIL PROTECTED] http://code-bear.com PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
PGP.sig
Description: This is a digitally signed message part
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
