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

Mon Jul 17 07:38:01 PDT 2006

(http://wiki.osafoundation.org/bin/view/Journal/AddressBookProject)

> Hi Ernesto,
>
> Thanks for mocking these helps, the visuals are very helpful.
>
> There are some higher-level questions we need to answer about what
> workflows and usage scenarios we want to support for our target user
> group. Answering these questions will help us figure out the best
> interaction design for displaying and manually editing contact info.
> In the meantime, you should go with whatever is easiest to implement,
> just so we can have something to play around with as soon as possible.

The *main* usage scenario right now is to support vCard-like  
contacts, which mostly means the need for arbitrary number of values  
for any given contact field. The main purpose of this project will be  
to import/export from .vcf vCard files.

> I've also added a 4th option at the bottom. It's susceptible to human
> error, but it's probably the most natural way for users to enter
> contact information. It's perhaps something we could try, knowing
> that there will be some interaction issues...and then tweak and
> refine over time.
>
> ===
> Another proposal:
> What if we just left the information in a big Notes field?
>

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.

- 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)

> ----------------
> 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"

> ===CONTACTS MANAGEMENT SCENARIOS===
>
> 1. Importing contacts from another client.
> + Which means the ability to display and edit whatever fields get
> imported.
> + What about attached notes?
>
> 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.

> 3. Auto-create a contact for each email address that is entered into
> Chandler
>
> 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.

> 5. Enter contact info manually.
>
> + email addresses
> + phone numbers
> + addresses
> + user-defined attributes

Definitely.

> 6. Stamping items to add them to the Contacts directory
>
> 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:

- A user can be both a work and a personal contact, duplicated cards?  
merged?
- When you share your contacts which fields would you share? declare  
some private fields?

I will further develop the subject on the project's wiki.

> More out there stuff
> + Product catalogs
> + Restaurant directories
> + Local white pages and yellow pages
> + Artist profiles, etc
>
> Deferred stuff...
> 8. Print labels?
> 9. Make calls from Chandler Contacts
> 10. Logging meetings and phone calls from Contacts
>
> 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.

>
> On Jul 14, 2006, at 7:58 AM, Ernesto Rivera wrote:
>
>>
>> I would like to get some on the AddressBook project I'm working on
>> (http://wiki.osafoundation.org/bin/view/Journal/
>> AddressBookProject), more precisely on task 7.1:
>>
>> "Allow GUI-editable multi-value fields"
>>
>> The idea is to decide the way users should add multiple values (ex.
>> multiple emails), assign to each value a tag (ex. home), reorder
>> values (ex. which email use when contacting someone?).
>>
>> Once a GUI is chosen I will work on creating the appropriate detail
>> blocks.
>>
>> --Ernesto
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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/20060717/f1ccdd95/attachment.html