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.

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.

===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?

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?

5. Enter contact info manually.

+ email addresses
+ phone numbers
+ addresses
+ user-defined attributes

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

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?

===
Another proposal:
What if we just left the information in a big Notes field?

----------------
(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.

-----------------
Tel: (234) 567-8900
Home address: 34 Wayward Drive, 90210
-----------------

Ideally, users could add user-defined attributes this way too:

-----------------
Tel: (234) 567-8900
Home address: 34 Wayward Drive, 90210
Relationship: Roommate's girlfriend
-----------------

What are the challenges of this approach?

Mimi


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

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

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

Reply via email to