[Design] [Sum] Contacts Design

[Ed Bindl]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070709/6a119083/attachment.htm