W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2012

Re: [Pick Contacts Web Intent] Extend CfC for 'remove search' to 22 October

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Thu, 25 Oct 2012 17:55:12 +0000
To: Josh Soref <jsoref@rim.com>
CC: DAP <public-device-apis@w3.org>
Message-ID: <AB5CBB8D-9D2E-4C77-9F3A-F49F1A0EF386@att.com>
Josh,

There may be bad implementations and bad client apps but I would not expect them to survive long. Nonetheless the intersection of them, while a problem for the poor users who stumble into it, should not be held up as a general example of why this functionality should be excluded from the API. Call it a hint or a search/filter, I don't care.  But the value and UX for this picker will suffer without it.

Thanks,
Bryan Sullivan

On Oct 23, 2012, at 4:24 PM, "Josh Soref" <jsoref@rim.com> wrote:

Wayne wrote: 
> I think Bryan's use case is compelling.

My concern keeps being that it really isn't the business of the client application as to what data the user selects from the service. 

We've changed the description to indicate that it's a hint, but we've left the name as "search" and that is leading to continuing confusion.

Bryan wrote:
> the effectiveness of the contact picker experience is substantially improved by the ability of the app to indicate the filter criteria to the intent provider.

I don't think that's really true fwiw, the effectiveness of a contact picker is really determined by the effectiveness of the contact picker itself, a lame contact picker will be a lame contact picker no matter what.

And a bad hint from the client application can actually make it an even worse experience.

I spent the past week dealing with "mail room confusion". The rule we have is "mail is sorted according to the first letter of the commonly used first name" -- the reason for this is to avoid confusion for people who change their family name when they change their marital status (which seems to happen often enough). Unfortunately, not everyone receiving mail exists, and mail was being sorted with off by one errors and not necessarily by the right "name" field (not all mail comes with all name fields, and there's no canonical lookup to determine the right first name field for a person).

We have people [the names below have been changed but do reflect real world problems]:

blablablah Jane Smith

No one knows Jane as "blablablah", but mail for Jane was sorted under "B".

We have mail for:
Curtis Matthews, but the directory only has Curt Matthews, so looking Curtis up fails.

We had mail for Curtis O Mathews too, which was just as bad (or perhaps worse). In the end, I had to just manually search for Curt Matthews.

Note that while I do know Curt and Jane, I don't necessarily know that they're equivalent to blablablah Jane Smith or Curtis Matthews.

The Pick Contact API needs to be able to address this use case. Namely, I'm receiving mail (with various poorly formed name inputs -- which doesn't match the data in my directory) and I want to get the directory's first name to use for sorting purposes. As long as the API is specified such that no implementer tries to take the input I have, fail to find what I need and then force me to start from scratch, I'm more or less ok with a hint. But if it tries to fail fast and early when it can't find Curtis Matthews or blablablah Jane Smith, that's a problem. It's actually better not to provide the hint field at all in the API if that's the most likely outcome (and it certainly is what I've seen). While it may seem like a pain to copy a few characters, it may turn out that it's actually easier for me to hand type "jane smith" than it is to remove blablablah -- that's the concern I have.

---------------------------------------------------------------------
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 Thursday, 25 October 2012 17:56:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 25 October 2012 17:56:40 GMT