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 - formatting problem - resending

From: Jungkee Song <jungkee.song@samsung.com>
Date: Thu, 18 Oct 2012 15:09:24 +0900
To: "'Carr, Wayne'" <wayne.carr@intel.com>, public-device-apis@w3.org
Message-id: <023201cdacf7$1f84d130$5e8e7390$%song@samsung.com>
> -----Original Message-----
> From: Carr, Wayne [mailto:wayne.carr@intel.com]
> Sent: Thursday, October 18, 2012 11:39 AM
> 
> I think Bryan's use case is compelling.  Was dropping this in response to
> Web Intents dropping the extras field?  That was just because the extras
> can easily be migrated into the data field.  This spec isn't using the
> data field as input so it's easy to use it for describing the request.

This CFC, discussing on removing search (dictionary ContactIntentExtras) from Pick Contacts Intent (PCI), does not have to do with getting rid of the "extras" field [1] of IntentParameters in Web Intents (WI). "extras" in WI was originally defined to specify extra meta information (url, filename, etc.) about the payload of "data" field. And as the TF determined to move those extra info into "data" field, it became useless somehow. On the other hand, we need a field to deliver optional parameters and used extra of WI for that purpose. Now, I think we can make use of "data" field of WI in that purpose if we make a decision to retain this search option capability after all. But I will double check with TF members whether we better define independent parameters rather than using "data", though.


> I think the data passed in should include:
> ---
> requiredFields - don't return contact information that doesn't have values
> for all of these fields (field names come from 5.1.1) and only return the
> fields listed
> 
> optionalFields - also return these values for these fields if available,
> but don't fail if no values (field names come from 5.1.1) - only fields in
> either  requiredFields or optionalFields are returned
> 
> valueContainsFilter - array or pairs of fields and values where only
> contacts where those fields contains those values are returned
> 
> limit - max number of records returned

These seem to be some sort of powerful searching and filtering capabilities on contact database. However, as this is an Web Intents based API, we leave those complex searching and filtering capabilities to service end. Service providers can implement better UX with greater flexibility when we do not impose any constraints. As we've felt in this demo [2]. The reason why we still retain the search and filter option here is to cover certain compelling use case in that client would want to pass some search hints from the page context when invoking the intent. It's apparently an option for those service providers who really intend to provide such a customized UX.


> ---
> 
> The data returned from the contacts service in 5.1.1 are only the fields
> listed above and only for contact records that match the requirements
> (required fields and required values).
> 
> That prevents having to dump lots of contacts back to the client and
> having search there.  So passes only the information that it needs to pass
> back.  And tells the contacts service what data it wants.

Again, we expect service providers would provide some sort of strong search UX and users would exploit "Pick" action from Pick Contacts Intent. ;)

> Example: the client can ask for contacts that contain "Smith" in the name
> field and that have an email address - only the name and email address are
> returned.  The draft should be clearer that the user is asked if it is OK
> to return what was found.
> 
> A Contacts API has to be able to specify what data it is looking for so
> that it can be given as little as possible (for privacy reasons).

It can be achieved by "ContactIntentExtras.fields" if we retain the search option.


[1] http://lists.w3.org/Archives/Public/public-web-intents/2012Sep/0008.html
[2] http://berjon.com/contacts-intent/



> >
> >>-----Original Message-----
> >>From: Jungkee Song [mailto:jungkee.song@samsung.com]
> >>Sent: Monday, October 15, 2012 7:16 PM
> >>To: public-device-apis@w3.org
> >>Subject: RE: [Pick Contacts Web Intent] Extend CfC for 'remove search'
> >>to 22 October
> >>
> >>-1.
> >>
> >>In addition to Sakari's point, without using search and filtering
> >>options, I could not come up with any way to support the use case [1]
> >>Bryan provided. I think the use case is compelling.
> >>
> >>The CFC for the 'remove search' is until 22nd of October, please share
> >>your opinion!
> >>
> >>
> >>[1]
> >>http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0119.htm
> >>l
> >>
> >>
> >>Jungkee
> >>
> >>> -----Original Message-----
> >>> From: Poussa, Sakari [mailto:sakari.poussa@intel.com]
> >>> Sent: Tuesday, October 09, 2012 4:34 PM
> >>> To: Frederick.Hirsch@nokia.com; public-device-apis@w3.org
> >>> Subject: Re: [Pick Contacts Web Intent] Extend CfC for 'remove search'
> >>> to
> >>> 22 October
> >>>
> >>> -1
> >>>
> >>> I think the client needs to have a way to include search filter. IMO,
> >>> this is very basic feature in contact API.
> >>>
> >>> BR; Sakari
> >>>
> >>> On 10/1/12 3:00 PM, "Frederick.Hirsch@nokia.com"
> >>> <Frederick.Hirsch@nokia.com> wrote:
> >>>
> >>> >The decision regarding removing search from the Pick Contacts Web
> >>> >Intent requires more thought and list discussion based on the issues
> >>> >raised on the list and the call [1].
> >>> >
> >>> >Thus we should extend the CfC deadline to allow this to happen -
> >>> >thus let's extend the CfC outlined below to 22 October, giving 3
> >>> >more weeks for review and list discussion.
> >>> >
> >>> >regards, Frederick
> >>> >
> >>> >Frederick Hirsch, Nokia
> >>> >Chair, W3C DAP Working Group
> >>> >
> >>> >[1]
> >>> >http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/att-
> >>> 0131/mi
> >>> >nutes-2012-09-26.html#item04
> >>> >
> >>> >For tracker this should complete ACTION-580
> >>> >
> >>> >
> >>> >On Sep 19, 2012, at 3:30 PM,  wrote:
> >>> >
> >>> >> On today's DAP teleconference  [1] we discussed removing search
> >>> >>from the Pick Contacts Intent draft [2].  Our discussion included a
> >>> >>number of reasons, including the fact that service providers may be
> >>> >>better positioned to offer integration of search with a meaningful
> >>> >>and familiar user interface, that matching depends on semantics
> >>> >>that may not be immediately obvious and may be coupled to the
> >>> >>service, and a general desire to simplify the specification.
> >>> >>
> >>> >> Specifically this would mean removing the ContactIntentExtras
> >>> >>dictionary definition (4.1.1) and its use case (and would also
> >>> >>require an update to Example 1).
> >>> >>
> >>> >> This is a Call for Consensus (CfC) to remove this search
> >>> >>functionality from the Pick Contacts Intent draft.  Support with a
> >>> >>+1 to the list is preferred, silence will be considered agreement,
> >>> >>concern should be expressed to the list.  Please respond by 25 Sept
> 2012.
> >>> >>
> >>> >> Thanks
> >>> >>
> >>> >> regards, Frederick
> >>> >>
> >>> >> Frederick Hirsch, Nokia
> >>> >> Chair, W3C DAP Working Group
> >>> >>
> >>> >> [1]
> >>> >>http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/att-
> >>> 0096/m
> >>> >>inutes-2012-09-19.html#item03
> >>> >>
> >>> >> [2] updated editors draft,
> >>> >>http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html
> >>> >>
> >>> >> For tracker this completes ACTION-576
> >>> >>
> >>> >
> >>> >
> >>
> >>
Received on Thursday, 18 October 2012 06:09:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 18 October 2012 06:09:59 GMT