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.
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.
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.
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.
Does stamping as contact imply auto-filling out of all the attributes
of a Contact item?
+ 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.
+ 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.
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?
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?
If one use of a collection is a project, then I can see some value in
associating (somehow) Contacts with that project.
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.
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
Multiply the difficulty of 2/3 because it intersects the security
model for the server as well.
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
