[contacts] proposal for names

So, my week's about to end, and Ernesto has been busy, which means we haven't synced up.

I have basically two not particularly related thoughts on the area of names (plus a footnote).

1. The most basic proposal I could make is to drop:
First
Middle
Last

And leave just a Name/FullName/DisplayName field

2. We could instead provide a Names associative list:

{ "displayName" : _somename_,
  "mailingName" : _somename_,
  "formalName" : _somename_,
  "nameIn2010": _somename_ /* the field label for this would of course be based on the user's only labeling, but see the footnote for why I list it at all */
}

Which could have 0 or more items with those being suggested ones.

----
To expand on 1 (although it applies equally to 2):

An implementation of the API could be encouraged to behave more or less like Outlook does when it's asked to import a vCard:

It has a "File as" field, with an editable drop down which lets the user select from a number of prepopulated suggestions. The UA could choose to remember the last selected form for future use, or it could favor a preference (Outlook happens to have a preference buried in options). The "File as" field more or less affects "DisplayName" and that approach seems to work for Microsoft (and has been around for a long time). It should be relatively workable for most UAs.

Actual spec text would be along the lines of:
1. remove First, Middle, Last
2. expose a DisplayName field
3. UAs SHOULD allow users to select how the DisplayName field should be constructed for the data to be returned by the API. UAs MAY choose to favor any format which makes sense for their user(s), to remember a user's preferred format, most recent format, or to offer suggestions each time.


----
The footnote:
Generally there are a couple of things one does with contacts:
1. Search for them
2. Try to use them to make contact

When one searches for "Jane Doe", one might occasionally be surprised that she got married and changed her name *yesterday* to "Jane Smith" (this just happened to me less than an hour ago).

The general design of the API is to let an application perform 1 with the help of the user (and user-agent) to eventually do 2 from the application. In the case of LDAP, it's pretty easy for names to change without the user being aware that they've changed (how dare someone I never met before change her name without notifying me?...). As such, I would hope that UA implementations of search generally try to relax searches (better than Outlook, please,... I searched for "Jane Doe", and it didn't notice that "Jane Smith" had an alias of "jdoe") when they fail to get a satisfactory match. My general hope is that a contacts search engine will try to search all available fields and do fuzzy matching (Jane => J; Doe => D; doe*jane | jane*doe | j*doe | doe*j | d*j | j*d) with higher scoring for things which have the most and best matches (jd/dj are really poor matches, but if nothing else matches, showing them doesn't hurt the user much). This is of course a QoI detail (and one where Outlook fails IMO), but I'd be happy to provide some suggested text on the subject. I'll also try to split this footnote off into another email later.

p.s. This week marks the beginning of the Jewish High Holy Days, as such I may be unavailable for various meetings, or may be unable to reply as promptly as I otherwise endeavor (and certainly may not be particularly prompt wrt assigned Actions), I'm sorry about this, but I'll do my best to reply when I can.

I was hoping to actually write a small demo showing an outlook contact editor display name field drop down selector widget, but it will probably have to wait a while. -- sorry.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Tuesday, 27 September 2011 18:30:57 UTC