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> wrote:

> Inline...
>
> Deepanshu Gautam
> Service Standards, Huawei
> O: +86 25 56620008 M: +8613585147627
>
> > -----Original Message-----
> > From: Greg Billock [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.


> >
> > --------------
> >
> > 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.


> >
> > 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.


> >
> > 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