Re: [Sum] Contacts Design

Mimi Yin <[email protected]>
Newsgroups gmane.org.osaf.design
Message-ID <[email protected]>
Hi, A lot of good issues and ideas have been weaving in and out of  
the Contacts Design thread on the list so I thought I'd take a moment  
and attempt to extract some highlights, if not pull together a blow- 
by-blow summary. (I will follow-up with a short-term proposal for Ed  
to think about.)

Please respond with anything I've missed / misrepresented. Thx! Mimi

Contacts Usage Scenarios
+ Ed voiced his belief that the 'Digital Rolodex' usage scenario is  
crucial to overall Chandler usability.
+ There was concern that the term CRM is too sale-sy. We should use  
'relationship manager' going forward.
+ I spun off a separate thread about GTD Waiting for workflows:  
http://lists.osafoundation.org/pipermail/design/2007-July/007511.html

Stamping Contacts
+ I think we're in agreement that Stamping Contacts to add them to  
the Task list / Calendar and vice versa is not particularly  
compelling, although Ted said he would use that feature. (I still  
feel we should leave this functionality in place for now and figure  
out how to deal with these modeling issues through some usage.)

+ I believe we're also in agreement that jotting down a Note and  
saving an Email as a Contact *are* compelling use cases.

Navigating between Contacts and Items pointing to/from Contacts
+ I think we all agree that being able to easily navigate to/from  
Items that point to Contacts is a useful feature.
+ It's not clear if this functionality is necessarily in direct  
conflict with Stamping Contacts.
+ There's the idea of being able to see all items that reference a  
particular Contact and vice versa, but what about organizing those  
references by attribute? To: Contact, From: Contact, Author: Contact,  
@Contact, etc...

There remains some significant challenges to figuring out where  
Contacts fit in, in the UI
+ Davor: Treat Contacts like Collections in the Sidebar. (There's no  
reason why this couldn't be extended to apply to any kind of item.)
I don't think we'd want all contacts / items to live in the sidebar  
as collections, but users could identify a few contacts to put in the  
sidebar. This is not dissimilar to the idea of being to define rule- 
based collections in the sidebar: All items referencing Davor.

However the idea of simply dragging a contact / item to the sidebar  
to accomplish this workflow is very appealing. Jeffrey had a similar  
idea to this a while back where he had contacts showing up in the  
mini-cal pane as an alternative view to the preview/mini-cal UI.  
(Essentially, we can think of the Sidebar as a place to store access  
points to 'Favorites' or most-viewed data.

+ (11th hour addition) OS X Finder - Breadcrumb Trail UI - Clicking  
on a Contact in the Detail View opens up another Summary Pane to the  
right of it and so-on-and-so-forth. This idea would be in addition to  
the Contacts and Items as Collections in the Sidebar idea. IOW, the 2  
are not mutually exclusive. (I will send out a more serious proposal  
explaining this idea. In the meantime, here are some old mockups:  
http://chandlerproject.org/pub/Journal/ContactsFeaturesForBeta/ 
Contacts_Mockups.pdf)

+ Some more issues to address
- What about Contacts that reference other Contacts? Do those Contact  
show up in the same view as Tasks, Messages, Events as well?

Contacts and Groups
+ Define groups around any attribute on a Contact (eyes=blue)
+ Define groups around a complex rule
+ Ability to manually define groups, essentially inclusions and  
exclusions

+ Q. Should Groups be Contact Items as well? I think there are  
compelling use cases for being able to reference a group. For  
example: Agenda items to discuss with the PPDTeam.
+ Q. What about companies and organizations? Are they Group-Contacts  
that reference all their members?

+ Having a notion of a 'default' email address (for using groups as  
email aliases)
+ Supporting different 'default' email addresses in different  
contexts (default 'Home' address versus default 'Work' address)

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

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.