[Sum] Contacts Design

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.

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.

3. A way to streamline and improve the PIM workflows we support today:
+ Using people as a handle to look for information, essentially a way  
to enhance Search.

+ A way to manage tasks and events around people:
- All the stuff I need to talk to so-and-so about, aka David Allen's  
@Who Agenda list.
- All the stuff I'm waiting for so-and-so to get back to me about

+ An easy way to collect and process contact info you get in the  
course of your information management workflows

So, which one of these do we tackle first?

Proposal
For probably pretty obvious reasons, I think it makes most sense to  
start with Scenario 3: Support the PIM workflows we have today. In  
doing so, we strengthen what we have already, making Chandler more  
compelling as a PIM. I also have a feeling that we'll manage to  
satisfy lightweight rolodex and CRM scenarios for some set limited  
set of users, even if we remain focused on PIM workflows.

What would this entail?
Answering some hard modeling questions we've deferred until now :)

1. Are contact items like other content items. Can they be triaged  
and stamped?
In talking with Ed, we agreed that some contact-stamping scenarios  
make more / less sense than others and many users will simply be  
confused by the idea of managing Contact items as first-class  
information items like Notes, Messages, Tasks and Events.

However, I think there some compelling scenarios that are worth  
experimenting with:
+ Note-->Contact You jot down a note with directions to a restaurant  
you're going to tonight and then you decide to stamp it as a contact  
for future reference and keep it around in the NOW section until  
after your dinner date.
+ Email-->Contact You receive an email from your friend who's just  
moved to Mexico. You want to make sure you keep track of that info so  
you can send her, her birthday gift. You might stamp the message as a  
Contact and add a Tickler to it to pop into NOW 3 weeks before her  
birthday so that it pops up with her contact info just in time for  
you to mail her your gift.
+ Addressing a Contact This is simply another 'single-item' sharing  
scenario. Send contacts to others. Edit and Update them if necessary.

+ 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.

+ 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?

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.

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.

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?

5. Contacts in the Faceted Sidebar
+ Are Contacts an application area? They currently show up simply as  
a collection in the sidebar.
+ Do Contacts show up in the triage table along with everything else?
+ Do Contacts show up in the All application area or are they  
cordoned off in some way? In a separate pane? In a floating palette?
+ Can Contacts be added to any old collection in the sidebar?

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?

These are the issues I think we need to discuss in the short-term if  
not come up with fully-baked stories for. Below is a laundry list of  
issues I think we can defer because they are more relevant to the  
rolodex and CRM scenarios and less immediately relevant to PIM  
workflows.

1. What are the different kinds of Contact?
Traditional 'Contacts as an Address Book' Model
+ A Person?
+ A Business / Organization?

More generic 'Contacts as a Profile Directory' Model
+ Location
+ Country
+ Model (as super-model)
+ Customer / Client
+ Product
+ Anything that you need to keep a 'Profile' record for.

2. There has always been a lot of controversy around what it means to  
be a Group in Chandler as well:
+ Are Groups simply a short-cut for addressing emails or tagging items?

+ Do Groups define teams and organizational structure (ie. Marketing  
team, Murdoch Family, Sierra Club members)
- Do individual contacts have different roles in different groups?  
(ie. Director of Marketing, Dad, Treasurer)

+ Are groups the same as collections?
+ Can groups be defined around rules?
+ Can groups have inclusions and exclusions like Chandler collections?
+ Does each collection have a corresponding Contacts Group? Is that  
Group gathered dynamically? (ie. All the people referenced by items  
in this collection.) Or is it defined explicitly?)

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

4. What about stale contact info? Old email addresses? Telephone  
numbers and Addresses? Ex-spouses?
If an email points to an old email address and the email address is  
updated on the Contact, do we update the email address on all old  
emails as well?

5. User-defined attributes

6. Defining relationships between Contacts
+ A is spouse of B.
+ C is employee of D.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design