[Design] Graphically editing contact's multi-value fields

[Ted Leung]

On Jul 17, 2006, at 7:38 AM, Ernesto Rivera wrote:

> Your email made me realize that a "big note" field will greatly  
> simplify the first contact's detail view version.
>
> Here's what I propose:
>
> - Name the big note field "raw vCard", without the headers and  
> footers:
>
> N:Jordán;Joe;;;
> FN:Joe Jordán
> TEL;type=HOME;type=pref:+591 4 437 98 83
> TEL;type=CELL:+591 707 16 003
> TEL;type=HOME:(591-4) 437 98 83
> item1.ADR;type=HOME;type=pref:;;;Cochabamba;;;Bolivia
> item1.X-ABADR:ch
> NOTE:Jordán Camacho\nJosé Andrés
>
> - This way I could implement right away a dirty but quick and  
> functional vCard import/export.

I think that it's better to get vCard import/export working   
quickly.   The UI stuff for the detail view is going to get  
complicated, and I'd hate for you to get stuck there for a long time.

>
> - Cleanly move one field at a time out of this big note using comma  
> separated fields (http://wiki.osafoundation.org/pub/Journal/ 
> AddressBookProject/imagen4.png)

Yes, ultimately, we can't use the big note field, because that's  
pretty user unfriendly, but as a way of getting you unblocked for  
your Summer of Code project, I think it's a good idea.

>
>> ----------------
>> firstname.lastname at email.com
>> (234)567-8900
>> 34 Wayward Drive, 90210
>> (Home address)
>> -----------------
>>
>> If data is properly formatted, then we provide visual feedback that
>> we recognize it as a phone number or an address or an email address.
>>
>> -----------------
>> Email: firstname.lastname at email.com
>> Tel: (234) 567-8900
>> Home address: 34 Wayward Drive, 90210
>> -----------------
>>
>> Ideally, users could add user-defined attributes this way too:
>>
>> -----------------
>> Email: firstname.lastname at email.com
>> Tel: (234) 567-8900
>> Home address: 34 Wayward Drive, 90210
>> Relationship: Roommate's girlfriend
>> -----------------
>>
>> What are the challenges of this approach?
>
> Now that would be more complicated, but I'll discuss that on the  
> wiki page.
> At first sight, I would say that people will write everything on a  
> hard to decode way. But it could be as interesting as Google's  
> smart Calendar way of quickly adding new events:
>
> "today 2pm dinner with John"

When I worked on Apple's Newton back in 1997, you could do this.  It  
worked very well.   This is part of the reason that Darshana is  
working on NLP functionality for her project.

>>
>> 2. Sync contacts with another client? Which clients?
>
> vCard support should suffice to interact with *any* good email/ 
> address book app. Even upcoming Vista apps. are fully incorporating  
> both vCards and iCalendars.
>

No one is mentioning the mobile phone contact sync problem.   There  
are going to be other needs for syncing, but they are certainly out  
of scope for your Summer of Code project.   Also, I can imagine real- 
time syncing to Apple's address book on the Mac using the address  
book API's.    It's not something that is probably on our radar for  
Chandler 1.0, but since so many other programs on the Mac interact  
with the address book, having a smooth way of talking to it and  
keeping it up to date would make it easier for people to use the  
Chandler address book as their primary address book.

>> 4. Auto-generate contact for each email address that is received in
>> Chandler? What are the implications for SPAM? Can we auto-generate a
>> contact and keep it in a holding pen...pending approval?
>
> Usually apps. add the new user only upon reply:
>
> - you shoudn't reply a spammer.
> - you have at least the displaying name of the person you are  
> replying.
> - there are no email address typing errors as you already received  
> a message from the guy.
>
> In the future users should be able to activate/deactivate this  
> functionality.
>

Yep, we ought to have something like this, and it probably ought to  
be activated by reply.

>>
>> 7. What kinds of contacts do we need to support out of the box for  
>> Beta?
>> + Work contacts
>> + Personal contacts
>> + Families
>> + Couples
>> + Companies
>> + Organizations
>> + Accounts
>
> This is a quite complicated problem most PIMs just tend to ignore:

I think that our goal is eventually to be able to support many of  
things in that list.  Whether or not we do that for Beta/1.0 is a  
separate story.

>> Interaction questions...
>> Do we want to allow users to view contact information by domain as
>> well as by type? (e.g. All home contact info as opposed to All phone
>> numbers)
>>
>> When would someone want to view contact info by type? versus by  
>> domain?
>
> I will order and develop these subjects also, also feel free to add/ 
> complement any contact discussion directly on the "? Other proposed  
> features" section of the wiki.

Some of this stuff falls under the general topic of searching, which  
is broader than just how it should work in the address book.

Ernesto, can you send a note to the list when you update the wiki?    
Not everyone has wiki notifications turned on.

Ted


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060717/1016e390/attachment.html