So, I just spoke with Philippe and we came up with a plan of action
to keep me busy while everyone is hustling and bustling for preview.
Just wanted to keep you in the loop.
So here's my TODO list:
1) play with the UI and make it prettier/more like the rest of chandler.
2) make notes stamp-able into contacts and add an icon to the markup
bar.
3) add a contacts view to the Application bar.
4) play with the quick entry box and see if I can get that working.
This should keep me busy at least until things settle down. I'm very
open to suggestions/neat ideas anyone has, so feel free to chime in.
Thanks,
Ed Bindl
On Jul 6, 2007, at 2:45 PM, Ed Bindl wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
