On Jul 17, 2006, at 7:38 AM, Ernesto Rivera wrote:
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 think we need to eventually reframe this scenario in terms of user scenarios that are relevant to our target users and target user group.
That will help us understand:
+ How flexible does the data entry interaction need to be?
+ How are people getting their data in? Import? Manual entry?
+ How often are they adding new data? Syncing data? Editing data? (ie. A salesperson would be doing this a lot.)
+ Which fields are important to have out of the box.
+ How much customization do we need to support?
+ Are people really going to replace their current contacts manager with Chandler in the Beta timeframe; OR
+ Do we need just enough contacts management to support our information/task management workflows?
We don't need to answer these questions now. I was bringing this up more to provide some design context for the questions you were asking and to awaken the PPD machine to start addressing this issue. :o)
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.
Excellent.
----------------
(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.
Could you give some examples of contact info that would be hard to decode?
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:
Yup. But that's why we have such a wonderful, flexible data model :o)
- A user can be both a work and a personal contact, duplicated cards? merged?
Or Work and Personal are just attributes of the person...non-mutually exclusive attributes.
- When you share your contacts which fields would you share? declare some private fields?
Yes, we already have this notion already. Certain fields aren't part of the sharing cloud. (e.g. Event status, Alarms, Collection membership, etc)
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.
Great! Thx.
Mimi
