Re: [Sum] Contacts Design

On 10 Jul, 2007, at 22:23, Davor Cubranic wrote:

> On Tuesday 10 July 2007 17:55:13 Mimi wrote:
>>
>> ...
>>
>> 1. Are these contact groups dynamically generated (include every
>> person that is referred to by items in this collection) OR manually
>> pulled together? I can think of scenarios for both.
>
> I'm not sure what contact groups might be. I don't think there are any
> in the "search" workflow I described above, and in general
> all "contact" items would live in the "Address book" OOTB collection,
> as shown in Ed's screenshots.

FWIW, In the Apple Address Book application (at which Ernesto may  
have peeked a little last Summer) groups can be either rule-based  
(“smart” in their parlance) or manually created (essentially by  
tagging).

>> 2. Are these groupings email aliases as well? That opens up a whole
>> other can of worms wrt which email address to use in which context.
>> For example, I have 1 contact in both Home and Work collections and I
>> have personal and work email addresses for that contact, etc, etc.

I'm not sure that basing this on collections is necessarily right,  
but it's probably better than other approaches (pick the first,  
highlight "exceptional" addressed) I have seen.

Hmm ... Now that I think about it, this brings up something we need  
to think about for the underlying model for Contacts. At the domain  
model level, we don't model types (maybe aspects is a better word) of  
Contact field. For example, for phone numbers you have home/work/ 
mobile/fax (and most apps allow you to add your own). IIRC, partly  
because it would have been hard to implement the UI, Ernesto just had  
a hard-coded set of attributes here.

> Good question. I imagine there could be a per-collection policy  
> defining
> the order of preference for choosing different email aliases.
>
>> 3. If there is a contacts pane or contacts palette for each
>> collection, then how do contacts show up in the main Triage Table
>> View if you're triaging them?
>
> Maybe a Contact is not a stamp then, but a different kind of item?

Like you, I think of Contact more as a generic Item: the relationship  
to other Items is more linking than a transformation à la stamping  
(au stamping?). I had imagined that, instead of, say, stamping a  
contact as a task or event, we would have some way of linking a new  
task or event to that contact instead.

--Grant

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

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design