RE: Proposal for "default services" parameter in IntentParameters dictionary

Inline with [DG]

Deepanshu Gautam
Service Standards, Huawei
O: +86 25 56620008 M: +8613585147627

From: James Hawkins [mailto:jhawkins@google.com]
Sent: Thursday, April 26, 2012 2:44 AM
To: Deepanshu Gautam
Cc: Greg Billock; WebIntents
Subject: Re: Proposal for "default services" parameter in IntentParameters dictionary

Comments inline.
On Tue, Apr 24, 2012 at 8:36 PM, Deepanshu Gautam <deepanshu.gautam@huawei.com<mailto:deepanshu.gautam@huawei.com>> wrote:
Inline...

Deepanshu Gautam
Service Standards, Huawei
O: +86 25 56620008<tel:%2B86%2025%2056620008> M: +8613585147627<tel:%2B8613585147627>

> -----Original Message-----
> From: Greg Billock [mailto:gbillock@google.com<mailto:gbillock@google.com>]
> Sent: Wednesday, April 25, 2012 4:42 AM
> To: WebIntents
> Subject: Proposal for "default services" parameter in IntentParameters
> dictionary
>
> Another chapter in the proposals coming out of the F2F... This one is
> about adding a way for the client to propose default services for a
> particular intent invocation, to make sure the picker will not be
> empty:
May be I'm being destructive but what is wrong in having an empty picker? User have not agreed to register any services for this action so there are no choices.

I wouldn't call it destructive, just inquisitive.  To answer your question, there are several reasons an empty picker should be avoided at all costs:
* It's a confusing user experience, since we're presenting UI to *do something* and the user is unable to complete the action.
* The client becomes less functional, which is unfortunate since the client may have knowledge of a service that can complete the action.
[DG] Thanks…got it.

>
> --------------
>
> Add an attribute to the IntentParameters dictionary as follows:
>
> dictionary IntentParameters {
>  DOMString action;
>  DOMString type;
>  any data;
>  sequence<Transferable> transfer;
>  dictionary<string> extras;
>  URL service;
>  sequence<URL> defaults;
> }
>
> This adds the "defaults" attribute to the IntentParameters dictionary
> proposed for the object literal syntax. The value stored in this
> attribute must be a vector of absolute URLs of Services implementing
> qualifying web intents services.
>
> If the user agent needs information about the all or any of the
> services (i.e. disposition, title, icon, etc) for use in preparing its
> UI, it MAY load the suggested default service URL(s) and examine the
> page(s) for the <intent> tag, reading off such information, or load
> the favicon for the site(s). The User Agent SHOULD ignore the defaults
> suggested by the intent invocation if the user already has a handler
> selected. The User Agent MAY ask the user if they wish to install all
> or any of the suggested default services, just like for
> any other visit of those page.
User may not have the handler *selected* just yet but registrations exists. In this case is it necessary to show the default?

It's not necessary, thus the usage of 'MAY'.  In fact I'm not sure we (Chrome) will show the suggestions if the picker is otherwise not empty.

>
> If the user has no persistent information about a qualifying service
> registered with the User Agent, the User Agent SHOULD present the user
> with the option to select from the default handlers proposed by the
> client at invocation.
>
> The User Agent MUST NOT deliver the intent payload to the page loaded
> as a default unless the Intent filter in the <intent> tag registration
> in the service page matches the intent invocation data according to
> the action/type matching algorithm, just like for any intent delivery.
Why this is needed? I guess, if the picker list some services (default or registered) that means filter have matched. Isn't? Are you referring to only one default existing service which is getting loaded automatically without picker? Sounds like explicit intent.

Hmm, this leads to an interesting line of thought.  I think we'd previously been thinking about showing the suggestions in the UI w/out sniffing for the intent registrations...we should probably rethink that.
[DG] Not sure about that. My only point is not to mention (The User Agent MUST NOT deliver…….) because it is not correct.

>
> If the 'service' parameter is present, invoking an explicit intent,
> the "defaults" parameter is ignored.
>
> -----------------
Why the client can't use explicit intents for this? There can be more than one explicit intent and user can select one of them.

This is explicit intents: specifying 'service' in the parameters.  I don't believe we have any use cases for the client suggesting more than one explicit service and allowing the user to choose between them.
[DG] My point was whether the functionality of “default intent” can be fulfilled by having multiple values of the ‘service’ parameters and allowing user to choose among them? In that case the use case for this will be “Default Service function” itself ☺ I can think of one more use case, though.
If there is only one value (which will also mean that there is only one recommendation) then it will become “explicit Intent ” i.e UA can load the service directly (UA MAY decide to intercept that too…..as specified in the spec. now).
If there are more than one value (or recommendations) then it will become “default service” i.e UA may allow user to select from them.

>
> Some questions. First off, I don't like "defaults". I think it makes
> it sound like a more permanent default setting, which we want to
> reserve for something arranged by the user and the UA. I prefer
> "recommendations". Does that sound good? "recommendedServices"? Any
> better ideas?
>
> I've left it very much up to the UA how to interpret these suggested
> services. It may want to give the user opportunity to install them,
> not display them in the case of a default or a preselected
> alternative, etc. I want developers to be able to expect that
> providing them means the user won't confront a dead end on an intent
> invocation. Does this wording adequately communicate that?


Thanks,
James