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