Great analysis by "Mimi Yin" <mimi@osafoundation.org>:
CivicCRM
========
In Sunday's 2nd breakout session, the group I was in worked on Dave
Greenberg's CRM (Customer / Contact Relationship Manager) plug-in to
Civicspace called CivicCRM. (Is that correct Dave?)
The basic data model (please correct me if I'm making this up) consists
of Individuals, Organizations and Family / Households, all of which can
be related to each other bi-directionally. (ie. George Foreman IV is an
employee of George Foreman Grills Inc., son of George Foreman I and
brother of George Foreman II, III and V.)
There is also a notion of groups, ad-hoc lists of individuals created
for the purpose of mailing lists, call lists and snail mail lists, etc.
We talked a little about how perhaps to the end-user, the difference
between a mailing list group and an organization or family / household
was trivial. That there was no real reason why a user wouldn't find it
just as useful to address a mass email to an organization: Sierra Club
and that it might feel redundant to then be forced to create a separate
thing called a group: Sierra Club to accomplish that when the user
feels like they have already created the organization: Sierra Club.
This issue underscores the importance of identifying features that are
very similar conceptually, yet significantly different behaviorally.
They either need to be clearly differentiated or conflated for
simplicity's sake.
Another mental model issue that we didn't have time to cover was: Do
Organization and Family / Household truly capture the superset of all
possible "groupings of individuals" an user might want to make. In
other words, would it be useful for users to be able to create other
kinds of more lightweight groupings or affiliations? As in...
1) Ones that aren't centered around a particular organization? OR
2) Ones that are centered around organizations that individuals were a
member of in the past? OR
3) One that are centered around organizations that the user doesn't
want to keep track of in the database because the organization itself
isn't important to them. The organization is only important to the user
as a way to organize relationships between several individuals (ie. 3
people who all have kids in the same Little Rascals PeeWee Baseball
League Team)
Some examples of lightweight affiliations that aren't satisfied by
Organization or Family / Household:
- Friends from the feminist activist groups in college
- Know each other through events for board members of various Asian
Art museums across the country
- Play touch football together three times a week
- Co-coaches on the same Little League team
- All played in the school band in Junior High School
- In the same circle of friends
- Neighborhood association
It might be important to ask the theoretical users of CivicCRM if they
ever keep track of such meta-information about individuals and their
relationships. For example, if you're trying to raise money for an
after-school program and you have a lead on an individual who happens
to still be in close touch with friends they made in Junior HS band,
this person might be a great way to get access to several potential
funders at once who all have shared interest in after-school programs
for kids. A person who has several such affiliations might be
especially appealing. Such people might be identified as KEYSTONE
funders, as in people who are the hub of a network of people with
shared interests.
Another added benefit of allowing users to create more lightweight
affiliations is that it is a good way to figure out the relative
strength of relationships between individuals (ie. Corinne and Maxim
know each other in 5 contexts: Neighbors, Kids in the same playgroup,
Play tennis together, Part of the same book club, Monthly dinner
party). Organizations are too few and far between (aka clunky) to
capture the subtle nuances of real world connections.
As far as I could tell, the current CivicCRM data model doesn't allow
users to create such ad-hoc contextual affiliations that are neither
Organizations nor Family / Households. However, it does allow users to
create relationships between individuals. 1-to-1 relationships between
individuals MIGHT be a way to meet the use cases enumerated above.
However, as with a lot of the social networking applications that have
emerged in the last few years, 1-to-1 relationships often devolve into
monstrous laundry lists of thousands of people with no obvious and
substantive way to figure out
1. Which relationships are meaningful and which ones are superficial
2. The context of these relationships. How do these 2 people know each
other. Met at a conference for work? Skiing? College? All three?
3. Who amongst these 4000 "related individuals" share the same contexts
and affiliations?
In other words, social networks provide a lot of land, but not very
much scape. It's a flat, undifferentiated list of relationships lacking
texture and context.
The question is, is it enough for users to define relationships between
individuals? (ie. Karim is a friend of Cory). Or should the mental
model be: How do these two people know each other? How do these eight
people know each other? How else do these two know each other? Who else
do these two people know in common? In what contexts? In how many
contexts? Then we can begin to figure out How WELL people know each
other.
We faced a similar challenge in Chandler. Our solution was a
lightweight grouping we called cluster:
http://wiki.osafoundation.org/bin/view/Chandler/AdhocCollectionsWorkflow
