RE: I18N-ISSUE-65: find() method case sensitivity [Contacts API]

Philip wrote:
> I think I understand your views

Good :)

> -- I think that the use cases that you are thinking of are rather 
> different to mine.

Likely
 
> In particular, I'm thinking of a (web based) email app that wants to 
> make use of the address book on the platform.

OK

> I might want to build a UI that had an entry field that looked like a 
> combo-box (INPUT & DATALIST in HTML5), and when I typed into the 
> field, the app would fetch (and update the DOM with) a set of matching 
> contacts, updating on each key press.

I don't think this is what we're offering. You roughly get the equivalent of:

<input type="email">, and the user upon encountering it can provide anything from any of their address books, using an interface that their user agent provides, which they *will* be comfortable with using because they use it *everywhere* that they use their user-agent.

As opposed to yet another quirky and stupid UI. Sure two or three sites will make fancy decent UIs, but the vast majority of sites will provide terrible UIs which will annoy the user and be much worse than the user-agent UI.

> Then, when I had typed enough characters, I might be left with one 
> entry or a small number -- which I could then select between with a 
> mouse (or cursor-down).

Each time you make a query using this API you risk a security check, if that isn't clear enough from the API description, then we should fix it. So no, you really, really, really do not want to do live queries the way you're intending.

What you'd probably do is a live query against addresses you already have seen (Outlook in theory does this, and Thunderbird does this), and when the user picks a name that you propose, you can let them choose to provide updated contact information (e.g. some people had me as "fmiddlelast@example.com" which later changed to "flast@example.com", so, if someone realized my contact info had changed, they might want to be able to tell you "let me provide a replacement contact" after having said "yeah, you completed the right person").

> From your answers, I think that you are focused on different use 
> cases.

> In any case, I think that spelling out the search string syntax would 
> be useful.

We can't, each provider is free to do whatever, and the user is free to provide an arbitrary contact which doesn't match.

> Does "her" match "Catherine"?

If the user decides it matches Catherine, yes. If not, then no. Whether the user is offered Catherine by default is an implementation decision (possibly by a provider as opposed to the user agent).

Would it help if we renamed the field to clearly be "hint" instead of "filter"? I think the answer is yes.

> Does "Cat in hat" match "Catherine Thatcher"?

If the user decides it matches, yes. If not, then no. Whether the user is offered that by default is an implementation decision (possibly by a provider as opposed to the user agent). My guess is that some backends will offer it and some won't, but the user will make the final decision, and an API consumer will only see the user's decision.

> I think that the implicit assumption is that, given a string of words 
> separated by spaces, each of those words must be found in the matched 
> entry (in any order, any case, any position).

What changes are necessary to the API description to make this line of the specification clearer:

"A string-based search filter which provides a hint to the user agent to facilitate contacts selection by the user."

I think that "hint" is pretty clear, but it clearly isn't anywhere near sufficient.

> Some people would argue that "her" should not match "Catherine", but 
> "cat" should match.

> Maybe the search string field should include some idea of the field to 
> be searched.

This is over engineering and fails to scale well to different backends.

> For example, if I receive a SIP call, I might want to lookup the 
> contact entry that has a matching telephone number.

I understand this use case.

> In this
> case, either the matching rules are extremely complex, or I might just 
> want to say that I do a tail match -- i.e. 9789368623 matches
> +19789368623.

I think I wrote a comment on this subject somewhere. 

The short answer (as with all of the other cases), is that when a complete match fails, the user is left with whatever you asked for and the ability to adapt it to find what you seek.

To use the phone number case, if you ask my user agent for:

"+1 (978) 936-8623", and my user agent can't find that contact, it will show me what you looked for. Since I maintain my contacts, I might know that my contacts don't have any international code prefixes and I might strip it to "978 936-8623" and do another search, if that turns up a contact, I can let my user agent return that contact to you (the application). -- As it happens, I'm an international traveler, so all of my contacts are encoded with country code, but that's just me.

As a QoI issue, a user-agent is free to take the value you ask for and munge it when it gets 0 results. It could even do a bunch of queries and score them showing the ones with the most hits first. For things that look like a phone number, I'd hope some in fact will do that.

> I agree that these are all very complex problems.

---------------------------------------------------------------------
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, 5 July 2011 21:36:54 UTC